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

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

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

agents/.agents/skills/brainstorm-with-docs/SKILL.md

@@ -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.