| name | 1c-feature-dev |
| description | Этот скилл следует использовать, когда пользователь просит "создать доработку 1C", "реализовать функционал 1C", "добавить новую возможность в 1C", "разработать модуль 1C", "сделать доработку в 1С" или нуждается в полном цикле разработки 1C-доработок от анализа до реализации с валидацией плана и проверками приемки. |
Принципы работы
- Адаптивность: количество агентов и глубина анализа зависят от сложности задачи
- Ранняя валидация: ревью плана до реализации, а не после
- Уточнение требований: выявление всех неоднозначностей до проектирования через вопросы пользователю
- Атомарные шаги: этапы реализации с критериями приемки и проверками
- Отслеживание прогресса: после завершения каждой фазы отмечай её как завершённую в списке задач
Phase 0: Инициализация и оценка сложности
Цель: понять масштаб задачи и создать структуру для работы
Начальный запрос: $ARGUMENTS
Действия:
- Создай список задач со всеми фазами
- Создай директорию
.tasks/task-[feature-name]/ для хранения артефактов
- Оцени сложность задачи (простая/средняя/сложная/критичная):
- Простая: небольшое изменение, очевидная реализация
- Средняя: затрагивает несколько модулей, требует понимания архитектуры
- Сложная: большая доработка, несколько подсистем, неочевидные решения
- Критичная: архитектурные изменения, влияние на всю систему, высокие риски
- Запиши оценку сложности в файл
.tasks/task-[feature-name]/phase0-complexity.md
Phase 1: Discovery
Цель: понять, что нужно построить
Действия:
- Если доработка неясна, спроси пользователя:
- Какую проблему они решают?
- Что должна делать доработка?
- Есть ли ограничения или требования?
- Резюмируй понимание и получи подтверждение от пользователя
- Сохрани подтвержденное понимание в файл
.tasks/task-[feature-name]/phase1-requirements.md:
- Исходный запрос из $ARGUMENTS
- Уточняющие вопросы и ответы (если были)
- Резюме понимания задачи
- Ключевые требования и ограничения
- Подтверждение пользователя
Phase 2: Исследование кодовой базы 1C
Цель: понять существующий код и паттерны
ПРИНЦИПЫ АДАПТИВНОГО ИССЛЕДОВАНИЯ:
ТЫ ПРИНИМАЕШЬ РЕШЕНИЕ о стратегии исследования на основе:
- Оценки сложности из Phase 0
- Характера задачи (новая доработка vs расширение существующей)
- Того, насколько понятна область кодовой базы
Ключевой принцип: глубина важнее ширины - лучше запустить агентов последовательно для углубления, чем параллельно на одно и то же.
Твои решения:
-
Сколько агентов 1c-code-explorer запустить? (1-4+)
- Для простых задач может хватить одного
- Для сложных может понадобиться несколько с углублением
-
Параллельно или последовательно?
- Параллельно - если нужно изучить разные независимые области
- Последовательно - если нужно углубление: первый агент находит, второй копает глубже
-
На какие аспекты фокусироваться?
- Похожие доработки и паттерны
- Архитектура и слои абстракции
- Интеграции и зависимости
- Критичные компоненты, найденные предыдущими агентами
-
Итеративное углубление
- Можешь запустить агента, посмотреть результаты, решить нужно ли ещё углубление
- Каждый следующий агент может фокусироваться на находках предыдущих
Действия:
- Прими решение о стратегии исследования (обоснуй коротко)
- Запусти агентов
1c-code-explorer согласно своей стратегии:
- Передай путь к требованиям:
phase1-requirements.md
- Укажи фокус исследования для каждого агента (паттерны, архитектура, похожие доработки и т.д.)
- Каждый агент должен вернуть список нескольких ключевых файлов для чтения
- Прочитай все указанные файлы для глубокого понимания
- Оцени: достаточно ли понимания? Нужно ли ещё углубление? Если да - запусти ещё агентов
- Представь полную сводку найденных паттернов
- Сохрани сводку в файл
.tasks/task-[feature-name]/phase2-exploration.md:
- Найденные паттерны и соглашения
- Похожие доработки с ссылками на файлы
- Ключевые компоненты и их назначение
- Архитектурные инсайты
- Список всех прочитанных ключевых файлов
Phase 3: Уточняющие вопросы
Цель: заполнить пробелы и разрешить все неоднозначности ДО проектирования
Действия:
- Просмотри находки по кодовой базе и исходный запрос на доработку
- Выяви недетализированные аспекты: граничные случаи, обработка ошибок, точки интеграции, границы области, предпочтения дизайна, обратная совместимость, потребности производительности
- Представь все вопросы пользователю в ясном, организованном списке
- Жди ответов перед проектированием архитектуры
- Сохрани вопросы и ответы в файл
.tasks/task-[feature-name]/phase3-clarifications.md:
- Список вопросов с контекстом
- Ответы пользователя на каждый вопрос
- Принятые решения и рекомендации
Если пользователь говорит "как считаешь нужным", предоставь свою рекомендацию и получи явное подтверждение.
Phase 4: Проектирование архитектуры
Цель: спроектировать архитектуру реализации
АДАПТИВНЫЙ ПОДХОД - количество агентов зависит от сложности:
Простая задача (1 агент):
- Запусти 1 агента
1c-code-architect
- Создай один практичный план реализации
Средняя задача (1 агент + опциональное мультисэмплинг):
- По умолчанию: 1 агент с практичным планом
- Опционально: если решение неочевидно, можешь запустить 2 агента с разными подходами и выбрать лучший
Сложная/критичная задача (2-3 агента, мультисэмплинг):
- Запусти 2-3 агента
1c-code-architect параллельно с разным фокусом:
- Минимальные изменения (наименьшее изменение, максимальное переиспользование)
- Чистая архитектура (поддерживаемость, элегантные абстракции)
- Прагматичный баланс (скорость + качество)
- Сформируй мнение о лучшем подходе
- Представь пользователю все подходы с твоей рекомендацией
- Спроси пользователя, какой подход он предпочитает
Действия:
- Запусти агентов
1c-code-architect согласно сложности задачи:
- Передай пути к артефактам:
phase1-requirements.md, phase2-exploration.md, phase3-clarifications.md
- Для каждого агента укажи архитектурный подход (минимальные изменения / чистая архитектура / баланс)
- После выбора подхода создай файл
.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: Ревью плана
Цель: валидировать план ДО реализации — ошибки в плане обходятся дорого, весь код придётся переписывать.
Действия:
- Запусти агента
1c-code-architect для ревью плана:
- Передай пути к артефактам:
phase1-requirements.md, phase2-exploration.md, phase3-clarifications.md, phase4-architecture.md
- Фокус ревью:
- Полнота: все ли аспекты задачи покрыты?
- Корректность: соответствуют ли решения найденным паттернам из Phase 2?
- Реалистичность: можно ли реализовать план как описано?
- Соответствие требованиям: покрывает ли план все требования из Phase 1 и ответы из Phase 3?
- Критерии приемки этапов: достаточно ли чёткие и проверяемые?
- Зависимости: правильно ли выстроена последовательность этапов?
- Технический долг: есть ли известные проблемы, которые план усугубит?
- Если агент находит проблемы:
- Обнови план в
.tasks/task-[feature-name]/phase4-architecture.md
- Повтори Phase 5 (ревью обновлённого плана)
- Когда план одобрен агентом, сохрани результаты ревью в
.tasks/task-[feature-name]/phase5-plan-review.md:
- Что было проверено (полнота, корректность, реалистичность и т.д.)
- Какие проблемы были найдены и исправлены (если были)
- Итоговое заключение: план готов к реализации
- Представь план пользователю:
- Краткое резюме плана
- Этапы реализации с критериями приемки
- Спроси явно: "План готов к реализации, можем начинать?"
НЕ ПЕРЕХОДИ К PHASE 6 БЕЗ ЯВНОГО ОДОБРЕНИЯ ПОЛЬЗОВАТЕЛЯ
Phase 6: Реализация по этапам
Цель: построить доработку атомарными шагами с проверками приемки
НЕ НАЧИНАЙ БЕЗ ОДОБРЕНИЯ ПОЛЬЗОВАТЕЛЯ
Действия:
- Прочитай файл плана
.tasks/task-[feature-name]/phase4-architecture.md
- Для каждого этапа реализации последовательно:
a. Отметь этап в плане как начатый (измени
- [ ] на - [🔄] в файле плана)
b. Запусти агента 1c-code-writer для реализации этапа:
- Передай путь к плану
- Укажи конкретный этап для реализации
- Напомни про критерии приемки
c. Проверь критерии приемки этапа:
- Все файлы созданы/изменены как описано?
- Критерии приемки выполнены?
- Код соответствует правилам из
1c-rules.md?
d. Если критерии не выполнены:
- Запусти агента
1c-code-writer для исправления:
- Передай путь к плану и укажи этап
- Опиши найденные проблемы и что нужно исправить
- Повтори проверку критериев
- Повторяй цикл исправления, пока критерии приемки не будут выполнены
e. Отметь этап в плане как завершённый (измени
- [🔄] на - [x] в файле плана)
Phase 7: Ревью кода
Цель: убедиться, что код корректен, элегантен и соответствует плану
Действия:
- Запусти ревьюеров согласно размеру задачи:
- Простая:
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) с теми же инструкциями
- Консолидируй их ответы и выяви проблемы, требующие исправлений
- Сохрани результаты ревью в
.tasks/task-[feature-name]/phase7-code-review.md:
- Что было проверено (соответствие плану, качество, баги и т.д.)
- Найденные проблемы с severity и рекомендациями
- Итоговая оценка готовности кода
- Представь выявленные проблемы пользователю и спроси, что он хочет сделать:
- Исправить сейчас
- Исправить позже (добавить в TODO/технический долг)
- Продолжить как есть
- Если "исправить сейчас":
- Добавь проблемы в план в секцию "Исправления после ревью"
- Запусти агента
1c-code-writer для исправления:
- Передай путь к плану:
phase4-architecture.md
- Опиши проблемы из ревью и что нужно исправить
- Вернись к началу Phase 7 (повторное ревью)
- Повторяй итерации, пока ревьюеры не перестанут находить критические проблемы
- Если "исправить позже":
- Добавь проблемы в план в секцию "Технический долг"
- Отметь в плане как отложенные
Phase 8: Итоги
Цель: документировать выполненное
Действия:
- Отметь все задачи как завершённые
- Сохрани резюме в файл
.tasks/task-[feature-name]/phase8-summary.md:
- Что было построено (ссылки на этапы реализации)
- Ключевые принятые решения (ссылка на план)
- Изменённые файлы (git diff --stat)
- Оставшийся технический долг (если есть)
- Предлагаемые следующие шаги
- Представь резюме пользователю
