brainstorminglisted

# brainstorming — voidcorp craftsman edition Start by understanding the project context. Then ask questions one at a time to refine the idea. Once you understand what is being built, present the design in sections, get approval, write the spec to `docs/specs/`, and transition to `harness:writing-plans`. **No implementation skill, no code, no scaffolding until the spec is written and approved.** **Attribution**: see `.source`. Primary source: superpowers/brainstorming; the upstream idea-pressure-test mode is the distilled `gstack:/office-hours` diagnostic, vendored for void-harness. --- ## HARD GATE Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until: 1. The spec is written to `docs/specs/YYYY-MM-DD-<topic>.md` 2. The spec has passed self-review 3. The user has explicitly approved the written spec **This applies to EVERY project, regardless of perceived simplicity.** The anti-pattern is "this is too simple to need a design." Every project goes through this process. Simple projects' specs are short (a few sentences for truly trivial ones), but they MUST be written and approved. --- ## Ingesting a forge spec If `docs/specs/` holds a spec with `source: forge` in its frontmatter (the forge→harness artifact contract; see `docs/ARCHITECTURE.md` "Inter-plugin contracts"), the up-front thinking is already done. **Verify and fill the gaps — do not re-ask what the spec already answers.** The 18 recon variables