backlog

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: <число>                  # сквозной номер по всему vault: максимальный id + 1
project: "[[<slug>/<slug>]]" # wiki-ссылка на карточку проекта
status: todo
tags: [task]                 # + bug для багов/инцидентов: [task, bug]
created: <сегодня YYYY-MM-DD>
created_at: <ISO datetime создания>
updated: <сегодня YYYY-MM-DD>
closed_at:
sp: <1|2|3|5|8|13>           # Story Points — размер задачи (Фибоначчи), см. «Story Points»
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 = max существующего + 1, уникален
• Все 4 поля RICE — числа в своих диапазонах; rice_effort = sp/5; sp из Фибоначчи
• project — корректная wiki-ссылка на существующий проект
• DoD описывает наблюдаемый результат, а не действия
• Вопросы записаны в файл, а не заданы в чате
• Язык — русский; summary — одна ёмкая строка
• (если git) закоммичено и запушено

Что сообщить пользователю

Номер задачи (id), путь к файлу, посчитанный RICE — одной-двумя строками.