dev-skills/backlog/skills/av-dev-backlog/SKILL.md

---
name: av-dev-backlog
description: Работа с беклогом задач как с каталогом markdown-файлов (одна задача = один файл + строка в индексе README). Заведение задачи из диалога, разбор находок аудита/ревью в задачи, груминг (интерактивная чистка неактуального), приоритизация, декомпозиция на независимо полезные части, мозговой штурм идеи. Использовать, когда просят добавить задачу/идею в беклог, превратить находки ревью в задачи, разобрать беклог, расставить приоритеты, разбить задачу или проработать идею. Не реализует задачи — этим занимается пайплайн задачи проекта.
---

# Беклог

Беклог — каталог markdown-файлов: одна задача = один файл `<slug>.md`, плюс
строка в индексе `README.md`. Скилл ведёт беклог: заводит, чистит, приоритизирует,
дробит, штурмует идеи. **Реализацией не занимается** — это дело пайплайна задачи.

## Три правила, из которых всё следует

Ситуация не покрыта инструкцией — решай по ним.

1. **Беклог гниёт с той стороны, где его пополняют.** Заведение — самая частая
   операция и с худшим отказом: из одного разговора рождается пять файлов, и
   груминг потом разгребает то, чего не надо было заводить. Дедупликация и фильтр
   на входе дешевле любой чистки. Заводим только то, что **не делаем сейчас** и о
   потере чего пожалеем.
2. **Файл — источник истины, индекс производен.** Разошлись — неправ индекс.
   Согласованность механизируема и проверяется командой, а не вниманием: всё, что
   ловит `backlog.py check`, не должно попадать ни в чек-лист, ни в промпт.
3. **Причина переживает запись.** Приоритет без причины будет переспорен на
   следующем груминге; выкинутая без причины задача вернётся через квартал тем же
   текстом. Реализованная задача оставляет след в коммите и спеке — выкинутая не
   оставляет ничего, поэтому у неё есть кладбище.

## Инструмент (`backlog.py`)

Пусть `bl="$CLAUDE_PLUGIN_ROOT/skills/av-dev-backlog/scripts/backlog.py"`.

```
python3 $bl check                       # согласованность + метрики здоровья, exit 1 при расхождениях
python3 $bl check --fix                 # + починить безопасный дрейф (секция, заголовок, дубли)
python3 $bl list --stale                # от самой залежавшейся; ещё --priority --type --tag
python3 $bl add --slug S --title T --priority P [--type idea|epic] [--hook H] [--reason R] [--tag a,b]
python3 $bl edit S [--title T] [--hook H] [--type idea|epic|task]   # переименовать / сменить хук, тип
python3 $bl move S --priority P [--reason R]     # перенести в другую секцию
python3 $bl close S --reason R          # на кладбище + удалить (выкинута)
python3 $bl close S --implemented       # просто удалить (реализована, есть коммит)
python3 $bl init [--sections "..."]     # завести беклог в новом проекте
```

Тип задачи — английское ключевое слово `idea` / `epic` / `task` (как и прочие
токены команд); `task` префикса не несёт, `idea`/`epic` кодируются `[idea]`/
`[epic]` в заголовке. Текст задачи при этом русский.

**Мутации правят файл и индекс заодно** — руками строку индекса или мета-строку
не пиши, зови `add`/`edit`/`move`/`close`. Смена заголовка, хука или типа (в том
числе понижение задачи до `[idea]`) — это `edit`, а не ручная правка H1 и
индекса: `edit` держит их в синхроне. Механика (слаг в имени, секция по
приоритету, формат кладбища, экранирование ввода) не может рассогласоваться,
потому что её делает скрипт. Тело задачи скрипт не трогает — `add` кладёт
заголовок, мета-строку и плейсхолдер, а контекст, шаги и ссылки ты дописываешь
редактором (пока плейсхолдер на месте, `check` напоминает, что тело не дописано).

`check` — единственный судья согласованности; что именно он ловит, скажет его
вывод, здесь не пересказываем. Гоняй его **в начале сессии** и **после каждой
правки**, даже если правил мутациями: дрейф мог накопиться раньше. Накопившийся
дрейф чини `check --fix` — он детерминированно правит безопасное (секция по файлу,
заголовок из H1, дубли строк), а неоднозначное (ссылка на исчезнувший файл,
битые строки) выносит тебе. Это идёт строкой доклада.

Формат файла, мета-строки, слага, индекса и кладбища —
[references/task-format.md](references/task-format.md). Там же тест «готова к
взятию».

## Сценарии

### Завести задачу или идею из диалога

1. **Фильтр.** Делаем прямо сейчас — не заводим. Не пожалеем о потере — не
   заводим. Родилось три кандидата — покажи их и спроси, какие заводить: молча
   заведённая пачка и есть тот самый отказ из правила 1.
2. **Дедуп.** `list` плюс поиск по слагам, хукам и телам (`grep -ril`), **включая
   `CLOSED.md`**. Нашлось в беклоге — **дописываем в существующий файл**, а не
   заводим соседний. Нашлось на кладбище — покажи пользователю ту строку и что
   изменилось с момента отказа: та же идея вернулась через диалог, а не через
   ревью. Две задачи об одном — самая дорогая находка груминга.
3. **Тип по тесту готовности** (см. task-format): проходит — задача (`--type task`,
   без префикса), не проходит — идея (`--type idea`), проходит по пользе, но не
   делается одним заходом — эпик (`--type epic`, сперва декомпозиция).
4. `add --slug … --title … --priority … --hook …` (тип, причину, теги — по
   месту). Хук отвечает «почему это в беклоге», а не пересказывает первый абзац.
   Затем допиши тело файла.
5. `check`.

### Разобрать находки аудита или ревью

Ревью и аудиты — код-ревью, архитектурный проход, аудит безопасности — тоже
источник задач, но с зеркальной диалогу опасностью: не пять файлов из одной
мысли, а сорок файлов из сорока сырых находок. Защита та же, что в самом ревью:
кластеризация по причине, дедуп против беклога, находка без свидетельства → идея,
а не задача, и карта кластеров пользователю до создания файлов. Порядок и
отображение серьёзности — [references/from-review.md](references/from-review.md).

### Груминг

Интерактивная сессия порциями, по дате правки из git и с правилом остановки —
[references/grooming.md](references/grooming.md). Ключевое: перед вопросом
пользователю проверь по коду и спекам, не сделано ли уже попутно, — это самая
частая находка и она не требует ничьего решения.

### Приоритизация

Приоритет — грубая оценка «ценность / стоимость», не обязательство к порядку.
Никаких очков и часов: уровни те, что есть в секциях индекса.

- Меняешь уровень — `move <slug> --priority <новый> --reason <причина>`; причина
  уезжает в мета-строку.
- Повышаешь — назови, **что именно эта задача обгоняет**. Повышение без
  проигравшего это не приоритизация, а согласие с последним, кто говорил.
- Задача, давно лежащая в нижней секции и не двигавшаяся (по дате git), —
  кандидат на кладбище, а не на новый круг «оставить как есть».

### Декомпозиция и штурм идеи

[references/split.md](references/split.md). Обе операции превращают одну запись в
несколько, и у обеих есть проверяемый тест: части должны **мерджиться порознь** и
**каждая давать видимую пользу**, а у штурма исход «выкинуть» — полноправный.

## Общее для всех сценариев

- **Кладбище.** Задача уходит из беклога без реализации → `close <slug> --reason
  <причина>`: скрипт пишет строку в `CLOSED.md` (дата, слаг, заголовок, причина,
  бывший приоритет) и удаляет файл со строкой индекса. Реализованные туда не идут
  — у них есть коммит, спека и ADR; для них `close <slug> --implemented`.
- **Границы покрытия в отчёте.** Любая сессия груминга, приоритизации или штурма
  заканчивается строкой «просмотрено N из M, не трогали — …». Отчёт без неё
  сообщает «беклог разобран», не сообщая, какая его часть осталась нетронутой.
- **Развилки — пользователю.** Через `AskUserQuestion`, с уже сформулированным
  предварительным суждением (рекомендация — первым вариантом). Что выкинуть, что
  повысить, какая рамка идеи верна — решение пользователя. Слаг, формулировка,
  порядок строк в индексе — механика, делаем сами.
- **Не больше трёх вопросов за раз.** Пачка длиннее трёх тяжела для ответа;
  решений больше — веди **несколько итераций** диалога по ≤3, а не один
  перегруженный запрос. Между итерациями применяй уже решённое.
- **Ничего не удаляем молча.** Файл задачи исчезает только через `close` —
  `--reason` (выкинута) или `--implemented` (реализована). Прямого `rm` нет.

## Переносимость

Скилл независим от **языка программирования, сборки, CI и трекера**: он ничего не
знает ни про Go, ни про npm, ни про конкретный багтрекер — беклог для него просто
каталог markdown. Текст задач — русский (язык документации проекта); зашита только
латиница слага.

- **Каталог беклога**: аргумент → указатель в `CLAUDE.md` проекта → поиск
  (`docs/backlog`, `backlog`, `doc/backlog`, `docs/tasks`). Не нашёлся — это новый
  проект: `init` заводит индекс и кладбище (секции по умолчанию высокий/средний/
  низкий, `--sections` переопределяет).
- **Слаг** — латиница kebab-case всегда; заголовок, тело, хук — по-русски.
- **Уровни приоритета** берутся из заголовков секций индекса как есть, их
  количество и названия — дело проекта.
- **Имена служебных файлов** (`README.md` — индекс, `CLOSED.md` — кладбище)
  фиксированы скиллом, не проектом.

Проектные тонкости (куда переезжает суть реализованной задачи, кто удаляет файл,
как беклог связан с трекером-инбоксом) описаны в `CLAUDE.md` проекта — прочитай
его перед работой.

## Чего этот скилл не делает

Не пишет код, не заводит спеки и change, не берёт задачу в работу — этим
занимается пайплайн задачи проекта, а этот скилл владеет только форматом и
содержимым беклога. Не решает за пользователя, что важно. Не переоформляет
существующие задачи «заодно»: правится то, чего касается операция.