| name | dev-start |
| description | Parallel-agent project/feature kickoff — 4 agents design contracts, scaffold tests, review security, validate structure BEFORE any code is written. Prevents 80% of audit findings at the root. |
/dev-start — Parallel Feature Kickoff
When to use
- Starting a new feature or project slice — design contracts, scaffold tests, and security review BEFORE any code is written.
- Preventing the most common audit findings at the root (no contracts, no tests, no security review).
- Kickoff for a PR-sized chunk of work:
/dev-start [feature description].
80% проблем из аудитов = код написан без подготовки. Нет контрактов, нет тестов, нет security review.
dev-start запускает 4 агента ПАРАЛЛЕЛЬНО до первой строки кода.
Команды
/dev-start [описание фичи] → полный kickoff (4 агента)/dev-start lite [описание] → быстрый (2 агента: contract + tests)
Anti-Hallucination (наследуется от wave-audit)
Каждый агент ОБЯЗАН:
- CODE_QUOTE — цитировать существующий код при ссылках на него
- VERIFY_CMD — давать команду для проверки каждого утверждения
- COVERAGE_LOG — перечислить прочитанные файлы
- SEVERITY_CALIBRATION — не раздувать severity
Phase 0 — Context Discovery (lead)
- Определить стек проекта (читать package.json / go.mod / pubspec.yaml — НЕ из memory)
- Найти аналогичные фичи в проекте (grep/glob по похожим паттернам)
- Прочитать CLAUDE.md, DECISIONS.md если есть
- Сформулировать scope: какие файлы будут затронуты
Phase 1 — Parallel Kickoff (4 агента одним сообщением)
Agent: ds-contract
Проект: [path], стек: [стек].
Фича: [описание].
Задача: спроектировать API контракт ДО реализации.
1. Определи ВСЕ types/interfaces которые нужны для фичи
2. Определи API boundaries — какие модули взаимодействуют
3. Проверь существующие типы — НЕ дублируй (SSOT):
- Grep по проекту: есть ли похожие типы?
- Если есть — переиспользуй, НЕ создавай новые
4. Определи data flow: откуда данные → куда → в каком формате
5. Для каждого join/merge — определи ключ (НЕ индекс массива!)
Output:
- Список types/interfaces с полями
- Data flow diagram (текстом)
- Список переиспользуемых типов (с путями)
- Предупреждения о потенциальных N+1 / data integrity issues
CODE_QUOTE существующих типов обязательна.
Agent: ds-tests
Проект: [path], стек: [стек].
Фича: [описание].
Задача: написать скелет тестов ДО реализации (TDD).
1. Определи critical paths фичи
2. Для каждого path — напиши test case:
- Happy path
- Edge cases (null, empty, boundary values)
- Error cases (network fail, invalid input, timeout)
- Auth cases (unauthorized, wrong role)
3. Определи test framework проекта (jest/vitest/pytest/go test)
4. Создай файлы тестов с описательными `it()`/`test()` — тела пустые (TODO)
Output:
- Список test files с путями
- Содержимое каждого test file (skeleton)
- Какие mocks/fixtures нужны
НЕ пиши реализацию — только тесты.
Agent: ds-security
Проект: [path], стек: [стек].
Фича: [описание].
Задача: security review ДО написания кода.
1. Классифицируй фичу по risk level:
- HIGH: auth, payments, user data, crypto, file upload
- MEDIUM: API endpoints, forms, search, notifications
- LOW: UI-only, docs, formatting
2. Для HIGH/MEDIUM — чек-лист требований:
- [ ] Input validation — какие поля, какие constraints?
- [ ] Auth/authz — кто может вызывать? какие роли?
- [ ] Rate limiting — нужен? какой лимит?
- [ ] Data exposure — что НЕ должно попасть в response?
- [ ] Secrets — нужны ли новые ключи/токены? Где хранить?
- [ ] Crypto — если JWT/подписи: verify ОБЯЗАТЕЛЕН (НЕ decode)
- [ ] Pagination — max limit обязателен
3. Проверь существующие auth/security паттерны в проекте:
- Как другие endpoints делают auth?
- Есть ли middleware? Используется ли?
- Есть ли rate limiting? Работает ли? (grep по коду)
Output:
- Risk level фичи
- Security requirements checklist (заполненный)
- Паттерны из проекта которые НАДО переиспользовать
- Антипаттерны из проекта которые НЕ НАДО повторять
- CODE_QUOTE существующих security паттернов
Agent: ds-structure
Проект: [path], стек: [стек].
Фича: [описание].
Задача: спланировать файловую структуру.
1. Определи какие файлы нужно создать / изменить
2. Для каждого файла — оценка LOC:
- Если >150 LOC predicted → split на 2+ файла СРАЗУ
- Если функция >25 LOC predicted → split на подфункции СРАЗУ
3. Проверь Constructor Pattern:
- 1 файл = 1 класс = 1 ответственность
- Types отдельно от реализации
- Нет ли существующих файлов >200 LOC которые фича усугубит
4. Проверь зависимости:
- Нужны ли новые пакеты?
- Есть ли уже установленные пакеты для этой задачи?
- Нет ли dead dependencies которые можно переиспользовать?
Output:
- File plan: [path] — [responsibility] — [estimated LOC]
- Files to modify: [path] — [current LOC] → [estimated LOC after]
- Constructor Pattern warnings
- Dependency recommendations
Phase 2 — Synthesis (lead)
- Собрать выводы 4 агентов
- Проверить конфликты:
- ds-contract предлагает тип, ds-security говорит не экспонировать поле?
- ds-structure предлагает файл, ds-tests ожидает другой путь?
- Сформировать Development Brief:
=== DEVELOPMENT BRIEF ===
Feature: [название]
Risk: HIGH/MEDIUM/LOW
## Contracts
[types/interfaces from ds-contract]
## Test Plan
[test files from ds-tests]
## Security Requirements
[checklist from ds-security]
## File Plan
[structure from ds-structure]
## Warnings
[potential issues caught before coding]
## Ready to code: YES/NO
[если NO — что нужно решить сначала]
- Показать пользователю для approve
- ТОЛЬКО после approve → начинать кодить
Safety Constraints
- НЕ писать код до завершения Phase 2
- НЕ создавать новые типы если есть существующие (SSOT)
- НЕ добавлять зависимости без обоснования
- НЕ пропускать ds-security для HIGH risk фич
- При конфликте между агентами — спросить пользователя
