Files
dev-skills/backlog/skills/av-dev-backlog/SKILL.md
T
avandClaude Opus 4.8 a22a825c40 init: маркетплейс av-dev-skills + плагин backlog
Отдельный репозиторий-маркетплейс для личных плагинов и скилов разработки,
чтобы подключать их к проектам через `/plugin`, а не держать в глобальном
`~/.claude/skills`.

Первый плагин — backlog: перенесён скилл ведения беклога из
`~/.claude/skills/backlog` под именем `av-dev-backlog`. Путь к `backlog.py`
переведён с фиксированного `~/.claude/...` на `$CLAUDE_PLUGIN_ROOT`, чтобы
работать после установки плагина.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-24 08:45:32 +03:00

15 KiB

name, description
name description
av-dev-backlog Работа с беклогом задач как с каталогом 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. Там же тест «готова к взятию».

Сценарии

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

  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.

Груминг

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

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

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

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

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

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