SDD-конвейер с агентами, от идеи до влитых тикетов — setup репозитория → интервью раундами с рекомендациями и макетами → спека в трекере → трассирующие тикеты → исполнители в свежих контекстах и своих worktree → линейное слияние, живая передача и приёмка «той же дверью». Use when the user wants a feature or product built end-to-end «по SDD», asks to «запусти разработку сам» after a design talk, or wants plan-then-build with agents. Orchestrates the mattpocock skills and does not replace them.
Installs into .claude/skills of the current project.
Are you the author of sdd?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/iulaijedi-sdd)
---
name: sdd
description: SDD-конвейер с агентами, от идеи до влитых тикетов — setup репозитория → интервью раундами с рекомендациями и макетами → спека в трекере → трассирующие тикеты → исполнители в свежих контекстах и своих worktree → линейное слияние, живая передача и приёмка «той же дверью». Use when the user wants a feature or product built end-to-end «по SDD», asks to «запусти разработку сам» after a design talk, or wants plan-then-build with agents. Orchestrates the mattpocock skills and does not replace them.
---
# SDD с агентами
Надстройка над конвейером mattpocock: `ask-matt` описывает сам поток, здесь — как его
вести. Оператор принимает решения одним «ок», факты добываются сами, вкус решается
глазами, реализацию делают агенты в свежих контекстах, а контроль остаётся у
человека. Ведущий набор на всё время работы — mattpocock; другие наборы не подмешиваются
(правило «один набор на задачу»: смешанный конвейер — известный источник
непредсказуемого поведения).
## Роли
- **Оператор** решает и принимает. Ему приносят одну рекомендацию, не меню; «ок» значит
«принято всё».
- **Координатор** (ты) ведёт конвейер: добывает факты, рекомендует, пишет документы,
запускает исполнителей, вливает, проверяет, отчитывается коротко и по факту. Рабочая
копия репозитория принадлежит координатору; исполнители живут в своих worktree.
- **Исполнитель** — свежий агент на один тикет. Знает только тикет, спеку, словарь, ADR и
правила репозитория; коммитит в свою ветку, не пушит.
## Шаги
### 1. Репозиторий готов к конвейеру
`setup-matt-pocock-skills` в репозитории, где будет жить код: трекер (GitHub Issues,
если есть remote), метки триажа, single-context. Репозиторий без `CLAUDE.md` — сначала
гигиенический аудит: настоящие пути и команды, рецепты, стирающие данные,
расхождения документов с продом, правила, застрявшие в памяти агента. Находки
ложатся в `CLAUDE.md`.
**Документ проекта о границах агента** (`CONSTITUTION.md` и подобные) читается здесь, до
первого действия, которое может в него попасть, а не после него.
Черновики файлов показать оператору; после «ок» записать, команды из документов
прогнать, всё закоммитить одним коммитом.
Готово: `CLAUDE.md` и `docs/agents/*.md` в репозитории, коммит есть, каждая команда
из документов запущена и работает, границы агента прочитаны.
### 2. Интервью до пустого фронтира
`grill-with-docs` по правилам [interview.md](interview.md): раунды по фронтиру, каждый
вопрос с рекомендацией, простым языком; факты — сам, включая `research` фоновым
агентом; вкус — макетами и картой решений; словарь и ADR пишутся по ходу.
Готово: ни одной ветки дерева решений, где что-то предполагается молча; термины
в `CONTEXT.md`; ADR на каждое решение, которое будущий читатель захочет «починить».
### 3. Швы согласованы
До спеки назвать оператору места для автотестов простыми словами — чистые модули без
окна, сети и процессов — и то, что проверяется только руками «той же дверью, что
пользователь». Этого требует `to-spec`.
Готово: оператор сказал «ок» на список швов.
### 4. Спека в трекере
`to-spec`: issue с меткой `ready-for-agent`, со ссылками на `CONTEXT.md`, ADR, отчёты
исследования и макеты. Документы, написанные во время интервью, закоммичены.
Готово: номер issue известен, `git status` чист по документам.
### 5. Тикеты — трассирующие ломтики
`to-tickets`: список показать оператору до публикации — название, блокеры, что даёт
каждый; после «ок» опубликовать блокеры первыми с нативными зависимостями трекера
([coordinator.md](coordinator.md), «Публикация тикетов»). Работа в двух репозиториях —
тикеты всё равно в одном трекере, репозиторий назван в заголовке тикета.
Готово: все тикеты опубликованы, у каждого верные блокеры, фронтир очевиден.
### 6. Передача заведена
До первого исполнителя — документ передачи в репозитории по
[handoff.md](handoff.md). Он **живой**: не пишется перед концом, а обновляется после
каждого слияния. Лимит модели, исчерпанный контекст и закрытый терминал приходят без
предупреждения, поэтому свежесть документа — единственное, что делает обрыв дешёвым.
Готово: документ закоммичен, в нём таблица тикетов, ветки и рабочие копии, план на
остаток и разрешения оператора.
Свежесть документа стережёт хук `handoff-stale.sh` на `Stop` и `PreCompact`.
### 7. Реализация исполнителями
На каждый тикет фронтира — свой исполнитель (`Agent`, general-purpose, в фоне) с промптом
по [implement-agent-prompt.md](implement-agent-prompt.md). **Каждому своя worktree**,
включая того, кто «работает в основной ветке»: основная копия остаётся координатору.
Параллельно идут только тикеты без общих файлов; больше исполнителей, чем успеваешь
слить, не запускать.
Готово: отчёт каждого запущенного исполнителя получен.
### 8. Приём и слияние
По [coordinator.md](coordinator.md): проверить утверждения отчёта на целевой ветке
(полный набор тестов, линтер, сборка), влить линейно, убрать worktree, обновить
окружение, закрыть найденные исполнителем дыры сразу отдельным коммитом, спорное —
оператору списком с рекомендацией, тикет закрыть с доказательствами. Пересчитать
фронтир, запустить следующих, **обновить передачу**.
Готово: целевая ветка зелёная, тикет закрыт хешами и замерами, передача свежая.
### 9. Ворота человека
Вкусовой контент (тексты персонажа, визуал) — показать оператору целиком, слияние после
«ок». Ручная приёмка «той же дверью, что пользователь» — критерий приёмки каждого тикета
с окном, терминалом, установщиком или устройством: зелёные тесты не доказывают, что
продукт работает, и матрица платформ — часть этой двери.
**Разрешения спрашиваются один раз на класс действий, записываются и не переспрашиваются.**
Первый раз: пуш, публикация, выпуск, выкатка, деньги, боевые серверы, миграции, правка
`CLAUDE.md`, изменения на машине оператора. Получив разрешение, координатор делает эти
хлопоты сам; возвращать человека к рутине руками — та ошибка, ради которой правило и
записано. К оператору остаются продуктовые решения и то, где нужны лично его учётные
данные. **Учётные данные не запрашиваются в переписке никогда**: секрет вводится там, где
он читается из stdin или из формы. Появился в переписке — не использовать, сказать прямо
и посоветовать ротацию.
### 10. След
В память агента: где спека, тикеты и передача, что оператор разрешил и запретил, какие
варианты отвергнуты и почему. Память переживает сессию, но привязана к машине и не видна
человеку — она дополняет передачу, а не заменяет её. Свои ошибки — оператору сразу,
с последствием и предложением, как жить дальше.
## Файлы
- [interview.md](interview.md) — раунды, перепитч, макеты, карта решений, фоновое исследование.
- [implement-agent-prompt.md](implement-agent-prompt.md) — шаблон промпта исполнителя.
- [coordinator.md](coordinator.md) — публикация тикетов, worktree, запуск, приём, слияние, обрыв исполнителя, отчёт оператору.
- [handoff.md](handoff.md) — живой документ передачи: что в нём и когда обновляется.