AgentSkillsCN

architecture

在基于需求的架构设计中加以应用。对组件、技术栈、数据模型、API 以及基础设施进行全面而系统的调研。

SKILL.md
--- frontmatter
name: architecture
description: Используй при проектировании архитектуры на основе Requirements. Структурированное исследование компонентов, стека, модели данных, API и инфраструктуры.

Architecture: проектирование архитектуры

Цель

Превратить спецификацию требований в архитектурный документ с описанием компонентов системы, их взаимодействия, технического стека и модели данных через структурированный диалог.

Входные данные

Перед началом прочитай docs/PROJECT_BRIEF.md, docs/MVP_SCOPE.md и docs/REQUIREMENTS.md. Если какой-то файл не найден — сообщи пользователю и предложи сначала создать недостающий документ.

Процесс

Фаза 1: Валидация понимания

Кратко перескажи ключевые требования и ограничения (3-5 предложений) и спроси:

  1. •"Я правильно понимаю технический контекст? Что-то изменилось?"

Фаза 2: Технический стек

Задавай вопросы ПО ОДНОМУ. Жди ответа перед следующим.

  1. •"Есть ли предпочтения по языку и фреймворку для бэкенда? Например: [вариант A], [вариант B], [вариант C] — исходя из требований, я бы рекомендовал [вариант] потому что [причина]."
  2. •"Для фронтенда — есть ли предпочтения? Учитывая требование адаптивности, варианты: [A], [B], [C]."
  3. •"Какую базу данных предпочитаешь? Учитывая [характер данных из требований], подошли бы: [A], [B] — рекомендую [вариант] потому что [причина]."
  4. •"Нужны ли дополнительные инфраструктурные компоненты? Например: очередь задач, кэш, файловое хранилище?"

Фаза 3: Компоненты и их взаимодействие

  1. •"Я вижу следующие основные компоненты системы: [список]. Логично ли такое разделение? Что бы ты добавил или объединил?"
  2. •"Как компоненты общаются между собой? Варианты: [синхронные вызовы / очередь сообщений / события] — для [конкретного взаимодействия] рекомендую [вариант] потому что [причина]."
  3. •"Какие внешние сервисы нужно интегрировать? Как система должна себя вести при их недоступности?"

Фаза 4: Модель данных

  1. •"Вот основные сущности, которые я вижу из требований: [список]. Какие связи между ними? Что упущено?"
  2. •"Какие данные меняются часто, а какие почти статичны? Это влияет на стратегию хранения и кэширования."
  3. •"Есть ли данные, требующие особого обращения? Токены, ключи, персональные данные?"

Фаза 5: API и контракты

  1. •"Какой стиль API предпочитаешь? REST, GraphQL, или гибрид? Для этого проекта рекомендую [вариант] потому что [причина]."
  2. •"Какие основные эндпоинты нужны для покрытия сценариев из MVP Scope?"

Фаза 6: Деплой и инфраструктура

  1. •"Где планируешь хостить? Варианты: [A], [B], [C] — с учётом масштаба MVP рекомендую [вариант]."
  2. •"Нужен ли CI/CD в MVP? Если да — какой уровень: только тесты, или полный пайплайн до деплоя?"

Фаза 7: Формирование документа

Когда все ответы собраны — представь Architecture блоками по 200-300 слов. После каждого блока спрашивай: "Эта часть выглядит верно?" Будь готов вернуться и уточнить, если что-то не сходится.

Результат

После валидации всех блоков создай файл docs/ARCHITECTURE.md:

markdown
# Architecture: [Название проекта]

## Обзор

[Высокоуровневое описание архитектуры: тип приложения, ключевые архитектурные решения,
связь с требованиями. 3-4 предложения]

## Технический стек

| Компонент | Технология | Обоснование |
|---|---|---|
| [Язык бэкенда] | [Технология] | [Почему выбрана] |
| [Фреймворк бэкенда] | [Технология] | [Почему выбран] |
| [Фронтенд] | [Технология] | [Почему выбран] |
| [База данных] | [Технология] | [Почему выбрана] |
| [Инфраструктура] | [Технология] | [Почему выбрана] |

## Компоненты системы

### [Компонент 1]

**Ответственность:** [Что делает этот компонент]

**Взаимодействует с:** [Список компонентов]

**Ключевые решения:** [Почему спроектирован именно так]

### [Компонент N]

[Аналогичная структура]

## Модель данных

### [Сущность 1]

| Поле | Тип | Описание |
|---|---|---|
| [Поле] | [Тип] | [Назначение, если неочевидно] |

**Связи:** [С какими сущностями и как связана]

### [Сущность N]

[Аналогичная структура]

## API

### [Группа эндпоинтов]

| Метод | Путь | Описание |
|---|---|---|
| [GET/POST/...] | [/api/...] | [Что делает] |

## Взаимодействие компонентов

[Описание ключевых потоков данных через систему.
Как проходит запрос от пользователя через компоненты до результата.
Для сложных потоков — текстовое описание последовательности шагов]

## Инфраструктура и деплой

**Хостинг:** [Где и как]

**CI/CD:** [Пайплайн, если есть]

**Мониторинг:** [Что отслеживаем в MVP]

## Решения и компромиссы

| Решение | Альтернативы | Почему выбрано |
|---|---|---|
| [Что решили] | [Что рассматривали] | [Аргументы] |

## Структура проекта

[Описание организации кода: директории, модули, слои]

Ключевые принципы

  • •Один вопрос за раз — не перегружай собеседника множеством вопросов
  • •Варианты ответов предпочтительнее — предлагай 2-3 варианта с обоснованием, на них проще отвечать
  • •Рекомендуй с аргументами — не просто предлагай варианты, а говори какой рекомендуешь и почему
  • •Архитектура следует из требований — каждое решение должно быть обосновано конкретным требованием
  • •Простота для MVP — не проектируй систему для миллиона пользователей, если MVP для десяти
  • •Челлендж overengineering — "нужен ли Kubernetes для MVP?" — скорее всего нет
  • •Документируй компромиссы — каждое решение имеет trade-off, фиксируй их
  • •Инкрементальная валидация — представляй документ блоками, проверяй каждый
  • •Будь гибким — возвращайся и уточняй ранние решения, если что-то не сходится