Architecture Decision Records
Этот skill нужен для случаев, когда решение уже влияет на архитектуру, процесс разработки или операционную модель и его нужно зафиксировать так, чтобы команда потом могла понять не только что выбрали, но и почему.
Когда использовать
Используй skill, если нужно зафиксировать:
- выбор архитектурного подхода или шаблона интеграции;
- новый основной стек, storage, queue, runtime или API-подход;
- важное security-решение;
- значимую смену направления с явными trade-offs;
- решение, которое потом придется защищать, пересматривать или supersede.
Базовый workflow
- Опиши контекст, ограничения и decision drivers.
- Выдели реальные варианты, которые рассматривались.
- Зафиксируй выбранное решение и аргументацию.
- Отдельно опиши последствия: хорошие, плохие, риски, follow-up.
- Обозначь статус решения и связи с другими ADR.
Ключевые правила
- ADR не должен быть пересказом финального решения без контекста.
- Для каждого варианта нужны осмысленные trade-offs, а не декоративный список.
- Решение должно быть привязано к ограничениям и ожидаемым последствиям.
- Если решение временное или спорное, это нужно писать явно.
- Если решение потом отменят, новый ADR должен ссылаться на предыдущий, а не стирать историю.
Карта reference-файлов
references/adr-template.md -> шаблон ADR и короткие правила заполнения
Формат ответа
Когда просят оформить ADR, возвращай:
- Название решения и статус.
- Контекст и decision drivers.
- Рассмотренные варианты и trade-offs.
- Принятое решение и rationale.
- Последствия, риски и follow-up шаги.
1---2name: architecture-decision-records3description: Фиксировать значимые архитектурные решения в ADR: контекст, варианты, выбранное решение, trade-offs и последствия.4---56# Architecture Decision Records78Этот skill нужен для случаев, когда решение уже влияет на архитектуру, процесс разработки или операционную модель и его нужно зафиксировать так, чтобы команда потом могла понять не только что выбрали, но и почему.910## Когда использовать1112Используй skill, если нужно зафиксировать:1314- выбор архитектурного подхода или шаблона интеграции;15- новый основной стек, storage, queue, runtime или API-подход;16- важное security-решение;17- значимую смену направления с явными trade-offs;18- решение, которое потом придется защищать, пересматривать или supersede.1920## Базовый workflow21221. Опиши контекст, ограничения и decision drivers.232. Выдели реальные варианты, которые рассматривались.243. Зафиксируй выбранное решение и аргументацию.254. Отдельно опиши последствия: хорошие, плохие, риски, follow-up.265. Обозначь статус решения и связи с другими ADR.2728## Ключевые правила2930- ADR не должен быть пересказом финального решения без контекста.31- Для каждого варианта нужны осмысленные trade-offs, а не декоративный список.32- Решение должно быть привязано к ограничениям и ожидаемым последствиям.33- Если решение временное или спорное, это нужно писать явно.34- Если решение потом отменят, новый ADR должен ссылаться на предыдущий, а не стирать историю.3536## Карта reference-файлов3738- `references/adr-template.md` -> шаблон ADR и короткие правила заполнения3940## Формат ответа4142Когда просят оформить ADR, возвращай:43441. Название решения и статус.452. Контекст и decision drivers.463. Рассмотренные варианты и trade-offs.474. Принятое решение и rationale.485. Последствия, риски и follow-up шаги.
Maslennikov-Anton