Kickoff

/kickoff — план запуска разработки

Четвёртый шаг пайплайна. На входе — утверждённые docs/00–05 и отчёт /audit с вердиктом READY или READY WITH CONDITIONS. На выходе — три файла в docs/: 07-kickoff.md — проектный план, инструкция для человека и для init-kickoff; init-kickoff.md и execute-kickoff.md — готовые агент-нейтральные инструкции, копируемые из шаблонов плагина как есть. Ни openspec/, ни AGENTS.md, ни zip этот шаг не создаёт — всё это делает init-kickoff уже внутри клонированного репозитория, где есть git и CLI.

Порядок развёртывания, который план описывает и которому подчинены все дальнейшие шаги:

1. Пользователь создаёт git-репозиторий и клонирует его (вручную).
2. Пользователь копирует docs/ целиком (00–07, STATUS.md, init-kickoff.md, execute-kickoff.md) в корень клона (вручную).
3. В корне клона говорит агенту — Claude Code, Codex или OpenCode — «выполни docs/init-kickoff.md»: создание структуры и файлов, openspec init для трёх агентов, changes, скил execute-kickoff из docs/execute-kickoff.md, коммит.
4. Запускает /execute-kickoff ($execute-kickoff в Codex) — столько раз, сколько changes: каждый запуск сам определяет текущий change и его состояние, доводит его до archive или до контрольной точки и останавливается. Если в текущей волне несколько changes, запуск в основном клоне открывает по git worktree и ветке change/NNN-name на каждый; пользователь запускает агента с /execute-kickoff в каждом worktree, а повторный запуск в основном клоне сливает и архивирует готовое.

Как задавать вопросы

Только через AskUserQuestion с 2–4 вариантами, рекомендуемый — первым с пометкой «(Recommended)». Развилки этого скила: выбор папки, «продолжать без актуального аудита или запустить /audit», число параллельных агентов (см. «Анализ параллелизма»), перезапись существующего docs/07-kickoff.md.

Где живут файлы

Как у остальных шагов: подключённая папка проекта → AskUserQuestion «Подключу папку сейчас (Recommended)» / «Работать в документах Project» → документы claude.ai Project + SendUserFile. Результат — docs/07-kickoff.md, docs/init-kickoff.md, docs/execute-kickoff.md рядом с остальными документами и обновлённый docs/STATUS.md.

Предусловия

1. docs/STATUS.md: exploration, BRD, TRD, SAD, SDD, DDD — approved; строка audit — READY или READY WITH CONDITIONS. Сверь «Проверенные версии» из шапки docs/06-audit-report.md с версиями в шапках документов: документ новее аудита — аудит устарел.
2. Аудит NOT READY, не проводился или устарел — остановись и спроси: «Сначала запустить /audit (Recommended)» / «Продолжить kickoff без актуального аудита». При «продолжить» — вынеси в план раздел «Запуск без прохождения аудита» со списком известных рисков; молча пропускать проверку нельзя.
3. Условия из READY WITH CONDITIONS переносятся в план с указанием, до какого change их закрыть.

Что читать

Только то, из чего состоит план: DDD §7 (changes CH-xx — основа дорожной карты), §6 (как поднять локально, деплой — для §1 и §4 плана), §9 (DoD), §10 (ветки/коммиты); SAD §4 (стек — для таблицы предварительных требований) и §7 (целевое окружение, путь доставки сборки, внешние сервисы); SDD §8 (переменные окружения — для §4 плана); SDD §1 — только колонки ID модуля и «Реализует FR» (для колонки «Модули» дорожной карты и анализа параллелизма); TRD §4 — только чтобы сверить, что у NFR развёртываемости есть ID для 000; отчёт аудита §1 и §4 (вердикт, условия); BRD §1 (название и одно предложение о продукте); exploration §7 — список capabilities; риски — из отчёта аудита, SAD §9 и TRD §9. TRD §3, SDD §2–§7, §9 и DDD §2–§5, §8 не читай: они нужны init-kickoff, а не плану. Ничего не придумывай: пробел в документах — открытый пункт в §7 плана, не догадка.

docs/07-kickoff.md

По-русски, плотно: таблицы вместо прозы, ссылки на файл и раздел вместо пересказа. Ориентир — до ~120 строк. Шапка как у остальных документов (версия, дата, вердикт аудита и его дата). Разделы:

1. Порядок развёртывания — четыре шага выше, с конкретикой проекта: команды git clone, что именно копировать в docs/, где и как запускать «выполни docs/init-kickoff.md» и /execute-kickoff. Предварительные требования таблицей: git, Node.js LTS, OpenSpec CLI (npm install -g @fission-ai/openspec@latest), хотя бы один агент (Claude Code / Codex / OpenCode) с командой установки, плюс стек проекта из SAD §4 и §7 (runtime, БД, Docker, CLI облака) — с командами проверки версий.
2. Дорожная карта changes — таблица: №, NNN-change-name, CH-xx, capabilities, FR/NFR, модули M-xx, зависит от, волна, оценка, условия аудита. Первая строка всегда 000-walking-skeleton, вторая — 001-project-foundation. Это контракт для init-kickoff: он создаёт каталоги ровно по этой таблице. Сразу под таблицей — подраздел 2а. Волны выполнения (см. «Анализ параллелизма»).
3. Целевое окружение и walking skeleton — из SAD §7: какое окружение целевое, как в него попадает сборка (ручной деплой допустим), что значит «приложение отвечает» (URL и ожидаемый ответ, /start в мессенджере, установка на устройство, --version), что для этого нужно от человека заранее (аккаунт, доступ, домен).
4. Окружение — переменные окружения из SDD §8 (имя, назначение, где взять — без значений), внешние сервисы из SAD §7, как поднять локально из DDD §6.
5. Контрольные точки — где execute-kickoff обязан остановиться и ждать человека: проверка 000 в целевом окружении (всегда), передача секретов, ручные действия во внешних сервисах, решения, отмеченные в аудите как «принять до CH-xx». Каждая — с change, к которому относится, и с тем, что человек должен принести назад (URL, значение, решение).
6. Правила — EARS-шаблоны для новых требований, DoD (DDD §9), слои Clean Architecture и линтер/форматтер (DDD §10 — ссылкой, без пересказа; это обязательные соглашения пайплайна, init-kickoff перенесёт их в AGENTS.md), ветки/коммиты (DDD §10), что нельзя менять без ADR.
7. Открытые условия и риски — условия из отчёта аудита §4, риски из SAD §9 и TRD §9, не распределённые требования из DDD §7 — каждый с change, до которого закрыть.
8. Чек-лист первого дня — 10–15 пунктов с чекбоксами: репозиторий создан и склонирован, docs/ скопирована, init-kickoff выполнен и коммит есть, openspec validate --all --strict зелёный, 000-walking-skeleton заархивирован и приложение отвечает в целевом окружении, 001 заархивирован…

Анализ параллелизма

Цель — показать, какие changes можно вести одновременно несколькими агентами и сколько это экономит. Колонка «Волна» — контракт: init-kickoff переносит её в proposal.md каждого change строкой - Wave: N, а execute-kickoff по ней выбирает режим — волна из одного change идёт последовательно, волна из нескольких — в параллельных worktree. Анализ делается всегда; его результат — колонки «Модули M-xx» и «Волна» в §2 и подраздел §2а. Ориентир на §2а — до ~25 строк сверх общего лимита плана.

Входные данные. «Зависит от» и «Оценка» — из DDD §7. «Модули M-xx» для change — все модули из SDD §1, у которых «Реализует FR» пересекается с FR/NFR этого change; для 000 и 001 пиши «все (каркас)». FR change, не реализуемый ни одним модулем SDD §1, — открытый пункт §7 плана, а сам change считается конфликтующим со всеми (в волне один).

Два вида конфликта. Changes нельзя вести параллельно, если (а) один зависит от другого, прямо или транзитивно, или (б) их множества модулей пересекаются. Пересечение должно быть именно пустым: design.md дальних changes пишется по реально существующему коду, а кода соседей по волне ещё нет. Общие файлы, которые правит почти любой срез (миграции БД, реестр маршрутов, DI-контейнер, навигация, манифест зависимостей — конкретные пути из DDD §1), конфликтом не считаются, но перечисляются в §2а как «файлы с очередью»: их правят по одному change за раз при слиянии волны.

Построение волн.

1. Волна 0 — только 000, волна 1 — только 001. Параллелизм начинается с волны 2.
2. В очередную волну попадают changes, у которых все зависимости лежат в предыдущих волнах; среди них жадно, по возрастанию CH-xx, набирается множество с попарно не пересекающимися модулями. Не поместившиеся уходят в следующую волну.
3. Change с контрольной точкой из §5, требующей человека (секреты, ручные действия во внешних сервисах, решение «принять до CH-xx»), остаётся в своей волне, но помечается «‖ стоп»: волна не закрывается, пока точка не снята, поэтому при равном выборе ставь такой change в волну поуже.
4. Ширина волны ограничена числом агентов: execute-kickoff откроет worktree на каждый change волны, и волна шире числа агентов только создаст простаивающие ветки. Сначала посчитай волны без ограничения и найди наибольшую ширину W. Затем спроси один раз через AskUserQuestion: «Сколько агентов будут выполнять план одновременно?» — варианты «1 — последовательно», «2», «3», «4 и больше»; первым и с пометкой «(Recommended)» ставь вариант, равный W (при W ≥ 4 — «4 и больше»), в описании вопроса назови W и экономию при ней. Если W = 1, вопрос не задавай: параллелить нечего. После ответа пересобери волны с этим ограничением. При ответе «1» каждый change получает собственную волну (в колонке «Волна» — 0, 1, 2, 3 … подряд), а в §2а остаётся таблица волн без ограничения с пометкой «справочно, план собран для одного агента».
5. Нумерация согласована с волнами: у всех changes волны N номера NNN меньше, чем у любого change волны N+1; внутри волны — по возрастанию CH-xx. Если порядок DDD §7 этому противоречит, перенумеруй NNN (CH-xx не трогай) и отметь это одной строкой под таблицей. 002 при этом остаётся за CH-02: init-kickoff пишет design.md и tasks.md именно для 000–002 по DDD §2–§4 и §8. Так числовой порядок остаётся корректной топологической сортировкой: план можно выполнить и одним агентом, проходя worktree волны по очереди.

Подраздел §2а плана содержит:

• таблицу волн: волна, changes, сумма оценок, длительность волны (максимальная оценка в ней), «‖ стоп», если есть;
• критический путь — цепочка changes по зависимостям с наибольшей суммой оценок;
• три числа: длительность последовательно (сумма всех оценок), параллельно при выбранном числе агентов (сумма длительностей волн), экономия в процентах. Оценки S/M/L переводи в условные единицы 1/2/4, если DDD §10 или §7 не задаёт своих; шкалу назови в одной строке;
• «файлы с очередью» — списком путей;
• вердикт одной строкой: экономия ≥ 25 % и есть хотя бы одна волна шириной ≥ 2 — «параллельное выполнение оправдано, волны N–M»; иначе — «выполнять последовательно: критический путь составляет X % плана, накладные расходы на ветки и слияние не окупаются»;
• порядок работы с параллельной волной, 3–4 строки для человека: /execute-kickoff в основном клоне создаёт worktree ../<repo>-wt/NNN-name и ветки change/NNN-name; в каждом worktree запускается свой агент с /execute-kickoff до отметки VERIFIED; повторный /execute-kickoff в основном клоне сливает готовые ветки по одной в числовом порядке, гоняет полный набор тестов, архивирует и удаляет worktree; следующая волна начинается, когда заархивирована вся текущая. Конфликт вне «файлов с очередью» возвращает change его воркеру на синхронизацию.

Ничего не придумывай и здесь: нет оценки у change — считай его как M и отметь в §7; нет модулей — см. выше.

Шаблоны init-kickoff.md и execute-kickoff.md

Лежат рядом с этим SKILL.md в templates/ (каталог скила известен из вызова; иначе — find ~/.claude/plugins -path '*/skills/kickoff/templates/init-kickoff.md'). Они проектно-независимы: всё проектное берут из 07-kickoff.md, AGENTS.md и openspec/. Копируй их в docs/ как есть — cp, не читая в контекст и не адаптируя. В режиме Project-документов файловой системы нет: прочитай оба шаблона и запиши через project_write под путями docs/init-kickoff.md и docs/execute-kickoff.md дословно — это единственная цена такого режима.

Проверка

• Каждая строка дорожной карты имеет CH-xx из DDD §7, зависимости не образуют цикла, 000 не зависит ни от чего, 001 — только от 000.
• Волны: у каждого change волна строго больше волны любой его зависимости; внутри волны модули попарно не пересекаются; ширина волны не больше выбранного числа агентов (при «1» — ровно один change на волну); волны 0 и 1 содержат только 000 и 001; номера NNN не убывают по волнам; 002 соответствует CH-02. Числа в §2а пересчитываются из таблицы §2 и сходятся.
• Каждое Must/Should FR/NFR, упомянутое в DDD §7, встречается в дорожной карте ровно один раз; не распределённое DDD требование — открытый пункт §7, не догадка.
• Для 000 назван ID NFR развёртываемости из TRD §4 или явно записано «NFR развёртываемости нет — change без спецификации (skip_specs: true), пункт в Open items README» — так же, как это делает init-kickoff.
• §5 содержит хотя бы контрольную точку для 000.
• docs/init-kickoff.md и docs/execute-kickoff.md побайтно совпадают с шаблонами (diff), если файловая система есть.

Завершение

1. Запиши docs/07-kickoff.md и скопируй шаблоны; если какой-то из файлов уже есть — AskUserQuestion: «Перезаписать» / «Сохранить рядом с суффиксом» / «Пропустить».
2. docs/STATUS.md: строка kickoff — ready, дата.
3. В чате — итог в шесть строк: сколько changes и волн, вердикт по параллелизму с процентом экономии, какие контрольные точки, сколько открытых условий, и первый шаг пользователя — создать репозиторий, скопировать docs/ и сказать агенту «выполни docs/init-kickoff.md». План не пересказывай.

Чего не делать

• Не создавать openspec/, CLAUDE.md, AGENTS.md, README, zip — это init-kickoff, в репозитории.
• Не редактировать шаблоны init-kickoff.md и execute-kickoff.md под проект — всё проектное живёт в 07-kickoff.md.
• Не генерировать спецификации и задачи — план ссылается на TRD/DDD по ID, копировать формулировки не нужно.
• Не дробить и не склеивать changes ради более широких волн: состав changes задан DDD §7, анализ только раскладывает их по волнам и, при необходимости, перенумеровывает NNN.
• Не раздувать 000-walking-skeleton до каркаса: без БД, auth, CI и тестов — только запуск в целевом окружении.
• Не переводить EARS-формулировки и не переформулировать их — они утверждены в TRD.
• Не начинать реализацию и не выполнять docs/init-kickoff.md в папке документов — там нет репозитория.
• Не задавать вопросы обычным текстом — только AskUserQuestion с вариантами.