new-task

name	new-task
description	Добавить новую задачу в `tasks.md` с маркером даты создания `➕ YYYY-MM-DD`. Используй, когда пользователь пишет /new-task, /add-task, "добавь задачу", "add task", "запиши задачу", "новая задача в tasks", "добавь в tasks.md", "поставь задачу в список", или присылает текст задачи (часто со ссылкой на трекер/документ) с просьбой завести её в активный список.

new-task

Добавляешь новую открытую задачу в tasks.md в корне vault. Скилл — зеркало close-task: тот закрывает, этот открывает. В дневной лог скилл не пишет (это решение пользователя; для записи факта есть worklog).

Дата

1. Если пользователь явно указал дату создания — используй её.
2. Иначе возьми текущую дату из окружения.
3. Формат: ➕ YYYY-MM-DD.
4. Никогда не проставляй дату задним числом, если пользователь её не назвал.

Разобрать вход

Возможные форматы запроса:

• /new-task <текст> [url] (старый алиас /add-task тоже работает)
• /new-task [end|idea|week+] [(short answer)] <текст>
• add task: <текст> / «добавь задачу: <текст>»
• Многострочный ввод: первая строка — описание, следующие строки — URL или короткие заметки.

Правила парсинга:

1. Выдели одну строку — само описание задачи. Без чекбокса, без даты, без префикса «add task:».
2. Все URL, которые шли в теле сообщения после описания или на отдельных строках, переноси в подбуллеты.
3. Если пользователь дал короткую заметку («ждём ответа от коллеги», номер тикета) — это тоже подбуллет.
4. Если задача создаётся из пересланного сообщения (Telegram, чат, письмо) или рядом в контексте известен автор, добавь отдельные подбуллеты:
   • Автор: <Name> (@login).
   • Цитата: «<полный исходный текст сообщения>». Не пересказывай цитату и не выбрасывай ссылки из неё; описание задачи можно нормализовать, но подпункт Цитата должен сохранять исходный текст максимально близко к оригиналу. Важно для многострочных цитат: не оставляй продолжение цитаты без отступа — оно станет обычным текстом между задачами. Либо нормализуй цитату в одну строку с сохранением ссылок, либо префиксуй каждую строку продолжения табом/подбуллетом так, чтобы весь текст оставался внутри этой задачи.
5. Не сокращай и не переформулируй описание без необходимости. Опечатки и явный мусор («ага», «вот») можно убрать в описании, но не в цитате исходного сообщения.
6. Wikilinks ([[Имя]]) сохраняй как есть.
7. Линт формулировки. Хорошая задача называет конкретное первое действие: глагол + объект («Вызвать клининг для кухни», а не «Кухня» или «Разобраться с кухней»). Если пользователь дал формулировку-проект без очевидного первого действия — добавь как есть (не блокируй и не переписывай молча), но в финальном ответе одной строкой предложи вариант первого действия: «Добавил. Первым шагом может быть: <...> — переформулировать?».
8. Позиция. По умолчанию задача идёт в начало блока открытых задач (см. правило 3 раздела «Куда вставлять»). Директивы-префиксы убирай из текста задачи:
   • end (например end: или end <текст>) — в конец секции # Week: по правилу 5 раздела «Куда вставлять».
   • begin — явно «в начало», совпадает с поведением по умолчанию.
9. Директивы назначения (слово-префикс в начале ввода — убери его из текста задачи):
   • idea → задача идёт в ideas.md (хвост лестницы, чеклист - [ ]), а не в tasks.md.
   • week+ → в секцию # Week+.
   • future (или tasks-future) → в tasks-future.md, по правилу 6 раздела «Куда вставлять».
   • Слова-директивы откладывания («отложи», «snooze», «на месяц / на 3 месяца / на полгода», «не сейчас, напомни потом») → это не new-task: делегируй snoozed-task (задача уходит в tasks-snoozed.md с датой 📅, в tasks.md не кладётся).

Проектные задачи

Если формулировка проектная — несколько этапов к одному результату («сделать X» в 3 шага, «запустить Y», задача с явными подэтапами) — заведи задачу как есть (не блокируй), но в финале предложи зарегистрировать её в projects.md с полным планом, а в tasks.md оставить только ближайший шаг. По Дорофееву задачу не раздувают этапами — план проекта живёт в projects.md, в списке задач висит одна ближайшая задача. Без подтверждения проект в projects.md не создавай и задачу не переписывай.

Обратная ссылка. У задачи-ближайшего-шага проекта добавь подбуллет:

	- Проект: [[projects]] (<название проекта>)

Это join-ключ для close-task и weekly-review: они находят проектную задачу по совпадению её текста с первой открытой подзадачей плана в projects.md. Подбуллет — табом, как остальные.

Дедупликация

1. Прочитай tasks.md.
2. Найди открытые строки с похожим описанием — открыта любая, кроме - [x] (правило в obsidian-vault, «Закрытость чекбокса»). Сравнение — без учёта регистра, по ключевым словам.
3. Если нашёл точное или почти точное совпадение — не добавляй, покажи существующую задачу пользователю и спроси: «Уже есть такая, дописать подбуллет / всё равно добавить отдельной / ничего не делать?»
4. Если совпадение далёкое — добавь, но в финальном ответе упомяни похожую (одна строка).

Дописать в существующую задачу

Используй этот же скилл, когда пользователь пишет «допиши в задачу», «добавь к задаче», «зафиксируй в этой задаче» и т.п.

1. Если из текущего контекста очевидна задача (например, её только что создали/обсуждали), не спрашивай уточнение — открой tasks.md, найди эту задачу и допиши к ней подбуллеты.
2. Если контекст неочевиден, найди кандидатов по ключевым словам; спрашивай только если есть несколько близких вариантов или ни одного.
3. Дописывай информацию под существующей задачей обычными подбуллетами с табом (\t- ...), не создавая новую задачу и не меняя порядок списка.
4. Если пользователь прислал готовый текст ответа/решения, сжимай его в 1–3 подбуллета Ответ/решение: ..., сохраняя практический смысл. Не нужно вставлять длинный текст целиком, если это не цитата постановщика.
5. После правки перечитай изменённый фрагмент и в финале укажи строки, куда добавлено.

short answer

Если в вызове указано short answer, ответь одной фразой: что и куда добавлено. Не называй имя файла и номер строки; формулировка задачи начинается с глагола, вводные слова убери. Перед ответом проверь .claude/short-answer.md — если файл есть, его указания про тон, род и длину главнее этой формулировки (правило — в obsidian-vault, «Короткие ответы»).

Куда вставлять

1. В tasks.md, всегда — если не сработала директива назначения (правило 9 парсинга). В ideas.md — если явно указано, что это идея; в tasks-future.md — только по явной директиве future / tasks-future (сам туда задачи не переноси).
2. Файл разбит на две секции-заголовка: # Week: (задачи на текущую неделю) и # Week+ (задачи на неделю+, более долгие). Ниже # Week+ идёт строка-легенда (ключ tasks_legend в .claude/vault-config.md; ключа нет — просто не трогай строку, начинающуюся с > Активные задачи).
3. Позиция по умолчанию — в начало блока открытых задач секции # Week:: сразу после последней - [x] и её подпунктов, перед первой открытой (любой чекбокс, кроме - [x]). Если в Week нет завершённых — сразу после заголовка # Week:. Не клади новую задачу в # Week+, если пользователь явно не сказал «на потом» / «неделя+» / «week+».
4. Если пользователь просит «в week+» / «на потом» / «не на эту неделю» — клади в конец секции # Week+, перед строкой-легендой (ключ tasks_legend в .claude/vault-config.md; ключа нет — просто не трогай строку, начинающуюся с > Активные задачи).
5. Если пользователь явно просит «в конец» (в т.ч. через директиву end, см. правило 8 парсинга), вставляй в конец секции # Week:: последней строкой перед заголовком # Week+ (после последней задачи Week и её подпунктов).
6. В tasks-future.md (директива future / tasks-future) файл устроен иначе: сверху общий блок без заголовка, ниже — тематические секции ## <Тема> (Полезный контент, Текучка, Идеи…). Позиция по умолчанию — в начало общего блока, первой строкой файла, до всех ##-секций. Если задача явно относится к существующей теме (например, «прочитать статью» → ## Полезный контент) — клади в конец этой секции. Директива end в этом файле = конец общего блока (перед первым ##).
7. Не создавай новых секций/заголовков, не переставляй существующие строки, не сортируй остальные задачи.

Формат строки

- [ ] <Описание задачи> ➕ YYYY-MM-DD
	- <URL или короткая заметка>

• Чекбокс — всегда - [ ].
• Подбуллеты — табом, не пробелами.
• Каждый URL/заметка — отдельный подбуллет.
• Если подбуллетов нет, строка задачи — единственная.
• Если пользователь просит «с подзадачами», «чеклистами» или даёт несколько требований в теле задачи — оформляй их как чеклист-подпункты:

- [ ] <Описание задачи> ➕ YYYY-MM-DD
	- [ ] <Подзадача 1>.
		- [ ] <Проверочный шаг/деталь, если нужна>.
	- [ ] <Подзадача 2>.

• Не превращай информационные заметки/исходную цитату в чекбокс: оставляй их обычным подбуллетом - Исходное сообщение: ....
• Для чеклистов допускается второй уровень вложенности с двумя табами, если нужно разложить крупную подзадачу на проверочные шаги.

Пример:

- [ ] Починить чек-лист перехода КП → Клиент принимает решение ➕ 2026-05-12
	- https://example.com/task/12345

Защита от ошибок

• Не добавляй задачу без описания. Если описание пустое — попроси сформулировать.
• Не дублируй существующую открытую задачу молча.
• Не переноси задачу в tasks-future.md по своей инициативе — только по явной директиве future / tasks-future.
• Не делай git commit и не запускай worklog автоматически.
• Не угадывай дату создания задним числом.
• Не меняй порядок существующих строк в tasks.md.
• Не превращай длинный URL в короткий маркер [ссылка] — оставляй полный URL.

Связанные скиллы

• close-task — закрывает задачу и пишет итог в дневной лог.
• snoozed-task — откладывает задачу в tasks-snoozed.md с датой активации 📅 (когда просят «отложить / snooze / напомни через N»).
• list-tasks — показывает открытые задачи, ищет старые и помогает с приоритетами.
• worklog — фиксирует факт в Log/YYYY/MM/YYYY-MM-DD.md. Запусти отдельно, если пользователь хочет ещё и запись в дневник.
• decompose — если задача крупная, после добавления имеет смысл предложить разбиение.

Проверка перед ответом

1. В tasks.md появилась ровно одна новая строка задачи (плюс подбуллеты, если были).
2. Чекбокс - [ ], дата создания ➕ YYYY-MM-DD присутствует.
3. Подбуллеты с табом, не с пробелами.
4. Существующие строки не изменены и не переставлены.
5. Дубликата не создал.

В финальном ответе одной строкой: какая задача добавлена и в какую строку tasks.md встала.