Files
dotfiles/agents/.agents/skills/brainstorm-with-docs/artifacts/spec.md
T
Dmitry DementievandClaude Opus 4.8 6f9de57b0c refactor(brainstorm-with-docs): понимание ведёт, артефакт — запись
- Зачем:
  - гравитация скилла тянула к «выдать артефакт»; управляющие документы
    раздувались деталями реализации (диагностировано на живом тесте — ADR
    с инлайном SQL).
- Что:
  - gate/stop: «готово» = общее понимание + рекомендованное направление,
    записанное минимально-достаточно, а не «артефакт произведён»; определение
    в одном месте (stop_condition), gate на него ссылается.
  - core_rules: минимально-достаточный артефакт + барьер высоты (без инлайна
    исполняемых артефактов) + single source of truth; приоритет над
    конвенциями репозитория.
  - шаг 2: артефакт(ы) выбираются ПОСЛЕ понимания, набором по жанрам.
  - adr.md/spec.md: Lifetime test → Scope test (ADR↔spec по охвату, не сроку);
    detailed plan — transient и вне scope скилла.
  - description + README: формулировки-цели ведут пониманием, не артефактом.
- Проверка:
  - grep: старый framing (lifetime/transient) убран; cross-ref Scope test
    сходится; определение «готово» не дублируется; витрина не artifact-first.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-08 18:56:30 +03:00

67 lines
1.9 KiB
Markdown

# Solution Design / Spec
Use for engineering, architecture, DevOps, integration, migration, or any
non-product feature work where a direction has been chosen but not yet built.
Use the minimum-sufficient version: the smallest form that fully preserves the
understanding, and no smaller. Drop sections that add nothing for this particular
problem — an empty section is noise.
## Template
```markdown
# Title
## Problem
## Context
## Goals
## Non-goals
## Current state
## Options considered
## Recommended approach
## Rationale
## Decisions and rejected alternatives
## Risks and mitigations
## Validation
## Documentation impact
## Open questions
```
## Notes on key sections
**Options considered vs Decisions.** Keep these two sections doing different jobs
so the rejected options aren't written twice. *Options considered* is the
landscape *before* the choice — the candidates and their trade-offs as they
stood. *Decisions and rejected alternatives* is the outcome *after* the choice —
what was picked and why each alternative was rejected. Frame in the first, judge
in the second.
**Decisions and rejected alternatives** is the highest-value section. Capture:
- accepted decisions and the reason behind each
- rejected alternatives and *why* they were rejected
- subtle constraints and important defaults
- sequencing decisions
- assumptions future agents must not silently re-derive
Do not turn this section into an ADR dump. Keep decisions that are local to this
work here; promote a decision to its own ADR (`artifacts/adr.md`) only when it is
durable, surprising, the result of a real trade-off, and matters beyond the scope
of this work — cross-cutting, relevant to readers elsewhere (see the scope test
in `artifacts/adr.md`).
**Validation** describes how we will know the implementation is correct — tests,
checks, acceptance criteria. It belongs here, not in `CONTEXT.md`.