docs(skills): brainstorm-with-docs — шов self_review развязан двумя ярусами

Самопроверка уехала до записи и работает по плану артефакта (уровень
решений; может вернуть в интервью, пока файла нет) — сверено с апстримом
Мэтта: валидация до записи, запись линейна. После записи — дешёвое
перечитывание готового файла глазами читателя, правки по месту, решения
не переоткрываются. Критерий конца интервью оставлен мягким (решение
владельца, в Rejected), версионный хвост в шаблоне context.md вычищен.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Dmitry DementievandClaude Opus 5 committed 2026-08-01 18:59:42 +03:00
1 parent d10ad6981c
commit a95dc7988e
3 files changed
+58 -24

No files matched your search

@@ -133,19 +133,32 @@ the skill cold. Applied same day:
README Roadmap section reduced to a pointer at this file (it had become a
second source of truth).
## Pending decisions (2026-08-01 cold review, deferred by owner)
## Landed (2026-08-01, step 7 / self_review seam resolved)
- **Step 7 / self_review seam.** Review runs "before presenting" but after the
file is written; unclear what happens to the written artifact if review sends
the run back to the interview. Candidate fixes: review the draft before
writing, or state honestly "write → review → patch; if a gap opens, back to
the interview, then update the artifact".
- **Interview stop criterion.** "Clear enough to synthesize" is vague; candidate
hardening: problem, constraints, and success criteria named + no open forks
left.
- **Version notes in templates.** `artifacts/context.md` carries "(Multi-context
handling is deliberately light in v1.)" — development history in agent-facing
text; belongs here, not there.
The cold review caught that `<self_review>` ran "before presenting" but *after*
the file was written — order unstated, and a review verdict of "continue the
interview" left a half-baked artifact on disk with no instructions. Resolution,
shaped by three inputs:
- **Upstream comparison** (owner's call to check Matt Pocock's current skills):
Matt has no post-write review at all — `domain-modeling` writes glossary/ADRs
inline as terms resolve ("don't batch"; our gate exception for inline capture
independently converged on this), and `to-spec` synthesizes from the
conversation with its only checkpoint *before* the write. Pattern: validate
before writing; the write itself is linear.
- **Owner's size nuance:** artifacts can be large — a full draft pass through
the chat before writing would push the whole text through context twice. So
the pre-write review runs on the artifact *plan* (outline + key content
decisions); the checklist is decision-altitude anyway, only "unclear terms"
is wording-level.
- **Owner's experience:** a cheap re-read of the finished document by its own
author regularly finds real defects. Kept, as a second tier.
Landed shape — two tiers: `<self_review>` runs at step 6 on the plan (can send
the run back to the interview; no file exists yet), step 7 writes the file once
directly, then re-reads it end-to-end as a reader and fixes text-level defects
in place (does not reopen decisions). Unlike upstream, the review itself is
kept — `to-spec` has none; ours has content worth keeping.
## v2 — remaining
@@ -163,3 +176,10 @@ Kept from before:
- **F6 — "space-separated `allowed-tools` won't parse."** False. Claude Code docs
accept space- or comma-separated or YAML list; and `allowed-tools` is
pre-approval, not a restriction. No change needed.
- **Hard interview-stop checklist** (cold-review finding, 2026-08-01). Proposal:
replace "clear enough to synthesize" with a checkable triple (problem,
constraints, success criteria named + no open forks). Owner's call: keep it
soft — a hard checklist pushes the interview toward box-ticking. Consistent
with the R2 verdict from the first test (relentlessness left SOFT). The
version-note tail in `artifacts/context.md` from the same review was simply
cleaned.
@@ -214,8 +214,13 @@ the ADR's options considered).
## 6. Confirm direction
Before writing or changing durable project documents, confirm the direction.
Confirmation can be lightweight, e.g.:
Run `<self_review>` on the artifact plan — the outline and its key content
decisions — before proposing it: the checklist works at decision altitude, no
full draft needed. If it opens a gap, return to the interview while no file
exists yet.
Then confirm the direction before writing or changing durable project
documents. Confirmation can be lightweight, e.g.:
> "I recommend option B. I'd document it as a solution design, add one
> lightweight ADR for the storage-layout decision, and add two terms to
@@ -229,7 +234,8 @@ vocabulary.
Once the user agrees, create or update the artifact, following the format in the
matching `artifacts/*.md` file, sized by the minimum-sufficient rule from
`<core_rules>`.
`<core_rules>`. Write the file once, directly — the plan passed review at step
6, so no draft pass through the chat.
Where it goes: follow the repo's existing documentation layout if there is one.
Otherwise use the conventional homes — `CONTEXT.md` at the repo root, ADRs in
@@ -237,7 +243,13 @@ Otherwise use the conventional homes — `CONTEXT.md` at the repo root, ADRs in
`docs/runbooks/`). If the location isn't obvious, propose a path and confirm it
as part of step 6 rather than guessing. Create directories lazily.
Then go to `<self_review>` and `<stop_condition>`.
After writing, re-read the written file end-to-end as its reader, not its
author, and fix what you find in place — wording, structure drift, sections
that disagree with each other, template mismatches. This pass is cheap and
regularly catches real defects; it polishes text, it does not reopen decisions
(those passed `<self_review>` at step 6).
Then go to `<stop_condition>`.
</how_to_do_it>
@@ -259,14 +271,16 @@ runbook. If it's a validation rule for this work → the spec.
<self_review>
This is a review of the document itself — distinct from a spec's `## Validation`
section, which lists acceptance criteria for the implementation.
A review of the artifact *plan* — the outline and its key content decisions —
run at step 6, before any file is written, so a gap sends the run back to the
interview while nothing sits half-baked on disk. Distinct from a spec's
`## Validation` section, which lists acceptance criteria for the implementation.
Before presenting the final artifact, review it for: unclear terms, missing
constraints, hidden assumptions, contradictions with existing docs, unnecessary
scope expansion, premature implementation detail, missing validation criteria,
decisions that should (or should not) be ADRs, operational steps that should be a
runbook, and context that does (or does not) belong in `CONTEXT.md`.
Check the plan for: unclear terms, missing constraints, hidden assumptions,
contradictions with existing docs, unnecessary scope expansion, premature
implementation detail, missing validation criteria, decisions that should (or
should not) be ADRs, operational steps that should be a runbook, and context
that does (or does not) belong in `CONTEXT.md`.
If it's too large, propose splitting it. If it's too vague, continue the
interview.
@@ -6,7 +6,7 @@ devoid of implementation details, decisions, plans, or work logs.
A single `CONTEXT.md` lives at the repo root. If a `CONTEXT-MAP.md` exists at the
root, the repo has multiple contexts — read it to find which `CONTEXT.md` the
current topic belongs to. (Multi-context handling is deliberately light in v1.)
current topic belongs to.
Create the file lazily — only when the first term is actually worth recording.