Skip to content

brainstorming: modernize the spec-refinement skill for capable models — implemented slice + deferred proposals #597

Description

@SUaDtL

The brainstorming skill predated several standing directives and read as written for a weaker model: strictly one question per round, no recommendation at forks, no approach exploration, no decomposition check, and a spec that got LESS review than any line of code that implements it. An external prior-art survey (2026-08-04, mechanics-reference only) plus this repo's own steers (decide parameters / ask forks in full; adversarial pass before hand-off; stopping rules for non-converging loops) shaped a redesign.

Implemented (PR follows)

  1. Phase 1 gains a split-before-you-spend check - an idea bundling independently shippable concerns is decomposed BEFORE question budget is spent; each piece is its own spec.
  2. New Phase 2 "Shape the approach" - genuine candidate approaches with trade-offs and exactly one recommendation; an explicit no-manufactured-alternatives rule; isolation + YAGNI lenses applied while the design is still soft.
  3. Question discipline rewritten to decide-or-ask - parameter-level choices are decided and recorded in the spec (a "Decided parameters" section the user reads at approval); genuine forks are asked IN FULL the first time, recommendation first, batched when independent. Replaces the one-question-per-round mandate.
  4. Closure is a checklist, not a feeling - a rationalization guard naming the specific self-justifications for stopping early ("simple enough", "asked enough", "user seems eager", "settle it during implementation"), each with its rebuttal, at the exact point the model decides it understands.
  5. Loop breaker - a contradiction or a resurfacing fork STOPs the loop and forces one adjudication rather than circling.
  6. Phase 5 review upgrade - mechanical self-review of the file as written (placeholder scan, internal consistency, boundary check, per-criterion testability, vague-language on its own prose) plus an adversarial pass whose surviving findings are PRESENTED WITH the spec: the user approves a challenged design, not a defended one.

INDEX.md row and the curated site page updated to match; description frontmatter now reads five phases.

Deferred - needs a ruling (the [decision] label is for these)

  • D1: fresh-context spec reviewer. The adversarial pass is same-agent. The stronger form dispatches a fresh reviewer agent against the written spec (never grade your own homework), the way code already gets reviewed here. Costs a subagent per feature spec and either a new agent definition or reuse of decision-challenger pointed at specs. Worth it for /sprint autonomy; possibly overkill for attended /feature runs.
  • D2: structured phase-status vocabulary. Phase gates currently close in prose. A compact status contract (e.g. FRAMED / SHAPED / REFINED / WRITTEN / APPROVED-or-BLOCKED) would let /sprint branch on state rather than parse text. Touches sprint + executing-plans integration, so it is a cross-skill change, not a brainstorming edit.
  • D3: skill-authoring as a tested artifact. The strongest external pattern observed: before shipping a skill revision, run a baseline session WITHOUT it, record the model's actual failure modes and rationalizations, write the skill against those, re-run to confirm. This repo already does the blind-exercise version of this for release; extending it to skill authoring generally overlaps issue Investigate: STE-inspired controlled authoring standard for skill normative text #591 (STE-inspired controlled authoring) and the skill-author skill's Phase 4 self-review.
  • D4: question-budget telemetry. No numeric budget was added (a fixed cap invites gaming; the breaker + checklist govern instead). If /ca:metrics ever grows a brainstorming lens, rounds-per-spec would be the honest signal to watch.

Transferable beyond brainstorming (no action here, recorded so they are not lost)

Metadata

Metadata

Assignees

No one assigned

    Labels

    decisionNeeds a user decision / ADR (not a straight fix)enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions