🚀 Feature Workflow — Добавление Функциональности

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

Триггеры:

• Новая функция/модуль в существующем проекте
• Расширение существующей функциональности
• Интеграция с внешним сервисом
• Добавление API endpoint

НЕ использовать для:

• Нового проекта с нуля → new-project.md
• Фикса багов → debugging.md
• Рефакторинга без изменения поведения → refactoring.md
• Архитектурных изменений (миграции, масштабирование) → architecture-change.md

Фаза 1: Анализ Требований

Шаг 1.1: Сбор Информации

Действия:

1. Уточни у пользователя:

   • Что именно должна делать функция?
   • Кто будет использовать? (роли, permissions)
   • Какие входы/выходы?
   • Есть ли edge cases?

2. Проверь существующий контекст:

   • /docs/Requirements.md — есть ли связанные требования?
   • /docs/Architecture.md — какие модули затронуты?
   • /docs/Rules.md — какие ограничения?

Выход: Понимание scope + список уточняющих вопросов (если есть).

Шаг 1.2: Оценка Сложности

Правило: При сомнении выбирай более высокий уровень сложности.

Фаза 2: Маршрутизация по Сложности

🟢 Simple Path

Критерии:

• ≤2 файла
• Один модуль
• Нет изменений БД
• Нет архитектурных решений

Протокол:

1. Анализ → понял scope, нет неясностей
         ↓
2. Сформировать промпт для @coder (templates/prompts/coder/implement.md)
         ↓
3. Делегировать @coder
         ↓
4. Делегировать @reviewer
         ↓
5. PASS → обновить /docs/* если нужно → DONE
   FAIL → анализ → исправление

Не требуется: Plan.md, Research.md, STOP-gate.

🟡 Medium Path

Критерии:

• 3-5 файлов ИЛИ
• Несколько модулей ИЛИ
• Изменения БД (новые поля) ИЛИ
• Новый API endpoint

Протокол:

1. Анализ → понял scope
         ↓
2. Создать /docs/Plan.md
   - Архитектурное решение
   - Список файлов + изменения
   - Порядок выполнения
   - Acceptance Criteria
         ↓
3. 🛑 STOP — запросить утверждение плана
         ↓
4. [После утверждения] Сформировать промпт для @coder
         ↓
5. Делегировать @coder
         ↓
6. Делегировать @reviewer
         ↓
7. PASS → обновить /docs/* → DONE
   FAIL → анализ → исправление

Требуется: Plan.md + STOP-gate перед реализацией.

🔴 Complex Path

Критерии:

• 5 файлов ИЛИ

• Cross-cutting concerns ИЛИ
• Новые таблицы / сложные миграции ИЛИ
• Изменения auth/authz ИЛИ
• Публичный API / breaking changes ИЛИ
• Интеграция с новым сервисом

Протокол:

1. Анализ → понял scope, выявил unknowns
         ↓
2. [Если unknowns] Вызвать @coder-expert для исследования
         ↓
3. Создать /docs/Research.md
   - Анализ текущей архитектуры
   - Зависимости и ограничения
   - Риски
         ↓
4. Создать /docs/Plan.md
   - Архитектурное решение + альтернативы
   - Почему выбран этот подход
   - Поэтапный план
   - Rollback strategy
   - Acceptance Criteria
         ↓
5. [Если арх. решение] Создать /docs/adr/ADR-NNN.md
         ↓
6. 🛑 STOP — запросить утверждение плана
         ↓
7. [После утверждения] Поэтапная реализация:
   Для каждой фазы:
   - Промпт для @coder
   - @reviewer после каждой фазы
         ↓
8. PASS all phases → обновить /docs/* → DONE
   FAIL → анализ → возможно @coder-expert → исправление

Требуется: Research.md + Plan.md + ADR (если арх. решение) + STOP-gate.

Фаза 3: Создание Плана

Структура Plan.md

markdown
1# Plan: [Название фичи]
2*Created: YYYY-MM-DD*
3
4## Цель
5[Что делаем и зачем]
6
7## Архитектурное Решение
8
9### Подход
10[Описание выбранного решения]
11
12### Альтернативы (🟡🔴)
13| Вариант | Pros | Cons |
14|---------|------|------|
15| A | ... | ... |
16| B | ... | ... |
17
18**Выбор:** Вариант A, потому что [обоснование]
19
20## Изменения
21
22### Файлы
23| Файл | Действие | Описание |
24|------|----------|----------|
25| `path/to/file.ts` | CREATE/MODIFY | Что делаем |
26
27### База Данных (если применимо)
28- Миграция: [описание]
29- Rollback: [как откатить]
30
31## Порядок Выполнения
321. [Шаг 1]
332. [Шаг 2]
343. ...
35
36## Acceptance Criteria
37- [ ] [Критерий 1 — измеримый]
38- [ ] [Критерий 2 — измеримый]
39- [ ] Тесты проходят
40- [ ] @reviewer PASS
41
42## Риски и Ограничения
43| Риск | Митигация |
44|------|-----------|
45| ... | ... |
46
47---
48🛑 **STOP: Требуется утверждение плана перед реализацией**

Фаза 4: Делегирование

Промпт для @coder

Используй шаблон из prompts/coder/implement.md:

markdown
1# Task: [Конкретное название]
2
3## Context
4[Почему важно, как вписывается в систему]
5
6## Scope
7[Точные шаги. Никакой лишней работы.]
8
9## Requirements
101. [Измеримое требование]
112. [Измеримое требование]
12
13## Constraints (Что НЕ делать)
14❌ Не расширять scope
15❌ Не менять контракты/зависимости без явного указания
16❌ Не оставлять console.log/debug код
17
18## Acceptance Criteria
19✅ [Тесты проходят]
20✅ [Build/Lint чистые]
21✅ [Конкретный результат]
22
23## Files to Work With
24- `path/to/file` — [что изменить]
25
26## Output Format
27Только код. Объяснения не нужны.

После @coder

ОБЯЗАТЕЛЬНО: Вызвать @reviewer.

markdown
1## 🤖 Delegation
2**Agent:** @reviewer
3**Purpose:** Проверить качество реализации [название фичи]
4**Expected Output:** PASS / FAIL с комментариями
5**Input Documents:** /docs/Plan.md, /docs/Rules.md
6🛑 STOP after completion. Return control to @meta-architect.

Фаза 5: Обработка Результатов

@reviewer PASS

1. Обновить /docs/*:

   • Architecture.md — если добавлены модули
   • Requirements.md — если новые требования зафиксированы
   • Tasks.md — отметить задачу выполненной

2. Сообщить пользователю о завершении

@reviewer FAIL

1. Проанализировать причину:

   • Ошибка в плане → исправить Plan.md
   • Ошибка @coder → уточнить промпт, повторить
   • Сложнее чем ожидалось → пересмотреть 🟢→🟡 или 🟡→🔴

2. Если >2 итерации без прогресса:

   • STOP → Two Steps Back
   • Вызвать @coder-expert
   • Пересмотреть подход

Чеклист Feature Workflow

Перед Началом

• Scope понятен (нет неясностей)
• Сложность оценена (🟢/🟡/🔴)
• Контекст загружен (Architecture.md, Rules.md)

Для 🟡/🔴

• Plan.md создан
• Альтернативы рассмотрены
• STOP-gate пройден (утверждение получено)

После Реализации

• @reviewer вызван
• PASS получен
• /docs/* обновлены

Quick Reference

Feature Request
      ↓
Анализ scope → Оценка 🟢🟡🔴
      ↓
🟢 → @coder → @reviewer → docs → DONE
🟡 → Plan.md → STOP → @coder → @reviewer → docs → DONE  
🔴 → Research.md → Plan.md (+ADR) → STOP → phased @coder → @reviewer per phase → docs → DONE

Связанные файлы:

• references/feature-spec-template.md — шаблон спецификации фичи
• references/feature-context-snapshot.md — шаблон контекстного снапшота
• references/requirements-template.md — шаблон требований
• .claude/skills/checklist-code-review/SKILL.md — чеклист ревью
• .claude/skills/role-coder-expert/references/ai-failure-modes.md — если @coder зацикливается

END OF WORKFLOW