/sdlc-milestones

name: sdlc-milestones
description: Вехи разработки по плейбуку Anthropic «AI-native SDLC» поверх оркестрации агентов — шесть стадий (Plan, Design, Build, Test, Deploy, Maintain), на каждой коммит артефакта (intent.md, spec.md, plan.md, дифф с выводом проверки, PR с ревью, инцидент) и ворота, кто его принимает. Применять при старте фичи или изменения кода, перед наймом исполнителя, перед PR и вливанием, при инциденте, по «зафиксируй веху», «на какой стадии задача», «intent.md», «spec.md», «plan.md», /sdlc-milestones.

Вехи AI-native SDLC

Источник: [The AI-Native SDLC Playbook](https://cdn.prod.website-files.com/6889473510b50328dbb70ae6/6aba736348bdf4f08183f463_AI%20Native%20SDLC%20Playbook_designv2%20(1).pdf), Louis Claxton, Anthropic. Ниже пересказ, приложенный к работе с агентами; за формулировками и примерами идите в оригинал.

Скилл не говорит, как нанимать агентов: это делает ваш режим оркестрации (например, [harness](../harness/SKILL.md) или [fable-ruki-agenty](../fable-ruki-agenty/SKILL.md)). Он говорит, какой артефакт должен лечь в git до перехода к следующей стадии.

Главная мысль плейбука: каждая стадия кончается коммитом артефакта, который читает следующая стадия; цепочка коммитов и есть журнал аудита — кто попросил, что сделал агент, кто одобрил. Внимание человека стоит на воротах: он принимает артефакт, подготовленный агентом, и не начинает стадию с нуля.

Роли

• **Владелец задачи** — человек, который ставит задачу и принимает ворота 1, 2 и 5 (вливание и прод).
• **Планировщик-лид** (вехи 1–3) — агент, который пишет intent.md, spec.md и plan.md, носит их владельцу на принятие, нанимает исполнителя только после закоммиченного plan.md и сверяет вехи скриптом. Отдельного агента нет — эту роль берёт оркестратор сессии или встроенный агент планирования харнеса (в Claude Code — `Plan`).
• **Исполнитель** — агент в своём worktree, работает по plan.md.
• **Ревьюер** (вехи 4–5) — агент, который не писал этот код: сверяет дифф с plan.md, требует вывод проверки в PR и порядок «падающий тест, потом починка», ставит одобрение, после которого PR видит владелец.
• Веха 6 и веха 1 следующего круга снова у планировщика-лида: диагноз инцидента он оформляет новым intent.md.

Где лежат артефакты

В репо, где живёт код задачи, папка `intent/<YYYY-MM-DD>-<slug>/`:

intent/2026-11-03-claims-status/
  intent.md    # веха 1 — что и зачем, словами автора
  spec.md      # веха 2 — требования и дизайн, спорные места
  plan.md      # веха 3 — файлы, порядок, риски, чем доказано
  lessons.md   # веха 6 — только если был инцидент

Шаблоны — `templates/`. Дифф, тесты и ревью живут в PR. Issue задачи ссылается на папку; в issue после каждой вехи строка `Веха N · <артефакт> · <sha>` (как вести issue — скилл [manager](../manager/SKILL.md)).

Масштаб. Правка в один-два файла без решений по дизайну проходит короткой цепочкой: замысел — в теле issue, план — в описании PR, вехи 4–5 обязательны. Полная папка — для фичи, нового модуля, изменения данных, денег, доступа или всего, что трогает несколько репо.

Шесть вех

| # | Стадия | Артефакт в git | Кто пишет | Ворота: кто принимает | Запускает | |---|---|---|---|---|---| | 1 | Plan | `intent.md` | планировщик-лид со слов владельца | владелец правит и принимает | веху 2 | | 2 | Design | `spec.md` рядом с intent | планировщик-лид по скиллам-политикам | владелец решает спорные места | plan mode | | 3 | Build | `plan.md`, затем дифф | планировщик-лид в plan mode, исполнитель в worktree | планировщик-лид сверяет план; высокий риск — владелец | исполнителя | | 4 | Test | вывод проверки в PR | исполнитель, свежий verifier | ревьюер: проверка зелёная, вывод вставлен | PR | | 5 | Deploy | PR с находками ревью | ревьюер, редакторы | одобрение ревьюера, вливает владелец; прод — по слову владельца | выкладку | | 6 | Maintain | новый `intent.md` из инцидента + eval | агент мониторинга или дежурный | владелец: чинить сейчас, позже или отклонить | веху 1 |

1. Plan — замысел

1. Владелец говорит проблему своими словами; формальный язык не нужен. 2. Агент задаёт вопросы аналитика: рамки, кто затронут, ограничения, как выглядит успех, что не входит (по одному вопросу за раз — см. [grill-me](../grill-me/SKILL.md)). 3. Агент пишет `intent.md` по шаблону: Problem, Proposed outcome, Affected users and systems, Constraints, Open questions; автор и статус в шапке. 4. Владелец правит то, что агент понял неверно. Его решение с датой — в intent.md. 5. Коммит в репо задачи. Веха закрыта, когда intent.md в `origin/main` или в принятом PR.

2. Design — спека

1. Агент читает принятый intent.md и пишет `spec.md`: требования и дизайн одним проходом, в рамках скиллов-политик проекта (бренд и вёрстка, правила текста, безопасность, данные людей). 2. Спорные места — отдельный раздел: где политики противоречат друг другу или intent.md молчит. Каждое — вопрос владельцу нумерованным пунктом. 3. Открытые вопросы intent.md закрыты или явно перенесены. 4. Коммит spec.md рядом с intent.md. Пара фиксирует, что просили и что решили. 5. Принятие spec.md владельцем запускает веху 3; без него сборка не начинается.

3. Build — план и сборка

1. Планировщик-лид в plan mode читает intent.md, spec.md и код, ничего не меняя, и пишет `plan.md`: Files that change, Order of work, Risks, Proof. 2. Допрос плана: что сломается, какой шаг самый рискованный, какие варианты отброшены и почему. 3. План готов, когда исполнитель, не видевший разговора, реализует его по одному файлу. Коммит plan.md до первой строки кода. 4. Исполнитель работает в своём worktree по плану. Разошёлся с планом — правит plan.md в том же коммите. 5. Знание проекта — в `AGENTS.md`/`CLAUDE.md` репо: команды сборки, тестов, линтера, соглашения, «что агент делает не так». Агент дважды ошибся одинаково — правка идёт в AGENTS.md, не в бриф. 6. Повторяющееся единообразное знание оформляется скиллом; то, что должно выполняться без исключений, подпирается хуком (защищённые пути, секреты в диффе, форматтер).

4. Test