1c-feature-dev

Принципы работы

• Адаптивность: количество агентов и глубина анализа зависят от сложности задачи
• Ранняя валидация: ревью плана до реализации, а не после
• Уточнение требований: выявление всех неоднозначностей до проектирования через вопросы пользователю
• Атомарные шаги: этапы реализации с критериями приемки и проверками
• Отслеживание прогресса: после завершения каждой фазы отмечай её как завершённую в списке задач

Phase 0: Инициализация и оценка сложности

Цель: понять масштаб задачи и создать структуру для работы

Начальный запрос: $ARGUMENTS

Действия:

1. Создай список задач со всеми фазами
2. Создай директорию .tasks/task-[feature-name]/ для хранения артефактов
3. Оцени сложность задачи (простая/средняя/сложная/критичная):
   • Простая: небольшое изменение, очевидная реализация
   • Средняя: затрагивает несколько модулей, требует понимания архитектуры
   • Сложная: большая доработка, несколько подсистем, неочевидные решения
   • Критичная: архитектурные изменения, влияние на всю систему, высокие риски
4. Запиши оценку сложности в файл .tasks/task-[feature-name]/phase0-complexity.md

Phase 1: Discovery

Цель: понять, что нужно построить

Действия:

1. Если доработка неясна, спроси пользователя:
   • Какую проблему они решают?
   • Что должна делать доработка?
   • Есть ли ограничения или требования?
2. Резюмируй понимание и получи подтверждение от пользователя
3. Сохрани подтвержденное понимание в файл .tasks/task-[feature-name]/phase1-requirements.md:
   • Исходный запрос из $ARGUMENTS
   • Уточняющие вопросы и ответы (если были)
   • Резюме понимания задачи
   • Ключевые требования и ограничения
   • Подтверждение пользователя

Phase 2: Исследование кодовой базы 1C

Цель: понять существующий код и паттерны

ПРИНЦИПЫ АДАПТИВНОГО ИССЛЕДОВАНИЯ:

ТЫ ПРИНИМАЕШЬ РЕШЕНИЕ о стратегии исследования на основе:

• Оценки сложности из Phase 0
• Характера задачи (новая доработка vs расширение существующей)
• Того, насколько понятна область кодовой базы

Ключевой принцип: глубина важнее ширины – лучше запустить агентов последовательно для углубления, чем параллельно на одно и то же.

Твои решения:

1. Сколько агентов 1c-code-explorer запустить? (1-4+)

   • Для простых задач может хватить одного
   • Для сложных может понадобиться несколько с углублением

2. Параллельно или последовательно?

   • Параллельно – если нужно изучить разные независимые области
   • Последовательно – если нужно углубление: первый агент находит, второй копает глубже

3. На какие аспекты фокусироваться?

   • Похожие доработки и паттерны
   • Архитектура и слои абстракции
   • Интеграции и зависимости
   • Критичные компоненты, найденные предыдущими агентами

4. Итеративное углубление

   • Можешь запустить агента, посмотреть результаты, решить нужно ли ещё углубление
   • Каждый следующий агент может фокусироваться на находках предыдущих

Действия:

1. Прими решение о стратегии исследования (обоснуй коротко)
2. Запусти агентов 1c-code-explorer согласно своей стратегии:
   • Передай путь к требованиям: phase1-requirements.md
   • Укажи фокус исследования для каждого агента (паттерны, архитектура, похожие доработки и т.д.)
3. Каждый агент должен вернуть список нескольких ключевых файлов для чтения
4. Прочитай все указанные файлы для глубокого понимания
5. Оцени: достаточно ли понимания? Нужно ли ещё углубление? Если да – запусти ещё агентов
6. Представь полную сводку найденных паттернов
7. Сохрани сводку в файл .tasks/task-[feature-name]/phase2-exploration.md:
   • Найденные паттерны и соглашения
   • Похожие доработки с ссылками на файлы
   • Ключевые компоненты и их назначение
   • Архитектурные инсайты
   • Список всех прочитанных ключевых файлов

Phase 3: Уточняющие вопросы

Цель: заполнить пробелы и разрешить все неоднозначности ДО проектирования

Действия:

1. Просмотри находки по кодовой базе и исходный запрос на доработку
2. Выяви недетализированные аспекты: граничные случаи, обработка ошибок, точки интеграции, границы области, предпочтения дизайна, обратная совместимость, потребности производительности
3. Представь все вопросы пользователю в ясном, организованном списке
4. Жди ответов перед проектированием архитектуры
5. Сохрани вопросы и ответы в файл .tasks/task-[feature-name]/phase3-clarifications.md:
   • Список вопросов с контекстом
   • Ответы пользователя на каждый вопрос
   • Принятые решения и рекомендации

Если пользователь говорит “как считаешь нужным”, предоставь свою рекомендацию и получи явное подтверждение.

Phase 4: Проектирование архитектуры

Цель: спроектировать архитектуру реализации

АДАПТИВНЫЙ ПОДХОД – количество агентов зависит от сложности:

Простая задача (1 агент):

• Запусти 1 агента 1c-code-architect
• Создай один практичный план реализации

Средняя задача (1 агент + опциональное мультисэмплинг):

• По умолчанию: 1 агент с практичным планом
• Опционально: если решение неочевидно, можешь запустить 2 агента с разными подходами и выбрать лучший

Сложная/критичная задача (2-3 агента, мультисэмплинг):

• Запусти 2-3 агента 1c-code-architect параллельно с разным фокусом:
  • Минимальные изменения (наименьшее изменение, максимальное переиспользование)
  • Чистая архитектура (поддерживаемость, элегантные абстракции)
  • Прагматичный баланс (скорость + качество)
• Сформируй мнение о лучшем подходе
• Представь пользователю все подходы с твоей рекомендацией
• Спроси пользователя, какой подход он предпочитает

Действия:

1. Запусти агентов 1c-code-architect согласно сложности задачи:
   • Передай пути к артефактам: phase1-requirements.md, phase2-exploration.md, phase3-clarifications.md
   • Для каждого агента укажи архитектурный подход (минимальные изменения / чистая архитектура / баланс)
2. После выбора подхода создай файл .tasks/task-[feature-name]/phase4-architecture.md с:
   • Постановкой задачи
   • Оценкой сложности из Phase 0
   • Выбранным архитектурным подходом с обоснованием
   • Найденными паттернами и соглашениями из Phase 2
   • Ответами на уточняющие вопросы из Phase 3
   • ЭТАПАМИ РЕАЛИЗАЦИИ – разбей реализацию на логические этапы (чеклист в markdown):
     • Гранулярность: простая задача = 1 этап, средняя = 2-4, сложная = 4-8, критичная = 5-10+ (отталкивайся от атомарности)
     • Атомарность: этап завершается за 1 сессию агента, имеет проверяемый результат, не блокирует сам себя
     • Формат: - [ ] **Этап N**: описание + файлы + критерии приемки + зависимости (если есть)
   • Mermaid-диаграммами (архитектура, потоки данных)
   • План должен быть самодостаточным для понимания без контекста беседы

Phase 5: Ревью плана

Цель: валидировать план ДО реализации — ошибки в плане обходятся дорого, весь код придётся переписывать.

Действия:

1. Запусти агента 1c-code-architect для ревью плана:
   • Передай пути к артефактам: phase1-requirements.md, phase2-exploration.md, phase3-clarifications.md, phase4-architecture.md
   • Фокус ревью:
     • Полнота: все ли аспекты задачи покрыты?
     • Корректность: соответствуют ли решения найденным паттернам из Phase 2?
     • Реалистичность: можно ли реализовать план как описано?
     • Соответствие требованиям: покрывает ли план все требования из Phase 1 и ответы из Phase 3?
     • Критерии приемки этапов: достаточно ли чёткие и проверяемые?
     • Зависимости: правильно ли выстроена последовательность этапов?
     • Технический долг: есть ли известные проблемы, которые план усугубит?
2. Если агент находит проблемы:
   • Обнови план в .tasks/task-[feature-name]/phase4-architecture.md
   • Повтори Phase 5 (ревью обновлённого плана)
3. Когда план одобрен агентом, сохрани результаты ревью в .tasks/task-[feature-name]/phase5-plan-review.md:
   • Что было проверено (полнота, корректность, реалистичность и т.д.)
   • Какие проблемы были найдены и исправлены (если были)
   • Итоговое заключение: план готов к реализации
4. Представь план пользователю:
   • Краткое резюме плана
   • Этапы реализации с критериями приемки
   • Спроси явно: “План готов к реализации, можем начинать?”

НЕ ПЕРЕХОДИ К PHASE 6 БЕЗ ЯВНОГО ОДОБРЕНИЯ ПОЛЬЗОВАТЕЛЯ

Phase 6: Реализация по этапам

Цель: построить доработку атомарными шагами с проверками приемки

НЕ НАЧИНАЙ БЕЗ ОДОБРЕНИЯ ПОЛЬЗОВАТЕЛЯ

Действия:

1. Прочитай файл плана .tasks/task-[feature-name]/phase4-architecture.md
2. Для каждого этапа реализации последовательно: a. Отметь этап в плане как начатый (измени - [ ] на - [🔄] в файле плана) b. Запусти агента 1c-code-writer для реализации этапа:
   • Передай путь к плану
   • Укажи конкретный этап для реализации
   • Напомни про критерии приемки c. Проверь критерии приемки этапа:
   • Все файлы созданы/изменены как описано?
   • Критерии приемки выполнены?
   • Код соответствует правилам из 1c-rules.md? d. Если критерии не выполнены:
   • Запусти агента 1c-code-writer для исправления:
     • Передай путь к плану и укажи этап
     • Опиши найденные проблемы и что нужно исправить
   • Повтори проверку критериев
   • Повторяй цикл исправления, пока критерии приемки не будут выполнены e. Отметь этап в плане как завершённый (измени - [🔄] на - [x] в файле плана)

Phase 7: Ревью кода

Цель: убедиться, что код корректен, элегантен и соответствует плану

Действия:

1. Запусти ревьюеров согласно размеру задачи:
   • Простая: 1c-code-reviewer
     • Передай путь к плану: phase4-architecture.md
     • Фокус: базовая корректность + беглая проверка соответствия плану
   • Средняя/сложная:
     • 1c-code-architect для проверки соответствия плану:
       • Передай пути к артефактам: phase1-requirements.md, phase4-architecture.md, phase5-plan-review.md
       • Фокус: соответствие плану, архитектурным решениям, критериям приемки этапов
     • 1c-code-reviewer для проверки качества кода:
       • Укажи путь к правилам: ~/.claude/rules/1c-rules.md
       • Фокус: баги, читаемость, правила, DRY, элегантность
   • Очень большая: раздели код на логические модули/подсистемы, для каждого модуля запусти пару агентов (architect + reviewer) с теми же инструкциями
2. Консолидируй их ответы и выяви проблемы, требующие исправлений
3. Сохрани результаты ревью в .tasks/task-[feature-name]/phase7-code-review.md:
   • Что было проверено (соответствие плану, качество, баги и т.д.)
   • Найденные проблемы с severity и рекомендациями
   • Итоговая оценка готовности кода
4. Представь выявленные проблемы пользователю и спроси, что он хочет сделать:
   • Исправить сейчас
   • Исправить позже (добавить в TODO/технический долг)
   • Продолжить как есть
5. Если “исправить сейчас”:
   • Добавь проблемы в план в секцию “Исправления после ревью”
   • Запусти агента 1c-code-writer для исправления:
     • Передай путь к плану: phase4-architecture.md
     • Опиши проблемы из ревью и что нужно исправить
   • Вернись к началу Phase 7 (повторное ревью)
   • Повторяй итерации, пока ревьюеры не перестанут находить критические проблемы
6. Если “исправить позже”:
   • Добавь проблемы в план в секцию “Технический долг”
   • Отметь в плане как отложенные

Phase 8: Итоги

Цель: документировать выполненное

Действия:

1. Отметь все задачи как завершённые
2. Сохрани резюме в файл .tasks/task-[feature-name]/phase8-summary.md:
   • Что было построено (ссылки на этапы реализации)
   • Ключевые принятые решения (ссылка на план)
   • Изменённые файлы (git diff –stat)
   • Оставшийся технический долг (если есть)
   • Предлагаемые следующие шаги
3. Представь резюме пользователю