🔄 Workflow разработки
Spec-driven development с Claude Code: от идеи до смёрджённого PR. Brainstorm → Spec → Plan → Worktree → Execute → Review → Merge.
🗺️ Полный цикл новой фичи
1
Brainstorm — обсудить идею
Запустить skill brainstorming. Claude задаёт уточняющие вопросы, предлагает 2-3 подхода, помогает выбрать. Обязателен для задач > 5 файлов.
/brainstorm
2
Spec — зафиксировать дизайн
Claude сохраняет согласованный дизайн в
docs/superpowers/specs/YYYY-MM-DD-feature-design.md. Это точка истины для реализации.docs/superpowers/specs/2026-05-08-payments-design.md
3
Plan — детальный план реализации
Spec-driven план с пошаговыми задачами (2-5 минут каждая). Чекбоксы для отслеживания прогресса. Claude сохраняет в docs/superpowers/plans/.
/write-plan
4
Git Worktree — изолированная ветка
Работа в отдельном worktree чтобы не ломать основную ветку. Можно вести несколько задач параллельно.
git worktree add E:/Clients/wt/payments feat/payments main
5
Execute — реализация по плану
Запустить Claude в worktree. Работать пошагово по чекбоксам плана. TDD: тест → реализация → рефакторинг.
cd E:/Clients/wt/payments && claude
6
Review — проверка кода
Code review через Claude. Проверка соответствия spec, стандартов кода, тестов. Все тесты должны быть зелёными.
/request-code-review
7
Merge — слияние в main
PR → squash merge → удалить worktree. Коммит должен быть атомарным — одна фича, один PR.
git worktree remove E:/Clients/wt/payments
🌿 Git Worktrees — параллельная работа
Worktrees позволяют работать над несколькими задачами одновременно, не переключая ветки в основной рабочей директории.
# Создать worktree для фичи payments (от main):
git worktree add E:/Clients/wt/payments feat/payments main
# Открыть Claude Code в worktree:
# cd E:/Clients/wt/payments && claude
# Список активных worktrees:
git worktree list
# Удалить worktree после merge:
git worktree remove E:/Clients/wt/payments
# Структура параллельных задач:
E:\Clients\wt\
├── payments\ ← feat/payments (активный)
├── auth-fix\ ← fix/auth-bug (активный)
└── refactor-api\ ← refactor/api-v2 (в ревью)
💡
Каждый worktree — отдельный Claude Code процесс. Запускай
claude в каждой папке независимо. Они не мешают друг другу, у каждого свой контекст.📝 TDD — Test Driven Development
# Цикл RED → GREEN → REFACTOR:
# 1. RED — написать тест который не проходит:
# Claude пишет тест для PaymentService::create()
./vendor/bin/pest tests/Feature/PaymentTest.php # FAIL ← ожидаем!
# 2. GREEN — написать минимальную реализацию:
# Claude пишет PaymentService::create()
./vendor/bin/pest tests/Feature/PaymentTest.php # PASS ← цель!
# 3. REFACTOR — улучшить код:
# Claude рефакторит Service, тест должен оставаться зелёным
./vendor/bin/pest tests/Feature/PaymentTest.php # PASS ← всё ещё!
✅
Правило из CLAUDE.md: перед PR все тесты должны быть зелёными. Если Claude говорит "всё работает" — запроси реальный output: "Запусти
./vendor/bin/pest и покажи вывод".🎓 Советы экспертов — что работает
Выжимка из блогов Boris Cherny (создатель CC), Geoffrey Huntley, Armin Ronacher, Mitchell Hashimoto, Steve Yegge, Harper Reed — люди с реальными проектами 50k–500k строк.
1
Верификация — главное (Anthropic, Yegge)
«Дай Claude способ проверить свою работу» — единственная вещь с наибольшим leverage. Тесты, lint, реальный bash-вывод. Никогда не доверяй «100% successful» без proof.
./vendor/bin/pest | pytest -v | npm test — запрашивай реальный output
2
Harper Reed: Idea → Spec → Plan → Execute
Сначала Socratic-диалог с reasoning-моделью → spec.md. Потом prompt_plan.md с чек-листом. Потом execute: «Open @prompt_plan.md, implement next uncompleted item, run tests, commit, mark done.»
3
Boris Cherny: параллельность + tags в PR
5 параллельных Claude в нумерованных вкладках + системные нотификации. Теги @.claude в PR — ошибки превращаются в правила CLAUDE.md. Голосовой ввод (fn+fn) даёт богаче промпты.
4
Mitchell Hashimoto: Vertical Slices
Ручной research архитектурных границ → «Consult the Oracle» (интерактивный план) → Vertical slices: UI → backend → integration по очереди. Никогда не шипать AI-код без manual review.
5
Geoffrey Huntley: /specs + stdlib промптов
Библиотека многоразовых шаблонов задач. Компилятор как верификатор — сильно типизированные языки (Rust, Go) дают детерминированный feedback. Анти-паттерн: преждевременная мульти-агентность.
6
Steve Yegge: Rule of Five
4–5 итераций до «as good as can get». 40% времени на code health — иначе будет >60%. Beware the Merge Wall: параллельные агенты от одного baseline создают ад при merge.
⚠️
Что НЕ работает у экспертов:
slash-команды без чёткого контракта, hooks кроме deny-list, sub-agents для не-исследовательских задач (Armin Ronacher).
Peter Steinberger удалил все MCP кроме минимума — Claude уходил крутить Playwright когда мог читать код напрямую.
💬 Эффективные промпты
# Начало задачи:
"Добавь страницу оплаты с Stripe. Backend: Laravel Service + Controller + FormRequest.
Frontend: Vue компонент PaymentForm. Начни с /brainstorm."
# Ограничение scope (важно!):
"Реализуй ТОЛЬКО PaymentService::create(). Не трогай Controller, Migration, тесты пока."
# При зависании:
"Запусти ./vendor/bin/pest tests/Feature/PaymentTest.php и покажи реальный output."
# После неудачи:
[/clear]
"Получаю TypeError в PaymentService строка 45. Вот полный стек: [вставить].
Причина в том что amount приходит как string из FormRequest."
🔍 Автоматизация проверок — не доверяй, проверяй
Встройте петлю верификации в рабочий поток. Claude должен не просто писать код — он должен доказывать что код работает.
Петля верификации
# Неправильный workflow (Claude угадывает):
Вы: "Добавь кнопку с анимацией"
Claude: "Готово! Я добавил кнопку с CSS-анимацией hover."
Вы: открываете браузер... кнопка сломана
# Правильный workflow (Claude доказывает):
Вы: "Добавь кнопку с анимацией. После — скриншот через Playwright."
Claude: [добавляет код] [открывает Playwright] [делает скриншот]
Claude: "Вот скриншот — кнопка работает, анимация на hover видна."
Три уровня верификации
| Уровень | Инструмент | Когда использовать | Промпт |
|---|---|---|---|
| Браузер | Playwright MCP | HTML/CSS/JS изменения | «…и сделай скриншот localhost:PORT» |
| Команды | Docker MCP exec | Миграции, тесты, очереди | «…и запусти через docker_exec, покажи вывод» |
| API | Bash curl / Playwright network | REST-эндпоинты | «…и сделай curl запрос, покажи ответ» |
Шаблон промпта с верификацией
# Структура промпта который не позволяет Claude уйти без доказательства:
"[Задача].
После выполнения:
1. [Конкретное действие проверки]
2. Покажи [конкретный результат]
Не отвечай 'готово' без доказательства."
# Примеры:
"Добавь форму регистрации в register.blade.php.
После: открой localhost:8000/register через Playwright и сделай скриншот.
Проверь что форма видна и поля подписаны."
"Создай API эндпоинт POST /api/users.
После: запусти тест php artisan test --filter=UserTest через docker_exec
и покажи вывод с количеством passed/failed."
"Напиши миграцию для таблицы orders.
После: запусти php artisan migrate через docker_exec
и покажи exit code и вывод команды."