forge-brainstorm

Forge playbook — Structured ideation (brainstorm before build)

Do not duplicate ECC skills — defer to: brainstorming (the deep design-dialogue methodology). This file is the Forge-specific orchestration wrapper: a compact diverge → converge loop sized for a /forge work package rather than a full standalone design doc.

Hard rules

• No implementation before a written pick + rationale. Even a "simple" task benefits from naming the 2-3 real alternatives and why one was chosen — unexamined assumptions on "simple" work cause the most rework.
• If the request is genuinely ambiguous in a way that changes the answer, ask 1-3 targeted questions before diverging; otherwise pick the sensible default, state it, and proceed — never silently guess on something consequential.
• Constraints are gathered from real project evidence (existing architecture, stack, CLAUDE.md, FORGE_PROJECT_PROFILE.md) — not invented defaults that ignore the actual codebase.
• Do not over-invest: this is a short loop, not a multi-day design-doc process. Match the depth to the task's real complexity/risk (see the fan-out table in CLAUDE.md).

The loop (diverge → constraints → converge → smallest viable first)

1. Diverge. List 2-4 genuinely different approaches (not trivial variations of the same one). For each: what it is, why it could work, and its real cost/risk.
2. Constraints. Apply what actually limits the choice here: existing architecture/conventions, stack, team size/skills available, time/complexity budget (fan-out level), security/compliance posture, anything the owner already ruled out.
3. Converge. Pick one approach and give the rationale in 1-3 sentences — why this one beats the alternatives for this project, not in the abstract. Name what was explicitly rejected and why.
4. Smallest viable first. Scope the smallest slice that proves the approach works end-to-end before building the full version — the first work package should be small enough to verify quickly, not the whole feature at once.