docs(skills): brainstorm-with-docs — дивергенция v2: веер, развилки, маршрутизация

Приземлён блок дивергенции из ROADMAP по итогам второго живого теста
(wayfinder-карта #26 стенда): шаг 5 разделён на веер и конвергенцию,
ширина веера — по весу решения, развилки решаются по месту в интервью.
Триггер «развилка» в description; описание и правила подрезаны по ревью
writing-great-skills. Свидетельства и доводы — в ROADMAP.md.

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

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

@@ -1,6 +1,6 @@
 ---
 name: brainstorm-with-docs
-description: Structured brainstorming and design alignment for unclear technical problems, grounded in the project's existing docs and vocabulary — questioning assumptions, sharpening terminology, comparing options, and reaching shared understanding and a recommended direction. Use when exploring an ambiguous engineering, DevOps, architecture, migration, integration, research, or documentation problem; the understanding is the deliverable, recorded in the smallest durable artifact (spec, ADR, runbook, research note, or CONTEXT.md glossary update). Not for implementation, trivial fixes, or executing an already-approved plan.
+description: Brainstorm and align on a design, grounded in the project's existing docs and vocabulary. Use when exploring an ambiguous problem — whatever the domain — or when grilling a decision fork (развилка): a fan of options, then convergence. The understanding is the deliverable, recorded in the smallest durable artifact (spec, ADR, runbook, research note, CONTEXT.md). Not for implementation, trivial fixes, or executing an already-approved plan.
 argument-hint: "[problem-or-topic]"
 allowed-tools: Read Grep Glob Write Edit WebSearch WebFetch Bash(git log:*) Bash(git diff:*) Bash(git status:*) Bash(git show:*)
 ---
@@ -41,12 +41,10 @@ not.
 
 Use this skill for:
 
-* ambiguous engineering tasks
-* architecture or design decisions
-* DevOps and infrastructure work
-* research-heavy technical tasks
-* migration, integration, or operational-procedure design
-* choosing between implementation approaches
+* ambiguous problems with an unclear direction — the shape is the trigger,
+  not the domain
+* choosing between approaches or grilling a decision fork: one decision at a
+  time, a fan of options before converging
 * converting a discussion into a durable specification
 * clarifying project terminology and assumptions
 
@@ -69,11 +67,9 @@ If invoked with arguments, treat `$ARGUMENTS` as the initial problem statement.
 * Surface assumptions, constraints, risks, trade-offs, and non-goals.
 * Don't interview forever — when the problem, constraints, and success criteria
   are clear enough, stop asking and synthesize.
-* Offer 2-3 viable approaches within the user's framing, plus at least one (more
-  if useful) that challenges the framing itself — the null option, a reframe, an
-  adjacent-domain steal. Without the framing-challenger, options collapse into
-  variations of one idea. Don't pad to hit a number; every option must be
-  genuinely distinct.
+* Generate the full fan of options before judging any of it — options of
+  genuinely different kinds, not variations of one idea. Composition and width
+  of the fan live in step 5.
 * Be direct. Give a real recommendation; don't hide behind "it depends" when the
   context supports a call.
 * Explicitly state what should NOT be done now.
@@ -99,7 +95,7 @@ If invoked with arguments, treat `$ARGUMENTS` as the initial problem statement.
 
 Before asking the user anything, read the relevant context. Prefer this order:
 
-1. `AGENTS.md` or an equivalent project map
+1. `AGENTS.md` or an equivalent project map, plus `docs/agents/*.md` if present
 2. README / project overview
 3. `docs/`, then existing specs and design docs
 4. ADRs (`docs/adr/`), runbooks, status docs
@@ -171,18 +167,50 @@ risk), using the format in [artifacts/context.md](artifacts/context.md) — don'
 batch them. Redefining an already-documented term is a vocabulary change: propose
 it inline, but confirm before writing (see step 6).
 
-## 5. Synthesize options
+When the interview hits a genuine decision fork — a choice that shapes what
+comes after — resolve it in place rather than deferring it to the end: run a
+divergence pass on that fork (see step 5), sized to its weight, and wait for the
+user's reaction before moving on. Invite reactions to the options you'd reject,
+not just to the favourite: what the user says about a rejected option often
+sharpens what they actually want.
 
-<!-- SEAM: a full divergence phase belongs before this convergence step (v2).
-     Rationale, toolkit, and status live in ROADMAP.md — not here, so a running
-     agent isn't primed with the design intent. -->
+## 5. Diverge, then converge
 
-Present 2-3 viable approaches within the user's framing, plus at least one that
-challenges it. For each: short description, when it fits, benefits, trade-offs,
-risks, operational implications, documentation impact, and what it avoids or
-postpones. Then recommend one, explaining why it fits the
+Two passes, kept separate: first generate options without judging them, then
+evaluate. Mixing generation and evaluation censors unusual options before
+they're voiced.
+
+**Diverge.** Restate the user's implicit frame in one sentence — the assumption
+their question stands on. Then lay out the fan:
+
+* 2-3 genuinely distinct approaches within the frame;
+* at least one option that rejects the frame itself;
+* the null option — what happens if this isn't done at all.
+
+Size the fan to the decision's weight. For a cheap, reversible choice the list
+above is enough; for a hard-to-reverse or expensive-to-unwind one, widen it with
+the toolkit — each technique carries its trigger:
+
+* *axis of variation* — options all sit on one axis? Name the axis, add an
+  option from a different one.
+* *archetype stances* — fan feels timid or samey? Force an MVP, a robust, and a
+  radical option.
+* *inversion* — one obvious approach dominates? Add its opposite.
+* *steal from an adjacent domain* — problem feels novel? Ask how another field
+  solves it.
+* *pre-mortem* — stakes are high? Assume the favourite failed in six months;
+  add the option you'd wish you'd considered.
+
+Before presenting, self-check: are these different *kinds* of answer, or
+variations of one? If variations, generate one more from a different axis.
+
+**Converge.** For each option: short description, when it fits, benefits,
+trade-offs, risks, operational implications, documentation impact, and what it
+avoids or postpones. Then recommend one, explaining why it fits the
 constraints, what risks remain, what to validate first, and what to explicitly
-not do now.
+not do now. When the fork is resolved, carry the rejected options and the
+reasons for rejecting them into the resolution record (the spec's alternatives,
+the ADR's options considered).
 
 ## 6. Confirm direction