# 1c Feature Dev

> Этот скилл следует использовать, когда пользователь просит "создать доработку 1C", "реализовать функционал 1C", "добавить новую возможность в 1C", "разработать модуль 1C", "сделать доработку в 1С" или нуждается в полном цикле разработки 1C-доработок от анализа до реализации с валидацией плана и проверками приемки

- Skill: `diversus23/1c-feature-dev` (Agent Skill)
- Install (CLI): `npx skillmds@latest add diversus23/1c-feature-dev`
- Raw SKILL.md: https://api.skillmd.com/api/skills/diversus23/1c-feature-dev/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Diversus23 (https://skillmd.com/u/diversus23)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/diversus23/1c-feature-dev

---


## Принципы

- **Адаптивность**: глубина анализа и количество агентов зависят от сложности
- **Ранняя валидация**: ревью плана до реализации, а не после
- **Атомарные шаги**: этапы с критериями приемки и проверками
- **Отслеживание прогресса**: отмечай завершённые фазы в списке задач
- **Устойчивость к сбоям агентов**: если агент вернул пустой, бесполезный или противоречивый результат — перезапусти с уточнённым фокусом (макс. 1 повтор). При повторной неудаче — продолжай своими силами и отметь это в артефакте

### Артефакты

Папка задачи: `.tasks/[YYYY]/[MM]/[DD]/[feature-name]/` (дата начала работы).

| Файл | Фаза | Описание |
|------|------|----------|
| `01-requirements.md` | 1 | Требования, оценка сложности |
| `02-exploration.md` | 2 | Паттерны, архитектура, уточнения |
| `03-architecture.md` | 3 | План реализации с архитектурными инвариантами |
| `04-plan-review.md` | 4 | Ревью плана (сложные/критичные) |
| `05-implementation-stage-NN.md` | 5 | Отчёт по этапу N: что сделано, файлы, решения, контекст для следующего этапа |
| `05-implementation-summary.md` | 5 | Итоговый лог реализации (создаётся после завершения ВСЕХ этапов) |
| `06-code-review.md` | 6 | Результаты ревью кода |
| `07-summary.md` | 7 | Итоговое резюме |
| `08-documentation.md` | 7 | Лог генерации документации (опционально) |

Файл создаётся только если для него есть содержание.

`05-implementation-stage-NN.md` создаётся **после каждого завершённого этапа** — это обеспечивает возможность продолжения работы в новом чате с точного места остановки.

### Передача контекста агентам

При запуске любого агента передавай **полные пути** к артефактам от корня проекта, например: `.tasks/2026/02/12/print-form-invoice/01-requirements.md`. Агенты работают в изоляции и не знают текущую папку задачи.

### Возобновление задачи

Если пользователь просит продолжить ранее начатую задачу — найди папку в `.tasks/` и определи фазу по артефактам:

- Есть `08-documentation.md` → задача завершена полностью (включая документацию), сообщи пользователю
- Есть `07-summary.md` → проверь конфигурацию документации в `CLAUDE.md` целевого проекта: если `documentation: true` → продолжи с шага 4 Фазы 7 (документация); если нет → задача завершена, сообщи пользователю
- Есть `06-code-review.md` → продолжи с Фазы 7 (итоги)
- Есть `05-implementation-summary.md` → продолжи с Фазы 6 (ревью)
- Есть файлы `05-implementation-stage-*.md` → **возобновление внутри Фазы 5**:
  1. Прочитай `03-architecture.md` → определи общее количество этапов
  2. Найди все `05-implementation-stage-NN.md` → определи последний
  3. Прочитай последний stage-файл → проверь статус:
     - `Статус: ЗАВЕРШЁН` → следующий этап = NN + 1
     - `Статус: В РАБОТЕ` → этап был прерван, продолжи его (проверь `git diff` для понимания что уже сделано)
  4. Прочитай секцию **«Контекст для следующего этапа»** из последнего завершённого stage-файла
  5. Если NN < общего количества этапов → продолжи Фазу 5 с этапа NN+1
  6. Если NN = общему количеству → все этапы завершены, создай `05-implementation-summary.md` и перейди к Фазе 6
- Есть `03-architecture.md` с `- [ ]` или `- [ ] 🔄`, нет файлов `05-implementation-stage-*` → начни Фазу 5 с Этапа 1
- Есть `03-architecture.md` без незакрытых этапов → продолжи с Фазы 4 (валидация)
- Есть `02-exploration.md`, нет `03-architecture.md` → продолжи с Фазы 3 (архитектура)
- Есть только `01-requirements.md` → продолжи с Фазы 2 (исследование)

Прочитай все существующие артефакты для восстановления контекста. При возобновлении Фазы 5 обрати особое внимание на stage-файлы — они содержат полный контекст каждого выполненного этапа.

### Оценка сложности

| Уровень | Описание | Пример |
|---------|----------|--------|
| **Простая** | Очевидная реализация, 1-2 файла | Добавить реквизит, простой обработчик |
| **Средняя** | Несколько модулей, понимание архитектуры | Новая печатная форма, доработка формы |
| **Сложная** | Несколько подсистем, неочевидные решения | Новый документооборот, интеграция |
| **Критичная** | Архитектурные изменения, высокие риски | Переработка подсистемы, миграция |

Сложность определяет поведение в каждой фазе (см. пометки «адаптивность»).

---

## Фаза 0: Проверка окружения

**Цель**: убедиться, что обязательные MCP-серверы доступны до начала работы

**Действия**:

1. Проверь доступность каждого обязательного MCP-сервера — вызови любой базовый tool:
   - **EDT MCP Server** (поиск метаданных, проверка синтаксиса)
2. Составь карту доступности и сообщи пользователю: какие MCP доступны, какие нет
3. **Если обязательный MCP недоступен** → ОСТАНОВИСЬ. Сообщи пользователю:
   - Какой сервер недоступен
   - Зачем он нужен
   - Ссылку на установку (см. `mcp-requirements.md`)
   - Предложи: запустить сервер и повторить, или продолжить без MCP (с предупреждением о рисках)
4. **Если все обязательные MCP доступны** → переходи к Фазе 1

---

## Фаза 1: Сбор требований

**Цель**: понять задачу, уточнить неясности, оценить масштаб

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

**Действия**:
1. Если запрос неясен — спроси: какую проблему решает, что должна делать доработка, есть ли ограничения
2. Резюмируй понимание и получи подтверждение
3. Оцени сложность (см. таблицу выше), обоснуй
4. Создай папку задачи, список задач со всеми фазами
5. Сохрани `01-requirements.md`: исходный запрос, Q&A, резюме, требования, сложность

---

## Фаза 2: Исследование кодовой базы

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

**Адаптивность**: решай сам — сколько агентов `1c-code-explorer` запустить (1-4), параллельно или последовательно. Глубина важнее ширины: лучше углубиться последовательно, чем дублировать параллельно.

Типичные фокусы для агентов (распределяй по необходимости):
- **Метаданные и структура**: объекты метаданных, реквизиты, табличные части, формы
- **Потоки выполнения**: цепочки вызовов, обработчики, точки входа в затрагиваемых модулях
- **Похожие доработки**: паттерны реализации аналогичных задач в кодовой базе
- **Зависимости и влияние**: кто использует затрагиваемые объекты, оценка каскадных изменений

**Действия**:

1. Запусти агентов `1c-code-explorer` с путём к `01-requirements.md` и указанием фокуса
2. Прочитай ключевые файлы, возвращённые агентами
3. Если понимания недостаточно — запусти ещё агентов для углубления
4. **Если после исследования появились технические вопросы** (граничные случаи, обработка ошибок, интеграции, обратная совместимость, производительность) — задай их пользователю и дождись ответов
5. **Переоцени сложность**: если исследование показало, что задача сложнее/проще, чем оценено в Фазе 1 — обнови оценку в `01-requirements.md` и скорректируй подход
6. Сохрани `02-exploration.md`: паттерны, похожие доработки, ключевые компоненты, архитектурные инсайты, прочитанные файлы, Q&A (если были)

---

## Фаза 3: Проектирование архитектуры

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

**Адаптивность**:
- **Простая/средняя**: 1 агент `1c-code-architect`, один практичный план. Для средней — опционально 2 агента, если решение неочевидно
- **Сложная/критичная**: 2-3 агента параллельно (минимальные изменения / чистая архитектура / прагматичный баланс). Представь все варианты с рекомендацией, спроси пользователя

**Действия**:
1. Запусти агентов с путями к `01-requirements.md`, `02-exploration.md`
2. Создай `03-architecture.md`:
   - Постановка задачи, сложность, выбранный подход с обоснованием
   - Паттерны и соглашения из Фазы 2
   - **Архитектурные инварианты** — список правил, которые НЕЛЬЗЯ нарушить при реализации ни на одном этапе. Примеры:
     - «Все обращения к контрагентам ТОЛЬКО через модуль КонтрагентыСервер»
     - «Регистр обновляется ТОЛЬКО при проведении документа»
     - «Форма НЕ обращается к БД напрямую — только через серверные методы»
     - «Обращение к реквизитам через ОбщегоНазначения.ЗначениеРеквизитаОбъекта»
     - Инварианты формулируются на основе: правил из `1c-rules.md`, паттернов из `02-exploration.md`, специфики конкретной задачи
   - **Этапы реализации** (чеклист):
     - Гранулярность: простая = 1, средняя = 2-4, сложная = 4-8, критичная = 5-10+
     - Атомарность: этап завершается за 1 сессию агента, имеет проверяемый результат
     - Формат: `- [ ] **Этап N**: описание + файлы + критерии приемки + зависимости`
     - Каждый этап включает поле **«Контекст для следующего этапа»**: что создаётся на этом этапе и понадобится на следующих (экспортные процедуры, объекты метаданных, зависимости)
   - Mermaid-диаграммы (архитектура, потоки данных)
   - План самодостаточен — понятен без контекста беседы

---

## Фаза 4: Валидация плана

**Цель**: убедиться в корректности плана ДО реализации

### Ревью агентом (только сложные/критичные)

1. Запусти агента `1c-code-architect` для ревью
2. Передай все артефакты: `01-requirements.md`, `02-exploration.md`, `03-architecture.md`
3. Фокус: полнота, корректность, реалистичность, зависимости этапов
4. При проблемах — обнови `03-architecture.md`, повтори ревью (макс. 2 итерации)
5. Сохрани `04-plan-review.md`

### Одобрение пользователем (ВСЕ задачи, включая простые)

1. Представь план: краткое резюме + этапы с критериями приемки
2. Спроси: «План готов к реализации, можем начинать?»
3. **Если пользователь отклоняет или просит изменения**:
   - Уточни, что именно не устраивает
   - Скорректируй `03-architecture.md`
   - Представь обновлённый план повторно

**НЕ ПЕРЕХОДИ К ФАЗЕ 5 БЕЗ ЯВНОГО ОДОБРЕНИЯ ПОЛЬЗОВАТЕЛЯ**

---

## Фаза 5: Реализация

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

**Адаптивность**:

- **До 4 этапов**: один агент `1c-code-writer` на все этапы
- **5+ этапов**: разбей на группы по 3-4 этапа, запускай агентов последовательно. Каждый следующий получает путь к плану, предыдущие stage-файлы и информацию, какие этапы уже выполнены

**Действия**:

1. Прочитай `03-architecture.md`, включая секцию **«Архитектурные инварианты»**
2. **Если это возобновление** — прочитай все существующие `05-implementation-stage-*.md` и определи, с какого этапа продолжать (см. «Возобновление задачи»)
3. Запусти агента `1c-code-writer`:
   - Передай путь к плану и укажи правила: `1c-rules.md`, `1c-ssl.md`, `1c-edt-metadata.md`
   - Если доработка затрагивает запросы — дополнительно укажи `1c-query-optimization.md`
   - Передай архитектурные инварианты из `03-architecture.md`
   - Если есть предыдущие stage-файлы — передай путь к последнему (секция «Контекст для следующего этапа»)
   - Этапы последовательно, с критериями приемки
   - **Агент ОБЯЗАН обновлять чеклист этапов в `03-architecture.md`**: при начале этапа `- [ ]` → `- [ ] 🔄`, при завершении `- [ ] 🔄` → `- [x]`
4. **После каждого завершённого этапа** — агент создаёт `05-implementation-stage-NN.md` (NN = номер этапа с ведущим нулём):

   ```markdown
   # Этап N: <название из плана>

   ## Статус: ЗАВЕРШЁН | В РАБОТЕ

   ## Что сделано
   - <конкретные действия>

   ## Изменённые файлы
   - <путь к файлу> (создан | изменён, строки X-Y)

   ## Ключевые решения
   - <решение и обоснование>

   ## Архитектурные инварианты (проверено)
   - [x] <инвариант 1>
   - [x] <инвариант 2>

   ## Контекст для следующего этапа
   - <экспортные процедуры, созданные объекты, зависимости — всё, что нужно знать для продолжения>
   ```

5. **Мини-валидация после каждого этапа** (DoD):
   - Проверь критерии приемки этапа из `03-architecture.md`
   - Запусти MCP-валидацию изменённых объектов (синтаксис, ошибки проекта)
   - Проверь архитектурные инварианты
   - Если критерии НЕ выполнены или есть ошибки → исправь до перехода к следующему этапу
   - Обнови статус в stage-файле: `В РАБОТЕ` → `ЗАВЕРШЁН` только после прохождения валидации
6. **Пауза между этапами** (опционально):
   - Проверь `CLAUDE.md` целевого проекта на наличие настройки `pause_between_stages: true` (в секции `1c-feature-dev`)
   - Если `true` → после каждого этапа сообщи пользователю: «Этап N завершён (N из M). Продолжить с Этапом N+1 или хотите проверить результат?»
   - Если настройка отсутствует или `false` → продолжай автоматически
7. При невыполненных этапах — запусти агента повторно с описанием оставшегося и путём к последнему stage-файлу
8. **После завершения ВСЕХ этапов** — создай `05-implementation-summary.md`:

   ```markdown
   # Итог реализации

   ## Статус: ВСЕ ЭТАПЫ ЗАВЕРШЕНЫ (N/N)

   ## Выполненные этапы
   | Этап | Описание | Файл отчёта |
   |------|---------|-------------|
   | 1 | <описание> | 05-implementation-stage-01.md |
   | 2 | <описание> | 05-implementation-stage-02.md |

   ## Все изменённые файлы
   - <сводный список из всех stage-файлов>

   ## Технический долг
   - <если что-то осталось>
   ```

---

## Фаза 6: Ревью кода

**Цель**: проверить качество кода и валидировать через MCP

**Адаптивность**: для простых задач — пропусти ревью агентом, но MCP-валидацию выполни всегда.

**Действия**:

1. **MCP-валидация** (все задачи): запусти перевалидацию изменённых объектов через MCP, проверь отсутствие новых ошибок проекта. При наличии ошибок — исправь до ревью
2. **Ревью агентом** (средние, сложные, критичные): запусти `1c-code-reviewer` с путями к `03-architecture.md` и `05-implementation-summary.md` (список изменённых файлов)
   - Фокус: баги, соответствие плану, `1c-rules.md`, читаемость, DRY
   - Reviewer решает, нужен ли `1c-code-simplifier` — если код избыточно сложен, запускает его самостоятельно
3. Сохрани `06-code-review.md`
4. Представь проблемы пользователю, спроси:
   - **Исправить сейчас** → запусти `1c-code-writer`, затем повторное ревью (макс. 2 итерации)
   - **Исправить позже** → добавь в `03-architecture.md` секцию «Технический долг»
   - **Продолжить как есть**

---

## Фаза 7: Итоги

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

**Действия**:

1. Отметь все задачи как завершённые
2. Сохрани `07-summary.md`:
   - Что построено (ссылки на этапы)
   - Ключевые решения
   - Изменённые файлы (`git diff --stat`)
   - Технический долг (если есть)
   - Предлагаемые следующие шаги
3. **Если доработка содержит бизнес-логику** — предложи пользователю сгенерировать тесты агентом `1c-code-test-generator` (YaXUnit / Vanessa Automation)
4. **Документация** (опционально):
   - Прочитай `CLAUDE.md` целевого проекта (корень проекта)
   - Найди секцию `## Documentation` (или `## Документация`)
   - Если секция существует и `documentation: true`:
     a. Извлеки конфигурацию: `documentation-types` (по умолчанию `[technical, user]`), `documentation-technical-path` (по умолчанию `docs/technical/`), `documentation-user-path` (по умолчанию `docs/user/`)
     b. Спроси пользователя: «Сгенерировать документацию для этой доработки? Настроенные типы: {documentation-types}»
     c. При согласии — запусти агента `1c-code-documenter`:
        - Передай пути к артефактам: `01-requirements.md`, `03-architecture.md`, `05-implementation-summary.md`, `07-summary.md`
        - Передай `documentation-types`, `documentation-technical-path`, `documentation-user-path` из конфигурации
     d. Сохрани `08-documentation.md`: какие файлы документации созданы, пути к ним
   - Если секция отсутствует или `documentation: false` — пропусти молча
5. Представь резюме пользователю