| 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).
Дата
- Если пользователь явно указал дату создания — используй её.
- Иначе возьми текущую дату из окружения.
- Формат:
➕ YYYY-MM-DD.
- Никогда не проставляй дату задним числом, если пользователь её не назвал.
Разобрать вход
Возможные форматы запроса:
/new-task <текст> [url] (старый алиас /add-task тоже работает)/new-task [end|idea|week+] [(short answer)] <текст>add task: <текст> / «добавь задачу: <текст>»- Многострочный ввод: первая строка — описание, следующие строки — URL или короткие заметки.
Правила парсинга:
- Выдели одну строку — само описание задачи. Без чекбокса, без даты, без префикса «add task:».
- Все URL, которые шли в теле сообщения после описания или на отдельных строках, переноси в подбуллеты.
- Если пользователь дал короткую заметку («ждём ответа от коллеги», номер тикета) — это тоже подбуллет.
- Если задача создаётся из пересланного сообщения (Telegram, чат, письмо) или рядом в контексте известен автор, добавь отдельные подбуллеты:
Автор: <Name> (@login).Цитата: «<полный исходный текст сообщения>».
Не пересказывай цитату и не выбрасывай ссылки из неё; описание задачи можно нормализовать, но подпункт Цитата должен сохранять исходный текст максимально близко к оригиналу.
Важно для многострочных цитат: не оставляй продолжение цитаты без отступа — оно станет обычным текстом между задачами. Либо нормализуй цитату в одну строку с сохранением ссылок, либо префиксуй каждую строку продолжения табом/подбуллетом так, чтобы весь текст оставался внутри этой задачи.
- Не сокращай и не переформулируй описание без необходимости. Опечатки и явный мусор («ага», «вот») можно убрать в описании, но не в цитате исходного сообщения.
- Wikilinks (
[[Имя]]) сохраняй как есть.
- Линт формулировки. Хорошая задача называет конкретное первое действие: глагол + объект («Вызвать клининг для кухни», а не «Кухня» или «Разобраться с кухней»). Если пользователь дал формулировку-проект без очевидного первого действия — добавь как есть (не блокируй и не переписывай молча), но в финальном ответе одной строкой предложи вариант первого действия: «Добавил. Первым шагом может быть: <...> — переформулировать?».
- Позиция. По умолчанию задача идёт в начало блока открытых задач (см. правило 3 раздела «Куда вставлять»). Директивы-префиксы убирай из текста задачи:
end (например end: или end <текст>) — в конец секции # Week: по правилу 5 раздела «Куда вставлять».begin — явно «в начало», совпадает с поведением по умолчанию.
- Директивы назначения (слово-префикс в начале ввода — убери его из текста задачи):
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. Подбуллет — табом, как остальные.
Дедупликация
- Прочитай
tasks.md.
- Найди открытые строки с похожим описанием — открыта любая, кроме
- [x] (правило в obsidian-vault, «Закрытость чекбокса»). Сравнение — без учёта регистра, по ключевым словам.
- Если нашёл точное или почти точное совпадение — не добавляй, покажи существующую задачу пользователю и спроси: «Уже есть такая, дописать подбуллет / всё равно добавить отдельной / ничего не делать?»
- Если совпадение далёкое — добавь, но в финальном ответе упомяни похожую (одна строка).
Дописать в существующую задачу
Используй этот же скилл, когда пользователь пишет «допиши в задачу», «добавь к задаче», «зафиксируй в этой задаче» и т.п.
- Если из текущего контекста очевидна задача (например, её только что создали/обсуждали), не спрашивай уточнение — открой
tasks.md, найди эту задачу и допиши к ней подбуллеты.
- Если контекст неочевиден, найди кандидатов по ключевым словам; спрашивай только если есть несколько близких вариантов или ни одного.
- Дописывай информацию под существующей задачей обычными подбуллетами с табом (
\t- ...), не создавая новую задачу и не меняя порядок списка.
- Если пользователь прислал готовый текст ответа/решения, сжимай его в 1–3 подбуллета
Ответ/решение: ..., сохраняя практический смысл. Не нужно вставлять длинный текст целиком, если это не цитата постановщика.
- После правки перечитай изменённый фрагмент и в финале укажи строки, куда добавлено.
short answer
Если в вызове указано short answer, ответь одной фразой: что и куда добавлено. Не называй имя файла и номер строки; формулировка задачи начинается с глагола, вводные слова убери. Перед ответом проверь .claude/short-answer.md — если файл есть, его указания про тон, род и длину главнее этой формулировки (правило — в obsidian-vault, «Короткие ответы»).
Куда вставлять
- В
tasks.md, всегда — если не сработала директива назначения (правило 9 парсинга). В ideas.md — если явно указано, что это идея; в tasks-future.md — только по явной директиве future / tasks-future (сам туда задачи не переноси).
- Файл разбит на две секции-заголовка:
# Week: (задачи на текущую неделю) и # Week+ (задачи на неделю+, более долгие). Ниже # Week+ идёт строка-легенда (ключ tasks_legend в .claude/vault-config.md; ключа нет — просто не трогай строку, начинающуюся с > Активные задачи).
- Позиция по умолчанию — в начало блока открытых задач секции
# Week:: сразу после последней - [x] и её подпунктов, перед первой открытой (любой чекбокс, кроме - [x]). Если в Week нет завершённых — сразу после заголовка # Week:. Не клади новую задачу в # Week+, если пользователь явно не сказал «на потом» / «неделя+» / «week+».
- Если пользователь просит «в week+» / «на потом» / «не на эту неделю» — клади в конец секции
# Week+, перед строкой-легендой (ключ tasks_legend в .claude/vault-config.md; ключа нет — просто не трогай строку, начинающуюся с > Активные задачи).
- Если пользователь явно просит «в конец» (в т.ч. через директиву
end, см. правило 8 парсинга), вставляй в конец секции # Week:: последней строкой перед заголовком # Week+ (после последней задачи Week и её подпунктов).
- В
tasks-future.md (директива future / tasks-future) файл устроен иначе: сверху общий блок без заголовка, ниже — тематические секции ## <Тема> (Полезный контент, Текучка, Идеи…). Позиция по умолчанию — в начало общего блока, первой строкой файла, до всех ##-секций. Если задача явно относится к существующей теме (например, «прочитать статью» → ## Полезный контент) — клади в конец этой секции. Директива end в этом файле = конец общего блока (перед первым ##).
- Не создавай новых секций/заголовков, не переставляй существующие строки, не сортируй остальные задачи.
Формат строки
- [ ] <Описание задачи> ➕ 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 — если задача крупная, после добавления имеет смысл предложить разбиение.
Проверка перед ответом
- В
tasks.md появилась ровно одна новая строка задачи (плюс подбуллеты, если были).
- Чекбокс
- [ ], дата создания ➕ YYYY-MM-DD присутствует.
- Подбуллеты с табом, не с пробелами.
- Существующие строки не изменены и не переставлены.
- Дубликата не создал.
В финальном ответе одной строкой: какая задача добавлена и в какую строку tasks.md встала.
