Запись об архитектурном решении (ADR)

Помогает выбрать между технологиями и оформить решение: варианты, плюсы и минусы, компромиссы и последствия.

СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: Помогает выбрать между технологиями и оформить решение: варианты, плюсы и минусы, компромиссы и последствия.
Когда брать: Когда нужно выбрать технологию, зафиксировать проектное решение, оценить чужой проект системы или спроектировать новый компонент.
Когда не брать: Если вопрос не про устройство программных систем.
Пример запроса: Что нам выбрать для шины событий, Kafka или SQS? Оформи решение как ADR.

Входит в плагин engineering. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

Нажмите «Скачать на русском» и сохраните архив.
В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
Включите скилл переключателем.

Для терминала

Распакуйте архив и положите папку architecture в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.

Текст

---
name: architecture
description: Создай или оцени запись об архитектурном решении (ADR). Используй, когда выбираешь между технологиями (например, Kafka и SQS), документируешь проектное решение с компромиссами и последствиями, проверяешь предложение по проектированию системы или проектируешь новый компонент по требованиям и ограничениям.
argument-hint: "<decision or system to design>"
---

/architecture

Если встретишь незнакомые подстановки или нужно проверить, какие инструменты подключены, смотри [CONNECTORS.md](../../CONNECTORS.md).

Создай запись об архитектурном решении (Architecture Decision Record, ADR) или оцени проект системы.

Использование

/architecture $ARGUMENTS

Режимы

Создать ADR: «Что нам выбрать для шины событий — Kafka или SQS?» Оценить проект: «Проверь это предложение по микросервисам» Проектирование системы: «Спроектируй систему уведомлений для нашего приложения»

Подробные схемы сбора требований, анализа масштабируемости и оценки компромиссов — в скилле system-design.

Результат — формат ADR

# ADR-[номер]: [Название]

**Статус:** Предложено | Принято | Устарело | Заменено
**Дата:** [Дата]
**Принимающие решение:** [Кто должен утвердить]

## Контекст
[Какая ситуация? Какие силы действуют?]

## Решение
[Какое изменение мы предлагаем?]

## Рассмотренные варианты

### Вариант A: [Название]
| Параметр | Оценка |
|-----------|------------|
| Сложность | [Низкая/Средняя/Высокая] |
| Стоимость | [Оценка] |
| Масштабируемость | [Оценка] |
| Знакомство команды | [Оценка] |

**Плюсы:** [Список]
**Минусы:** [Список]

### Вариант B: [Название]
[Тот же формат]

## Анализ компромиссов
[Ключевые компромиссы между вариантами с чёткими доводами]

## Последствия
- [Что становится проще]
- [Что становится сложнее]
- [К чему нам придётся вернуться]

## Задачи
1. [ ] [Шаг реализации]
2. [ ] [Последующее действие]

Если подключены коннекторы

Если подключена ~~knowledge base:

Ищи прошлые ADR и проектные документы
Находи нужный технический контекст

Если подключён ~~project tracker:

Связывай с соответствующими эпиками и тикетами
Создавай задачи на реализацию

Советы

Сразу назови ограничения — «Нам нужно выпустить за 2 недели» или «Должна выдерживать 10 тыс. запросов в секунду» определяют ответ.
Назови варианты — даже если ты склоняешься к одному, при явных альтернативах я дам более взвешенный анализ.
Учитывай нефункциональные требования — задержка, стоимость, опыт команды и затраты на поддержку важны не меньше, чем функции.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/engineering/skills/architecture, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском

---
name: architecture
description: Create or evaluate an architecture decision record (ADR). Use when choosing between technologies (e.g., Kafka vs SQS), documenting a design decision with trade-offs and consequences, reviewing a system design proposal, or designing a new component from requirements and constraints.
argument-hint: "<decision or system to design>"
---

# /architecture

> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).

Create an Architecture Decision Record (ADR) or evaluate a system design.

## Usage

```
/architecture $ARGUMENTS
```

## Modes

**Create an ADR**: "Should we use Kafka or SQS for our event bus?"
**Evaluate a design**: "Review this microservices proposal"
**System design**: "Design the notification system for our app"

See the **system-design** skill for detailed frameworks on requirements gathering, scalability analysis, and trade-off evaluation.

## Output — ADR Format

```markdown
# ADR-[number]: [Title]

**Status:** Proposed | Accepted | Deprecated | Superseded
**Date:** [Date]
**Deciders:** [Who needs to sign off]

## Context
[What is the situation? What forces are at play?]

## Decision
[What is the change we're proposing?]

## Options Considered

### Option A: [Name]
| Dimension | Assessment |
|-----------|------------|
| Complexity | [Low/Med/High] |
| Cost | [Assessment] |
| Scalability | [Assessment] |
| Team familiarity | [Assessment] |

**Pros:** [List]
**Cons:** [List]

### Option B: [Name]
[Same format]

## Trade-off Analysis
[Key trade-offs between options with clear reasoning]

## Consequences
- [What becomes easier]
- [What becomes harder]
- [What we'll need to revisit]

## Action Items
1. [ ] [Implementation step]
2. [ ] [Follow-up]
```

## If Connectors Available

If **~~knowledge base** is connected:
- Search for prior ADRs and design docs
- Find relevant technical context

If **~~project tracker** is connected:
- Link to related epics and tickets
- Create implementation tasks

## Tips

1. **State constraints upfront** — "We need to ship in 2 weeks" or "Must handle 10K rps" shapes the answer.
2. **Name your options** — Even if you're leaning one way, I'll give a more balanced analysis with explicit alternatives.
3. **Include non-functional requirements** — Latency, cost, team expertise, and maintenance burden matter as much as features.

Источник: anthropics/knowledge-work-plugins / engineering / architecture ↗. Ссылка проверена 2026-10-10.

---
name: architecture
description: Создай или оцени запись об архитектурном решении (ADR). Используй, когда выбираешь между технологиями (например, Kafka и SQS), документируешь проектное решение с компромиссами и последствиями, проверяешь предложение по проектированию системы или проектируешь новый компонент по требованиям и ограничениям.
argument-hint: "<decision or system to design>"
---

# /architecture

> Если встретишь незнакомые подстановки или нужно проверить, какие инструменты подключены, смотри [CONNECTORS.md](../../CONNECTORS.md).

Создай запись об архитектурном решении (Architecture Decision Record, ADR) или оцени проект системы.

## Использование

```
/architecture $ARGUMENTS
```

## Режимы

**Создать ADR**: «Что нам выбрать для шины событий — Kafka или SQS?»
**Оценить проект**: «Проверь это предложение по микросервисам»
**Проектирование системы**: «Спроектируй систему уведомлений для нашего приложения»

Подробные схемы сбора требований, анализа масштабируемости и оценки компромиссов — в скилле **system-design**.

## Результат — формат ADR

```markdown
# ADR-[номер]: [Название]

**Статус:** Предложено | Принято | Устарело | Заменено
**Дата:** [Дата]
**Принимающие решение:** [Кто должен утвердить]

## Контекст
[Какая ситуация? Какие силы действуют?]

## Решение
[Какое изменение мы предлагаем?]

## Рассмотренные варианты

### Вариант A: [Название]
| Параметр | Оценка |
|-----------|------------|
| Сложность | [Низкая/Средняя/Высокая] |
| Стоимость | [Оценка] |
| Масштабируемость | [Оценка] |
| Знакомство команды | [Оценка] |

**Плюсы:** [Список]
**Минусы:** [Список]

### Вариант B: [Название]
[Тот же формат]

## Анализ компромиссов
[Ключевые компромиссы между вариантами с чёткими доводами]

## Последствия
- [Что становится проще]
- [Что становится сложнее]
- [К чему нам придётся вернуться]

## Задачи
1. [ ] [Шаг реализации]
2. [ ] [Последующее действие]
```

## Если подключены коннекторы

Если подключена **~~knowledge base**:
- Ищи прошлые ADR и проектные документы
- Находи нужный технический контекст

Если подключён **~~project tracker**:
- Связывай с соответствующими эпиками и тикетами
- Создавай задачи на реализацию

## Советы

1. **Сразу назови ограничения** — «Нам нужно выпустить за 2 недели» или «Должна выдерживать 10 тыс. запросов в секунду» определяют ответ.
2. **Назови варианты** — даже если ты склоняешься к одному, при явных альтернативах я дам более взвешенный анализ.
3. **Учитывай нефункциональные требования** — задержка, стоимость, опыт команды и затраты на поддержку важны не меньше, чем функции.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/engineering/skills/architecture, лицензия Apache-2.0. Изменения: перевод на русский язык.