assessing-brainstorms

Assessing brainstorms

Decide whether a brainstorm becomes one spec or a roadmap of several, then hand off to the matching skill. The verb is assess because the work is the assessment — single shippable unit, or multiple? — not a git fork-style copy.

The decision

Signal	Spec	Roadmap
Single coherent feature with one clear shipping definition	✓
Two or more independent shippable units that share a thesis		✓
Decision table fits in one screen, open threads < 5	✓
Brainstorm body > ~300 lines or multiple §2 decision tables		✓
The user already used the word "arc," "phases," or "tracks"		✓

If two or more roadmap signals fire, recommend roadmap. Otherwise recommend spec. Lead with the recommendation; let the user override.

Process

1. Read the brainstorm. Frontmatter, §2 decision table, open threads, next steps. Confirm it's complete (no TBDs in §2, open threads triaged into "blocking" vs "shape-only").

2. State the call. "Reading this as a [spec | roadmap] because [signals]. Disagree?" Wait for confirmation.

3. Invoke the verb:

   node greymatter/scripts/dev-pipeline.js assess <brainstorm-path> --to spec|roadmap
   

   The verb copies the canonical templates next to the brainstorm and patches frontmatter with the brainstorm topic. (Brainstorms are scaffolded by dev-pipeline.js init as brainstorm.md — no temp. rename needed.)

4. Hand off:

   • Spec path: invoke writing-specs. Tell it the brainstorm path. Stop.
   • Roadmap path: invoke writing-roadmaps. Tell it the brainstorm path. Stop.

You do not draft the spec or roadmap yourself. This skill ends at the handoff.

Anti-patterns

• Assessing a half-baked brainstorm. If §2 still has TBDs, send the user back to brainstorming to close them. Assessing prematurely surfaces churn downstream.
• Splitting a single coherent feature into a roadmap "for completeness." Roadmaps exist when the units ship independently. Cosmetic decomposition is overhead.
• Drafting the spec inline. Hand off. The next skill owns the body.