| name | backlog |
| description | Завести задачу в беклог проекта (vault). Используй, когда пользователь говорит «добавь в беклог», «заведи задачу», «запиши задачу» или описывает дело, которое надо не потерять. |
| user_invocable | true |
backlog
Превратить мысль пользователя в одну хорошо описанную задачу в vault — с приоритетом, номером и всеми разделами. Этот файл самодостаточен: его можно дать любому агенту, и он выполнит задачу целиком.
Шаг 0 — прочитай правила
Прочитай _rules.md в корне vault (папка с CLAUDE.md и projects/). Ниже — компактный контракт, нужный для этого навыка; _rules.md уточняет общие конвенции.
Контракт задачи
Файл: projects/<slug>/tasks/<имя>.md, где <slug> — папка проекта, <имя> — короткое kebab-case на английском (search-entries.md).
Frontmatter:
---
id: <число>
project: "[[<slug>/<slug>]]"
status: todo
tags: [task]
created: <сегодня YYYY-MM-DD>
created_at: <ISO datetime создания>
updated: <сегодня YYYY-MM-DD>
closed_at:
sp: <1|2|3|5|8|13>
rice_reach: <1–10>
rice_impact: <1–5>
rice_confidence: <50–100>
rice_effort: <sp / 5, минимум 0.1>
summary: "<одна строка для индексов и дашборда>"
roles: [<выведи из RICE — см. «Роли»>]
model_tier: <junior|middle|senior — по sp: ≤2 junior, 3–5 middle, ≥8 senior>
---
RICE = (reach × impact × confidence/100) / effort — больше = важнее.
Как назначить id
Найди максимальный id среди всех projects/*/tasks/*.md и прибавь 1. Способ (если есть shell): grep -rhoE '^id:\s*[0-9]+' projects/*/tasks/ | grep -oE '[0-9]+' | sort -n | tail -1. Иначе — прочитай файлы задач и возьми max+1. Номера не переиспользуются и не пропускаются.
Калибровка RICE (якоря)
Оценки грубые — их задача отделить важное от неважного, а не спорить о 3.2 против 3.6.
- reach (1–10) — как часто/широко встречается эффект.
1–2 редкий кейс (раз в месяц, единичные случаи); 3–5 заметно и регулярно; 6–8 частый сценарий; 9–10 ежедневно / почти всегда.
- impact (1–5) — сила влияния на цель проекта.
1 косметика; 2 небольшое улучшение; 3 ощутимая польза; 4 сильно двигает ключевую метрику; 5 критично (риск, блокер, ядро продукта).
- confidence (50–100) — уверенность в оценках выше.
50–60 гипотеза, мало данных; 70–80 разумная уверенность; 90–100 проверено или очевидно.
- effort — выводится из
sp: sp / 5, минимум 0.1. Сам effort отдельно не выдумывай (см. «Story Points»).
Story Points (SP)
sp — первичная оценка размера задачи по шкале Фибоначчи. Это не время: у людей валюта — время, у ИИ-агента — токены. SP отвязан от часов; velocity ИИ = токены / SP (метрика «стоимость 1 SP», см. методологию — Тиринг моделей).
Якоря (оценивай относительный размер, не часы):
| SP | Размер |
|---|
| 1 | тривиально, механически, чёткий DoD — мелкий фикс, правка текста/конфига, однострочник |
| 2 | простая понятная задача, один компонент, путь очевиден |
| 3 | средняя: несколько шагов, как делать — ясно |
| 5 | крупная: есть неочевидное, несколько компонентов/файлов |
| 8 | большая или с неопределённостью → подумай о декомпозиции |
| 13 | слишком большая/мутная → декомпозируй обязательно, не бери как есть |
sp ≥ 8 — сигнал разбить задачу на подзадачи. Существующие задачи с est_days не трогаются (переходный период); новые заводятся в sp.
Роли (Огород)
Из компонентов RICE выведи roles — какие роли команды включаются на задаче (методология — docs/roles.md):
reviewer — всегда (корректность + полнота; углубляется при impact ≥ 4);analyst — если confidence ≤ 60 (мутная задача: уточнить постановку до старта);techwriter — если reach ≥ 6 (внешняя дока) или задача меняет архитектуру/контракт (внутренняя дока);developer — исполнитель, подразумевается (можно не указывать).
Пример: задача с reach 7, impact 4, confidence 65 → roles: [reviewer, techwriter]. Мелкая правка без RICE → roles: [reviewer].
Грейд модели (Огород)
Назначь model_tier — грейд модели, который по умолчанию возьмёт задачу. Плановый грейд выводится из размера задачи (sp). Три грейда вендоронейтральны (маппинг на конкретные модели — в адаптере инструмента); методология — раздел «Тиринг моделей» в docs/methodology.md.
junior — sp ≤ 2 (мелкие, механические)middle — sp 3–5 (дефолт, средние)senior — sp ≥ 8 (крупные, сложные)
Грейд — плановый: при исполнении возможна эскалация на ступень вверх (junior → middle → senior). Через эскалацию ловится рассуждательная сложность: мутная мелкая задача (низкий confidence/смена архитектуры) поднимается выше планового по размеру. Границы sp стартовые, самокалибруются по доле эскалаций.
Пример: sp 2 → model_tier: junior; sp 5 → middle; sp 8 → senior.
Подъём грейда при заведении. Если в roles входит techwriter (задача влияет на
архитектуру/контракт) ИЛИ analyst при confidence ≤ 60 — повысь плановый
model_tier на ступень вверх (junior→middle, middle→senior) и зафикси причину в
«Заметках». Аудит показал систематическое занижение архитектурных задач в junior
при чисто-sp-выводе.
Стиль описания (что значит «классно описанная задача»)
- Коротко и конкретно, без воды. Задача — не спецификация.
summary — одна строка, по делу; можно эмодзи-маркер (🐛 баг, 🚨 риск, ⚡ перф).- DoD = наблюдаемый результат, что станет ПРАВДОЙ, когда сделано (поведение/состояние), НЕ список действий. Неупорядоченный чек-лист — он же мера прогресса: отмеченные галочки = насколько готово. Антипример: «Зафиксированы ограничения по питанию» — действие в прошедшем времени; правильно: «Файл
preferences.md существует и содержит поля X, Y, Z» — проверяемое состояние.
- Плана как раздела нет. «Как делать» — внутренняя кухня исполнителя; если нужно записать шаги, они идут в «Заметки», пользователю не показываются.
- Сомнения и непонятности — в раздел «Вопросы» файла, НЕ в чат пользователю.
- Всё содержимое — на русском.
Разделы тела
## Что нужно сделать
<1–3 предложения, конкретно>
## Почему важно
<связь с целью проекта>
## Критерии готовности (DoD)
- [ ] <наблюдаемое состояние результата>
## Пререквизиты
<зависимости/блокеры или «нет»>
## Вопросы
<что прояснить до старта, маркированным списком; «нет», если вопросов нет — не оставляй пустой буллет>
## Заметки
<происхождение, контекст; для инбокса: Из инбокса <дата>: "<текст>">
Пример (вход → результат)
Вход от пользователя: «добавь в беклог: на странице со списком записей нет поиска по тексту, тяжело находить старые».
Создаётся projects/myapp/tasks/search-entries.md (id = max+1, допустим 42):
---
id: 42
project: "[[myapp/myapp]]"
status: todo
tags: [task]
created: 2026-06-12
updated: 2026-06-12
sp: 2
rice_reach: 6
rice_impact: 3
rice_confidence: 80
rice_effort: 0.4
summary: "Поиск по тексту в списке записей"
---
## Что нужно сделать
Добавить поле поиска над списком записей, фильтрующее по подстроке в тексте записи (без учёта регистра).
## Почему важно
Список растёт, найти старую запись прокруткой всё дороже — поиск делает историю пригодной для использования.
## Критерии готовности (DoD)
- [ ] Над списком есть поле поиска
- [ ] Ввод текста фильтрует список по подстроке без учёта регистра
- [ ] Пустой запрос показывает все записи
## Пререквизиты
нет
## Вопросы
- Искать только по тексту записи или ещё по тегам/дате?
## Заметки
Из разговора 2026-06-12.
Как взялась оценка RICE: ищут регулярно (reach 6), ощутимое удобство (impact 3), фича понятная и проверенная практикой (confidence 80), небольшая — один компонент (sp 2 → effort 0.4) → RICE ≈ 36.
Крайние случаи
- Проект неочевиден — выбери наиболее вероятный по тексту, а сомнение запиши в «Вопросы» задачи. Не спрашивай в чате.
- Не можешь оценить размер — поставь
sp по ближайшему аналогу (Фибоначчи) и отметь в «Вопросы», что оценка грубая.
- Это баг/инцидент — добавь тег
bug, в summary эмодзи 🐛, в «Заметках» — как воспроизвести.
- Vault — git-репозиторий — после создания файла:
git add -A && git commit && git push.
Самопроверка перед завершением
Что сообщить пользователю
Номер задачи (id), путь к файлу, посчитанный RICE — одной-двумя строками.
