Files
dev-skills/av-dev-docs/skills/init/SKILL.md
T
avandClaude Opus 5 00ddfb0dde av-dev-pm расколот на av-dev-docs и av-dev-tasks
Плагин владел двумя разными вещами сразу — документацией проекта и учётом работ,
— и это мешало обеим. Канон нельзя было поставить без задач, задачи без канона, а
язык проектных текстов лежал внутри скилла canon и потому принадлежал половине.
Теперь плагина два, каждый ставится сам по себе.

av-dev-docs: скиллы canon, docs, init; агенты doc-consistency, doc-code-drift,
doc-wording; скрипт docs.py. av-dev-tasks: скиллы tasks, session; агенты
task-form, task-wording; скрипт tasks.py.

Между собой они зовутся через пространство имён, а не по пути в чужое дерево.
Все относительные ссылки, пересекшие границу плагина, сняты: tasks больше не
указывает в canon, canon не указывает в tasks. Вместо ссылки — имя скилла и
оговорка, что вызов может не разрешиться, и это исход, а не поломка.

То, что нужно обоим дословно, стало вторым общим домом. Словарь «Сопровождение и
эксплуатация» назван в трёх местах трёх плагинов — секция роадмапа, раздел
«Эксплуатация» в architecture.md, тема ревью operations — и ни один из трёх им не
владеет; он уехал в shared/operations.md, а canon.md и скилл задач везут копии.
Три перечня «чем держат проект» уже разъезжались на «метриках и логах» против
«мониторинга», так что ссылка тут не годится: плагин, поставленный в одиночку,
получил бы указатель в никуда. Тем же способом язык: у av-dev-tasks появилась
своя копия language.md.

Копий стало 18 при 8 домах.

Переименования разведены по смыслу, а не заменой строки: где речь о каноне —
av-dev-docs, где об учёте задач — av-dev-tasks. В пайплайне таких мест
одиннадцать, и оба адресата там встречаются вперемешку.

Журналы (DECISIONS, TODO, HISTORY) намеренно не тронуты: они описывают состояние
на момент записи. По той же причине оставлена наблюдённая строка в комментарии
docs.py — она цитирует конфиг живого проекта, а не называет плагин.

Не входит в этот заход и названо отдельно: слияние canon и docs в один скилл,
разделение docs/.pm.json на два конфига и переезд openspec в пайплайн.

Гейт зелёный: копии, фронтматтеры, диаграммы, json. Оба скрипта прогнаны после
переезда — docs.py version и tasks.py check на фикстуре.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 14:06:26 +03:00

9.7 KiB
Raw Blame History

name, description
name description
init Завести новый проект — сессия вопросов и ответов по свободному описанию замысла, из которой рождается первичная документация по канону av-dev: паспорт, CLAUDE.md с инвариантами и командами, модель угроз с периметром, первые цели в роадмапе и скелет остальных документов. Заводит и OpenSpec (openspec init) с настроенным openspec/config.yaml — дом темы requirements, без которого не работают ни propose, ни ревью. Использовать, когда начинают новый проект с нуля, когда есть только текст «что мне нужно и почему» и надо превратить его в рабочую документацию, когда просят провести стартовое интервью по брифу. Проект, где документация уже как-то ведётся, переводит скилл canon.

Заведение нового проекта

Вход — свободный текст «что мне нужно и почему». Выход — канон документов, с которого дальше работают все остальные скиллы.

Определение канона — канон. Прочитай его до первого вопроса: интервью идёт по слотам канона, а не по вкусу. Что класть в каждый файл — скелеты; не выдумывай заглушки своей формы, docs.py узнаёт только плейсхолдер оттуда.

Что init физически не может произвести

В новом репозитории нет кода, а architecture.md, database.md, conventions/ и research/ выводятся из него. Сочинить их на старте — значит проектировать вперёд реальности, и написанное протухнет раньше первой задачи.

Поэтому init заполняет то, что человек знает до первой строки кода:

Заполняется Остаётся скелетом с честной строкой
passport.md architecture.md
CLAUDE.md database.md
security.md conventions/
docs/tasks/ROADMAP.md — первые цели research/, adr/
docs/.pm.json review.md — журнал пуст, настройка появится с первым ревью
openspec/config.yaml

Честная строка информативна, а не «TBD»: «архитектуры пока нет: кода нет, заводится первой задачей». Проход читает её как факт.

Порядок интервью — зависимость, а не удобство

Каждый блок опирается на ответ предыдущего; переставлять нельзя.

  1. Цель и потребители. Ради чего это; кто пользуется — список закрытый, и он определяет, что считать нужным, а что интересным.
  2. Чем это НЕ является и мера успеха. Граница домена — критерий, по которому потом судят в теме architecture о переносе понятия. Мера — по чему поймём, что удалось.
  3. Периметр и недоверенный вход. Открыт наружу или контур доверенный; что приходит извне и каким каналом; что чувствительнее чего. Контур ещё не развёрнут — назови оба периметра, целевой и сегодняшний.
  4. Стек, хранилище, необратимое. Чем пишем и почему; где данные; что в этом проекте нельзя откатить — деплой, выкладка наружу, перезапись данных.
  5. Чем краснеет гейт. Какие проверки обязательны; что красит безусловно; чего в гейте намеренно не будет и кто тогда это гоняет.
  6. Первые цели. Возможности приложения, а не задачи: три-пять целей в Запланировано, каждая — ответ на «что приложение будет уметь», с обоснованием очереди прозой.

Как вести

  • Не больше трёх вопросов за итерацию (AskUserQuestion), рекомендация первым вариантом. Между итерациями применяй уже решённое.
  • Сперва вычитай ответы из брифа. Если ответ уже есть в тексте, вопрос не задавай — покажи своё прочтение и спроси, верно ли.
  • Не выдумывай четыре вещи: периметр, что необратимо, измеренные числа и адресата дорогой проверки. Их из замысла не вывести. Не сказано — пиши «неизвестно» с пометкой, что ждёт ответа.
  • Развилка замысла — человеку, механика — сама. Имена файлов, слаги, порядок строк не выноси.

Порядок работы

  1. Прочитай бриф целиком. Выпиши, на какие блоки интервью ответ уже есть.
  2. Проведи интервью итерациями по ≤3 вопроса.
  3. Заведи OpenSpec: openspec init --tools claude. Каталог openspec/ — часть канона, а не соседняя технология: в нём дом темы requirements, и без него не работают ни opsx:propose, ни ревью дизайна, ни сверка требований. Команда кладёт ещё .claude/skills/openspec-* и .claude/commands/opsx/* — это её нормальная работа, не трогай их.
  4. Заведи docs/.pm.json с текущей версией канона.
  5. Напиши заполняемые документы. Бриф переезжает в passport.md и отдельным файлом не остаётся: два дома для одного замысла разойдутся на первом же уточнении.
  6. Заведи скелет остальных по скелетам — каждый с честной строкой.
  7. Заполни openspec/config.yaml по тем же скелетам. Файл из коробки — закомментированный пример на английском; он заменяется целиком, потому что нетронутый выглядит настроенным, а работает как пустой. Пиши туда только то, что нужно в момент порождения артефакта: язык, правила именования capability, придирки валидатора и адреса docs/passport.md и CLAUDE.md. Инварианты, конвенции и правило ревью не пересказывай — у них есть дома, и второй дом разойдётся с первым молча.
  8. Каталог задач и первые цели — вызови скилл av-dev-tasks:tasks: он владеет форматом целей и задач.
  9. docs.py check из скилла canon — до отсутствия дрейфа. Замечания о незаполненных плейсхолдерах остаются: их закрывает не init, а работа.
  10. Покажи человеку, что получилось, и отдельным списком — что выведено из брифа, что предположено, что осталось неизвестным. Правят по этим строкам.

Что дальше

  • Содержимое канона по ходу разработки ведёт скилл docs.
  • Раскладку проверяет canon check.
  • Первую задачу берёт пайплайн проекта; architecture.md и conventions/ наполняются его шагом синка, а не заранее.

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

  • Не проектирует систему. Архитектура выводится из кода, а не наоборот.
  • Не пишет код и не заводит сборку.
  • Не переводит существующий проект — это canon adopt. Признак: в репозитории уже есть документация или беклог в какой-то раскладке.
  • Не решает за человека, что важно: цель, границы и периметр — его ответы.