🟢 Продвинутый · Процесс

📐 Стандарты разработки — снижение регресса

Регресс — главный враг solo-разработчика: сделал фичу, сломал другую. Эта страница — система: правильный цикл разработки, скиллы в нужный момент, стандарты в CLAUDE.md и чеклисты которые работают.

8-шаговый цикл 5 ключевых скиллов 12 пунктов чеклиста 7 анти-паттернов

#🔴 Почему возникает регресс

Регресс — не случайность. Это предсказуемый результат нескольких конкретных ошибок. Знать их — значит уметь предотвратить.

Нет плана

Claude начинает реализацию без spec. Через 3 часа — запутанный код, непонятные зависимости, страх трогать.

Нет верификации

«Готово» без запуска тестов. Claude говорит что всё работает — но никто не проверил. Ошибка найдётся в prod.

Одна огромная сессия

Вся задача в одном контексте. История раздулась, Claude путает детали разных подзадач, качество падает.

Игнор скиллов

Разработчик пишет промпты вручную вместо /tdd или /code-review. Нет структуры — нет гарантий.

Нет границ в CLAUDE.md

Claude трогает всё подряд: меняет .env, добавляет зависимости, переписывает рядом стоящий файл. Без explicit запретов всё дозволено.

#🗺️ Цикл без регресса — 8 шагов

Этот цикл — не теория. Каждый шаг снимает конкретный риск регресса. Пропуск шага = принятый риск, который рано или поздно реализуется.

Подготовка к проекту

Новый проект или крупная фича — сначала бриф, требования, стек. Без этого Claude будет угадывать контекст и принимать архитектурные решения самостоятельно. Полное руководство → project-brief.html

/project-brief пропустить: только мелкие правки

Brainstorm

Обсудить задачу с Claude ПЕРЕД реализацией. Уточнить требования, выбрать подход, избежать архитектурных ошибок на старте. Когда пропустить: переименование, мелкие CSS-правки, очевидные однострочники.

/brainstorm → superpowers:brainstorming пропустить: задачи < 2 файлов

Spec

Зафиксировать согласованный дизайн в docs/superpowers/specs/. Это точка истины — если реализация расходится со spec, что-то пошло не так. Пример: docs/superpowers/specs/2026-05-27-payments-design.md

сохраняется автоматически после brainstorm

Plan

Детальный план с чекбоксами — задачи по 2–5 минут каждая. Claude выполняет по одному пункту и отмечает. Нет плана = нет контроля прогресса. Пример: docs/superpowers/plans/2026-05-27-payments-plan.md

/write-plan → superpowers:writing-plans

🧭 Консенсус практиков: отдельная фаза плана/спеки до кода — самая частая рекомендация в индустрии. Переделать план дёшево, переделать код — дорого. Так строят процесс Anthropic (Plan Mode), Mitchell Hashimoto (Oracle) и Harper Reed (spec.md) — см. сводную шпаргалку.

Git Worktree

Изолированная ветка = защита main от незаконченного кода. Можно вести несколько задач параллельно без переключения веток.

/git-worktrees → superpowers:using-git-worktrees

git worktree add E:/wt/feat-name feat/feat-name main

TDD Execute

Тест первый, реализация вторая. RED → GREEN → REFACTOR. Если нет тестов — Claude не может верифицировать свою работу. Это источник регресса #2.

/tdd → superpowers:test-driven-development

php artisan test / npm run test

Code Review

Ревью изменений ПЕРЕД мержем. Минимум medium уровень. Для security и архитектурных изменений — high или ultra.

/code-review уровни: low / medium / high / ultra

Когда ultra: изменения в auth, payments, API-ключах.

Merge + Cleanup

Squash-merge в main. Удалить worktree. Закрыть сессию (/clear). Атомарный коммит — одна фича, один PR.

git worktree remove E:/wt/feat-name

Каждый шаг этого цикла описан детально в → Workflow разработки. Эта страница про то, ПОЧЕМУ шаги важны и какие скиллы использовать на каждом.

#📊 Таблица скиллов — быстрый lookup

Когда сомневаешься какой скилл вызвать — смотри сюда. Одна строка = одно решение.

Ситуация	Скилл / Команда	Что даёт	Когда НЕ нужен
Новая фича > 2 файлов	`/brainstorm`	Дизайн без угадывания	Мелкие однострочники
После brainstorm, нужен план	`/write-plan`	Чеклист задач 2–5 мин	Уже понятно что делать
Реализация с гарантией	`/tdd`	RED → GREEN → REFACTOR	Уже есть тесты
Перед мержем	`/code-review`	Находит баги до prod	Тривиальный однострочник
Security / payments	`/code-review high`	Глубокий анализ рисков	Косметические правки
Многоагентный ревью PR	`/code-review ultra`	Несколько агентов параллельно	Локальные изменения
Исправить найденное ревью	`/simplify`	Автоприменение фиксов	—
Отладка неочевидного бага	`/focused-fix`	Систематический дебаг	Очевидная опечатка
Параллельная задача	`git worktree` + `/git-worktrees`	Изоляция от main	Маленькая правка
Перед началом нового проекта	`/project-brief`	Бриф, ТЗ, контекст	Фича в существующем проекте
UI/UX задача	`/px <описание>`	Дизайн-скиллы	Backend-задача
Технический долг	`/tech-debt`	Анализ накопленных проблем	Активная разработка фичи
Безопасность	`/security-review`	XSS, SQLi, CSRF, auth	Публичный статический сайт
Документация	`/changelog`	Авто-changelog из git	Нет git-истории
Выбор модели	`/model-picker`	Haiku / Sonnet / Opus	Всегда один и тот же проект

#🎯 Пять ключевых скиллов — когда и как

Эти пять скиллов формируют ядро качественного процесса. Знать их не только формально, но понимать зачем — разница между использованием и злоупотреблением.

🧠 Brainstorming /brainstorm

Когда использовать

Любая задача затрагивающая > 2 файлов, архитектурные решения, новые фичи. Claude задаёт уточняющие вопросы, предлагает 2–3 подхода, помогает выбрать.

Анти-паттерн

Вызывать для «добавь поле в форму» — это overhead, достаточно прямого промпта. Не каждая задача требует brainstorm.

/brainstorm → Claude задаст вопросы → ответь → получи 2-3 подхода → выбери
Результат: spec.md с согласованным дизайном → передаёшь в /write-plan

🧪 TDD /tdd

Когда использовать

Любая бизнес-логика, сервисы, API-эндпоинты, что угодно что может сломаться. Жёсткое правило: RED обязателен. Зелёный тест без RED означает тест который ничего не проверяет.

Анти-паттерн

«Напишу тесты потом» — тесты потом не пишутся, а регресс находится в prod. Нет тестов = нет верификации = источник регресса #2.

/tdd → Claude пишет тест → тест красный (RED) → Claude пишет реализацию → тест зелёный (GREEN) → рефакторинг

👁️ Code Review /code-review

Когда использовать

Перед каждым мержем. medium — дефолт. high — для auth/payments/API. ultra — для PR на GitHub с несколькими агентами параллельно.

Анти-паттерн

Пропускать ревью «потому что сам писал и всё помню» — регресс именно там. Субъективная оценка своего кода хуже чем никакой.

/code-review          — medium (дефолт)
/code-review high    — auth, payments, API
/code-review ultra   — PR №42 на GitHub, многоагентный

🌿 Git Worktrees /git-worktrees

Когда использовать

Параллельные задачи, долгие фичи, эксперименты которые могут сломать. Несколько Claude параллельно в разных worktrees — реальный параллелизм.

Анти-паттерн

Работать в main и «откатить если что» — откатить сложнее чем кажется. main всегда должен быть deployable.

/git-worktrees → выбрать папку → Claude создаёт ветку и worktree → работаешь изолированно
Бонус: несколько Claude параллельно в разных worktrees

📋 Writing Plans /write-plan

Когда использовать

После brainstorm, перед реализацией сложной задачи. Результат: docs/superpowers/plans/YYYY-MM-DD-task-plan.md с чекбоксами.

Анти-паттерн

Давать Claude задачу без плана — он будет делать «всё сразу» и терять фокус между подзадачами.

/write-plan → Claude читает spec → создаёт чекбоксы (задачи 2-5 мин) → ты проверяешь → /execute-plan

#⚙️ CLAUDE.md как основа стандартов

CLAUDE.md — единственное место где твои стандарты становятся обязательными для Claude. Всё что не написано в CLAUDE.md — Claude может сделать иначе.

Правила снижающие регресс — шаблон блока в CLAUDE.md

## Архитектурные границы (обязательно соблюдать)
- Логика ТОЛЬКО в app/Services/ — контроллеры вызывают сервисы, не содержат логику
- Репозитории ТОЛЬКО в app/Repositories/ — работа с БД только там
- НЕ трогай файлы за пределами текущей задачи
- НЕ изменяй .env, docker-compose.yml, webpack.config.js без явного запроса

## Верификация (обязательно)
- После каждого изменения запусти тесты и покажи вывод
- Никогда не говори "должно работать" — запусти и покажи
- Тесты должны быть зелёными перед сообщением "готово"

## Git (только по явной просьбе)
- НЕ делай git add . — только конкретные файлы
- НЕ коммить без явного запроса
- Сообщения коммитов на английском

## Безопасность
- Проверяй SQL-инъекции, XSS, CSRF при любых изменениях на периметре
- НЕ логируй sensitive данные (пароли, токены, карты)
- НЕ добавляй секреты в код — только через .env

## Стиль кода
- Комментарии и docstring — только по явной просьбе
- Type hints — только по явной просьбе
- Следуй существующему стилю файла, не навязывай свой

🧭 Консенсус практиков: короткий актуальный CLAUDE.md работает лучше раздутого — модель хуже держит в голове длинные инструкции, а устаревшие правила только сбивают с толку. После каждой ошибки агента — новое явное правило, а не абзац «на всякий случай». Так советуют Simon Willison (<500 токенов), Boris Cherny и Peter Steinberger (<100 строк) — см. сводную шпаргалку.

Нужную модель для каждого шага → Выбор модели (Haiku / Sonnet / Opus)

#✅ Чеклист перед каждым коммитом

12 пунктов. Занимает 2 минуты. Предотвращает часы исправлений.

#⚠️ Анти-паттерны — топ-7 ошибок

«Сделай всё сразу»

Огромный промпт с 10 требованиями за раз. Claude теряет фокус, делает половину, угадывает остальное.

Одна задача = один промпт. Используй plan с чекбоксами.

Долгая сессия без /compact

Работаешь 3 часа, история раздулась до 150K токенов. Ответы становятся хуже, Claude путает детали разных подзадач.

/compact каждые 40–50K токенов, /clear при смене задачи.

«Работает на моей машине»

Нет тестов, нет CI, нет верификации. Регресс обнаруживается когда клиент жалуется.

/tdd обязателен. Запускай тесты и показывай вывод Claude после каждого изменения.

Ревью только на словах

«Проверил, всё окей» без /code-review. Субъективная оценка своего кода — хуже чем никакой.

/code-review перед каждым мержем. Для security — /code-review high.

Работа в main напрямую

Долгая незаконченная фича в main ломает других (или тебя в другой задаче).

git worktree для каждой задачи > 1 часа. main всегда должен быть deployable.

Игнор CLAUDE.md

CLAUDE.md пустой или старый. Claude не знает твоих правил и делает по-своему.

CLAUDE.md под 200 строк, актуальный. Пересматривать раз в месяц.

Пропуск brainstorm для «очевидных» задач

«Это же просто — добавить поле.» Через 2 часа: «поле» затронуло 8 файлов и сломало валидацию.

Если задача касается > 2 файлов или есть неопределённость — /brainstorm. Занимает 5 минут.

#📚 Связанные материалы

🗂️ Workflow разработки

Полный цикл: Brainstorm → Spec → Plan → Execute → Merge

📋 Подготовка к проекту

Бриф, ТЗ, Lean Canvas — до начала разработки

🧭 Выбор модели

Haiku / Sonnet / Opus — когда и зачем

✅ Чек-листы

Полная коллекция чек-листов для разных ситуаций

🪙 Оптимизация токенов

Экономия контекста и правила сессий