---
name: decision-log
description: Records business and personal decisions in ADR (Architecture Decision Record) format adapted for non-tech use — number/title/date/status/context/alternatives/decision/rationale/expected outcome (1/3/6 months)/assumptions/check metric, plus a 30-day retrospective. This skill should be used whenever the user makes or describes a decision that should be remembered, OR whenever the user asks "почему я так решил", "какое решение я принял по X", "decision log", "ADR", "зафиксируй решение", "запиши, что мы решили", "что я выбрал между". Maintains decisions/ folder with INDEX.md. Decisions are immutable once Accepted — changes go as new decisions referencing previous ones.
---

# decision-log

Фиксация бизнес- и личных решений в формате ADR с retrospective через месяц.

Источники: claude-plugins.dev/@sethdford/adr-writer, github.com/joelparkerhenderson/architecture-decision-record (Joel Parker Henderson — каноничный репо, источник Nygard format и MADR), martinfowler.com/bliki/ArchitectureDecisionRecord.html.

Термин «ADR» ввёл Michael Nygard в 2011 в статье «Documenting Architecture Decisions» — для tech-решений. В этом скилле адаптировано для бизнес-решений (наём, ценообразование, выход на рынок, отказ от клиента, изменение позиционирования).

## Шаг 0: загрузить контекст

- about-me
- Если есть `decisions/INDEX.md` — прочитать предыдущие решения, чтобы избежать дублей и противоречий
- Если есть последний `decisions/[N]-[название].md` — посмотреть, не противоречит ли новое
- Если есть `~/.claude/skills/decision-log/references/criteria.md` — учесть критерии при анализе альтернатив

## Smart-onboarding: критерии решений

Если `criteria.md` отсутствует, и это первый ADR пользователя — спроси ПОСЛЕ записи первого решения (не блокируем):

```
Зафиксировал твой первый ADR. Если хочешь, чтобы следующие решения
оценивались по твоим личным критериям (например: «маржа ≥ 30% и срок
≤ 3 мес» — твои персональные «да/нет») — 4 минуты на заполнение
criteria.md. Это окупится со второго решения.

Заполняем сейчас или потом?
```

- «Сейчас» → 4 вопроса из `templates/11-decision-criteria.md`.
- «Потом» → ставим напоминание в первый weekly-review.

## Шаг 1: запуск

Решение фиксируется когда:
- Пользователь явно говорит «зафиксируй, что я решил X»
- В weekly-review #7 — назвал решение для формализации
- В sales-script / negotiation — пришли к точке, требующей фиксации
- В разговоре прозвучало: «всё, тогда делаем X», «значит, выбираем Y», «решено — Z»

Если контекст неясен — спросить одной фразой: «зафиксировать как ADR? название одной строкой?»

## Шаг 2: 7 вопросов (если контекста мало)

Если решение в чате не раскрыто — задать одним блоком:

```
1. Заголовок (1 строка): что именно решили?
2. Контекст: что происходило, почему пришлось решать?
3. Альтернативы: какие варианты рассматривал?
4. Принятое решение: что выбрал и почему именно это?
5. Ожидаемый результат через 1, 3, 6 месяцев — что должно произойти?
6. Какие предположения должны быть верны, чтобы решение сработало?
7. Метрика проверки: как поймёшь, сработало или нет?
```

## Шаг 3: формат записи

```markdown
# [N]. [Заголовок одной строкой]

**Дата**: 2026-05-10
**Статус**: Accepted
**Авторы**: [Имя]

## Контекст
[Что происходило, почему нужно было решать. 2–4 строки. Без воды.]

## Альтернативы
1. **[Вариант A]** — плюсы: ...; минусы: ...; почему отклонил: ...
2. **[Вариант B]** — плюсы: ...; минусы: ...; почему отклонил: ...
3. **[Принятое решение]** — плюсы: ...; минусы: ...; почему выбрал: ...

## Решение
[Конкретно, что решили. Одна-две строки.]

## Обоснование
[Почему именно это, а не альтернативы. 2–4 пункта.]

## Ожидаемый результат
- Через 1 месяц: [метрика, число, состояние]
- Через 3 месяца: ...
- Через 6 месяцев: ...

## Предположения
- Должно быть верно: [что]
- Должно быть верно: [что]

## Метрика проверки
[Как поймёшь, сработало или нет. Конкретно.]

## Связанные решения
- См. [#N — заголовок предыдущего решения по этой теме]

## Retrospective (заполнится через 30 дней)
> Оставлено пусто. Через месяц — сравнить ожидаемое с фактом.

### Что сделал бы иначе
> Заполняется ретроспективно.
```

## Шаг 4: status lifecycle

| Status | Когда |
|---|---|
| **Proposed** | Идея, ещё не принята |
| **Accepted** | Принято, исполняется |
| **Deprecated** | Больше не действует, но не отменено новым решением |
| **Superseded by [#N]** | Отменено решением #N (ссылка обязательна) |

**Иммутабельность**: принятое решение НЕ редактируется. Если меняем — пишем новый ADR, в нём ссылка «supersedes [#N]», в старом — статус «Superseded by [#NEW]».

Это критично — иначе через год не понять, почему так решили, потому что текст редактировался.

## Шаг 5: индекс

После записи обновить `decisions/INDEX.md`:

```markdown
# Decisions Index

| # | Дата | Заголовок | Статус |
|---|---|---|---|
| 0001 | 2026-01-15 | Перейти на Tilda для лендингов | Accepted |
| 0002 | 2026-02-03 | Закрыть направление консалтинга для SMB | Superseded by #0007 |
| 0007 | 2026-05-10 | Возобновить SMB-консалтинг с фокусом на e-com | Accepted |
```

## Шаг 6: retrospective через 30 дней

Через месяц после Accepted — пользователь должен запустить ретроспективу:
- Сравнить «Ожидаемый результат через 1 месяц» с фактом.
- Записать «Что сделал бы иначе».
- Если результат сильно расходится — рассмотреть новый ADR (Superseded by).

Скилл может в начале новой сессии напомнить: «прошло 30 дней с ADR #N, готов сделать retrospective?»

## Anti-patterns

- Не редактировать Accepted ADR — только новый со ссылкой.
- Не писать ADR для каждого мелкого решения — только для тех, которые через 3 месяца захочешь вспомнить «почему».
- Не использовать generic заголовки («Стратегическое решение», «Изменение подхода»). Конкретно: «Перенос воронки с TG на email».
- Не пропускать «Метрика проверки» — без неё ADR через 3 месяца бесполезен.

## RU-специфика

- Дата: ISO + ДД.ММ.
- Связанные решения — ссылки внутрепапки `decisions/`, не внешние URL.
- Имена авторов в команде — только имя или имя+роль, без отчества (если только не корпоративная культура с отчествами).
- Если решение касается денег — указать в ₽, не в условных.

## Reference

- `references/adr-template.md` — пустой шаблон ADR для копирования.

## Smart-onboarding (при первом запуске)

Перед первым ADR проверь:

1. `~/.claude/skills/decision-log/references/criteria.md` — есть личные критерии «да/нет»?
   - **Нет** → один вопрос: «Хочешь зафиксировать свои критерии решений (4 вопроса, 5 минут)? Это сделает ADR быстрее и последовательнее.» Если «не сейчас» — продолжаем без них.

2. Не спрашивай дважды в одной сессии.
