dev-skills/av-dev-docs/skills/init/SKILL.md

name, description

name

description

init

Завести новый проект — сессия вопросов и ответов по свободному описанию замысла, из которой рождается первичная документация по канону av-dev: паспорт, CLAUDE.md с инвариантами и командами, модель угроз с периметром, первые цели в роадмапе и скелет остальных документов. OpenSpec заводит не сам, а вызовом скилла av-dev-pipeline:openspec — каталог принадлежит конвейеру; плагина конвейера нет — шаг пропускается строкой доклада. Использовать, когда начинают новый проект с нуля, когда есть только текст «что мне нужно и почему» и надо превратить его в рабочую документацию, когда просят провести стартовое интервью по брифу. Проект, где документация уже как-то ведётся, переводит скилл 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 — журнал пуст, настройка появится с первым ревью

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

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

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

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

Как вести

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

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

1. Прочитай бриф целиком. Выпиши, на какие блоки интервью ответ уже есть.

2. Проведи интервью итерациями по ≤3 вопроса.

3. OpenSpec — вызови Skill av-dev-pipeline:openspec. Он заводит каталог и заменяет пример в config.yaml настройкой. Делается это до первого документа: без openspec/ не работают ни opsx:propose, ни ревью дизайна, ни сверка требований. Каталог принадлежит конвейеру, а не канону, поэтому здесь только вызов — ни команды, ни формы файла init не знает.

   Вызов не разрешился — плагина конвейера в проекте нет. Это законный исход, а не поломка: проект без конвейера живёт без OpenSpec. Скажи это строкой в докладе и иди дальше; docs.py check о каталоге тоже промолчит.

4. Заведи docs/.pm.json с текущей версией канона.

5. Напиши заполняемые документы. Бриф переезжает в passport.md и отдельным файлом не остаётся: два дома для одного замысла разойдутся на первом же уточнении.

6. Заведи скелет остальных по скелетам — каждый с честной строкой.

7. Каталог задач и первые цели — вызови скилл av-dev-tasks:tasks: он владеет форматом целей и задач. Не разрешился — учёт задач остаётся владельцу, и это тоже строка доклада.

8. docs.py check из скилла canon — до отсутствия дрейфа. Замечания о незаполненных плейсхолдерах остаются: их закрывает не init, а работа.

9. Покажи человеку, что получилось, и отдельным списком — что выведено из брифа, что предположено, что осталось неизвестным. Правят по этим строкам.

Что дальше

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

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

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