change-plan-architect - SKILL.md Agent Skill

name: change-plan-architect description: "Сформировать план внедрения изменения после анализа текущего кода, контрактов, зависимостей и недостающих ресурсов. Использовать для задач средней сложности: поиск блокеров, выявление пробелов в API/контрактах и безопасная поэтапная поставка."

Change Plan Architect

Назначение

Скилл готовит короткий, исполнимый план изменений: что делать, в каком порядке, какие зависимости закрыть заранее и где нельзя продолжать без явного решения по контрактам или данным.

Shared Runtime Contract

Применить общий booster-контракт из booster-runtime-contract.md.

Режим выполнения

Позиция по умолчанию: report-only.

Порядок работы

Зафиксировать цель, границы задачи и явные не-цели.
Явно сохранять report-only posture и делать минимальные безопасные допущения только там, где нет блокирующей неоднозначности.
Кратко описать текущее состояние: какие модули, контуры и контракты затронуты.
Выявить блокеры и пробелы:

API/схемы/права/внешние сервисы;
отсутствующие данные и артефакты;
неоднозначные допущения.

Для migration/CLI/operator-фаз построить карту предметных зависимостей:

какие данные, классификаторы, состояния и правила нужны командам для реальной ценности;
что из этого уже есть в target system, а что пока только в legacy/raw payload.

Для migration/cutover-фаз отдельно классифицировать состояние переноса:

entrypoint migrated;
execution migrated;
state/storage migrated;
legacy runtime still required.

Для migration/cutover-фаз явно описать:

какой код реально исполняется в target system;
какой код и side effects всё ещё живут в legacy/external runtime;
где находятся working directory, логи, сессии, lock-файлы и иные операционные артефакты.

Проверить риск дублирования между проектами и явно решить:

переиспользуем общий слой;
или временно оставляем локально с обоснованием и сроком пересмотра.

Применить guard по UX-сложности из references/ux-complexity-guard.md.
Сформировать короткий поэтапный план:

шаг;
предусловия;
ответственный Tier/роль и конкретный skill-исполнитель для реализации;
проверка готовности.

Добавить компактные review-ready секции:

Product Review Snapshot: пользовательская ценность, acceptance path, scope tradeoffs;
Engineering Review Snapshot: архитектура, trust boundaries, тестовая стратегия, rollback ожидания.

Зафиксировать риски, rollback и критерии Go/No-Go.

Обязательный анализ пробелов

Прочитать references/resource-gap-checklist.md и включить релевантные категории в план.

Формат результата

Execution Posture
Целевая возможность
Текущее состояние
Current-State Assessment
Контур миграции/cutover
Карта влияния
Пробелы и недостающие ресурсы
Допущения и открытые вопросы
Решение по дублированию
Матрица active/deferred/read-only/legacy-required
Product Review Snapshot
Engineering Review Snapshot
Этапы внедрения
Маршрутизация по Tier/ролям
План проверки
Риски и меры снижения
Критерии Go/No-Go
Решение по UX-сложности

Правила качества

Основной язык: русский.
Каждый блокирующий пробел явно помечать как блокирующий, а не прятать в текст.
Не считать перенос команд/экранов достаточным, если не закрыты предметные предпосылки.
Держать план коротким: один основной документ по умолчанию, без лишних матриц и служебных заметок.
Не смешивать проектирование и реализацию в одном непроверяемом шаге.
План без Маршрутизация по Tier/ролям, без конкретного skill-исполнителя на существенном шаге реализации или с placeholder TBD/unassigned считается дефектным и не готов к передаче.
Для migration/cutover-планов не считать operator/CLI cutover завершённой миграцией, если execution layer или state/storage остаются в legacy/external runtime.
Если legacy/external runtime всё ещё нужен, план обязан явно показать это в контуре миграции и в матрице состояния, а не прятать в примечания.