new-task

name	new-task
description	Добавить новую задачу в `tasks.md` с маркером даты создания `➕ YYYY-MM-DD`. Используй, когда пользователь пишет /new-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: <текст> / «добавь задачу: <текст>»
• Многострочный ввод: первая строка — описание, следующие строки — URL или короткие заметки.

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

1. Выдели одну строку — само описание задачи. Без чекбокса, без даты, без префикса «add task:».
2. Все URL, которые шли в теле сообщения после описания или на отдельных строках, переноси в подбуллеты.
3. Если пользователь дал короткую заметку («ждём ответа от коллеги», номер тикета) — это тоже подбуллет.
4. Если задача создаётся из пересланного сообщения (Telegram, чат, письмо) или рядом в контексте известен автор, добавь отдельные подбуллеты:
   • Автор: <Name> (@login).
   • Цитата: «<полный исходный текст сообщения>». Не пересказывай цитату и не выбрасывай ссылки из неё; описание задачи можно нормализовать, но подпункт Цитата должен сохранять исходный текст максимально близко к оригиналу.
5. Не сокращай и не переформулируй описание без необходимости. Опечатки и явный мусор («ага», «вот») можно убрать в описании, но не в цитате исходного сообщения.
6. Wikilinks ([[Имя]]) сохраняй как есть.

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

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

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

1. В tasks.md, всегда. tasks-future.md скилл не трогает.
2. Файл разбит на две секции-заголовка: # Week: (задачи на текущую неделю) и # Week+ (задачи на неделю+, более долгие). Ниже # Week+ идёт строка-легенда > Активные задачи. Будущие: [[tasks-future]]..
3. Позиция по умолчанию — в конец секции # Week:: последней строкой перед заголовком # Week+ (после последней задачи Week и её подпунктов). Не клади новую задачу в # Week+, если пользователь явно не сказал «на потом» / «неделя+» / «week+».
4. Если пользователь просит «в week+» / «на потом» / «не на эту неделю» — клади в конец секции # Week+, перед строкой-легендой.
5. Если пользователь явно просит «в начало», вставляй в начало блока открытых задач секции # Week:: сразу после последней - [x] и её подпунктов, перед первой открытой - [ ] / - [/]. Если в Week нет завершённых — сразу после заголовка # Week:.
6. Не создавай новых секций/заголовков, не переставляй существующие строки, не сортируй остальные задачи.

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

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

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

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

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

Пример:

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

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

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

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

• [[close-task]] — закрывает задачу и пишет итог в дневной лог.
• [[list-tasks]] — показывает открытые задачи, ищет старые и помогает с приоритетами.
• [[worklog]] — фиксирует факт в Log/YYYY-MM-DD.md. Запусти отдельно, если пользователь хочет ещё и запись в дневник.
• Если задача крупная и есть скилл decompose — после добавления имеет смысл предложить разбиение.

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

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

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