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

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

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

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

**Определение канона — [канон](../canon/references/canon.md).** Прочитай его до
первого вопроса: интервью идёт по слотам канона, а не по вкусу. Что класть в
каждый файл — [скелеты](../canon/references/skeletons.md); не выдумывай заглушки
своей формы, `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. Заведи скелет остальных по [скелетам](../canon/references/skeletons.md) —
   каждый с честной строкой.
7. Каталог задач и первые цели — **вызови скилл `av-dev-tasks:tasks`**: он владеет
   форматом целей и задач. Не разрешился — учёт задач остаётся владельцу, и это
   тоже строка доклада.
8. `docs.py check` из скилла `canon` — до отсутствия дрейфа. Замечания о
   незаполненных плейсхолдерах остаются: их закрывает не `init`, а работа.
9. Покажи человеку, что получилось, и **отдельным списком** — что выведено из
   брифа, что предположено, что осталось неизвестным. Правят по этим строкам.

## Что дальше

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

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

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