architect

name	architect
description	Архитектурный анализ и планирование реализации фич. Результат сохраняется в backlog/plans/<date>-<slug>.md по шаблону _specs/templates/plan.md. Используй при планировании, архитектуре, дизайне системы, новой фиче, как реализовать, продумать решение.

/architect — Architecture & Planning

Результат работы скилла = файл плана в backlog/plans/<YYYY-MM-DD>-<slug>.md, не сообщение в чат. Без согласования пользователем («делай» / «ок» / «поехали») план НЕ исполняется (см. .claude/rules/plan-before-act.md).

Instructions

1. Пойми задачу

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

• Что именно нужно реализовать?
• Какие ограничения/требования?
• Есть ли примеры/референсы?
• Есть ли связанный бриф в backlog/briefs/? Если нет — спроси, нужен ли сначала бриф (для крупных фич), или сразу план (для лёгких фич ≤1 день).

2. Изучи текущую архитектуру

Прочитай ключевые файлы проекта: handlers, services, models. Проверь documentation/ на существующие архитектурные решения.

3. Создай файл плана

Скопируй шаблон _specs/templates/plan.md в backlog/plans/<YYYY-MM-DD>-<slug>.md и заполни:

• Шапка: дата, источник (бриф из backlog/briefs/ если есть), статус = «план → ожидает согласования».
• Контекст — что знаем, ограничения, что пробовали.
• Подход — пошаговая архитектура решения:
  • Handler/Page слой — src/{path} (приём, валидация, вызов сервиса).
  • Service слой — src/{path} (бизнес-логика, оркестрация).
  • Repository/Model слой — src/{path} (доступ к данным, если нужно).
  • Модели данных (Pydantic / TypeScript / SQL).
  • Интеграции (какие сервисы затронуты, новые зависимости).
• Альтернативы (отвергнутые) — какие варианты рассмотрел и почему не он.
• Риски и митигации — таблица.
• Чек-лист реализации — - [ ] пункты от моделей данных к handler/тестам.
• Метрика «успех» — что должно работать после реализации.

4. Решение по _specs/<feature>/

Если фича крупная (>3 дней) и нужны архитектурные документы:

• Создай _specs/<feature>/ с tech-spec / user-spec / ADR.
• В плане (backlog/plans/<slug>.md) — ссылка на спеки, не дубль.

Если фича лёгкая — _specs/<feature>/ НЕ создавать. План-чек-лист в backlog/plans/ достаточен.

5. Принципы

ВСЕГДА следуй:

• KISS — простота важнее.
• YAGNI — не на будущее.
• SRP — одна ответственность.
• Async — все I/O через async/await (если применимо).

6. Покажи план пользователю

После заполнения файла:

• Дай путь к файлу backlog/plans/<...>.md.
• 3-5 строк краткого содержания (не пересказывай весь план).
• Жди явный сигнал «делай» / «ок» / «поехали». Уточняющие вопросы пользователя — НЕ согласование.

7. После согласования (исполнение)

• Идёшь по чек-листу плана сверху вниз.
• При отклонении от плана — обнови файл backlog/plans/<slug>.md, не отклоняйся молча.
• После реализации — план уезжает в backlog/archive/done/<slug>.md, факты о фиче — в documentation/ при необходимости.

Антипаттерны

• ❌ Возвращать план в чат вместо файла в backlog/plans/.
• ❌ Чек-лист в backlog/briefs/<slug>.md (это план — plans/<slug>.md).
• ❌ Создавать _specs/<feature>/plan.md (план только в backlog/plans/).
• ❌ Начинать реализацию сразу после показа плана, без явного сигнала.