# Kickoff

> Шаг 4 пайплайна разработки приложений: по прошедшей /audit документации пишет план запуска docs/07-kickoff.md — порядок развёртывания, дорожную карту changes (с нулевым walking skeleton), анализ параллелизма (волны выполнения и критический путь), контрольные точки, условия аудита, окружение — и кладёт рядом инструкции docs/init-kickoff.md (инициализация репозитория) и docs/execute-kickoff.md (шаблон скила выполнения плана). Триггеры: /kickoff, «подготовь проект к разработке», «составь план запуска».

- Skill: `oastashev/kickoff` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add oastashev/kickoff`
- Raw SKILL.md: https://api.skillmd.com/api/skills/oastashev/kickoff/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: oastashev (https://skillmd.com/u/oastashev)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/oastashev/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` с вариантами.