Brainstorm

Goal

Turn a raw idea into a high-level design brief — the problem, the chosen approach, the major pieces and how they relate, and the decisions that change everything downstream, all at design altitude. It's the input to crank:crank-spec, which turns the brief into a full spec.

Hard Rules

• Stay at design altitude. Settle what you're building and which shape it takes — not exact signatures, schemas, field names, or file-by-file breakdowns. Drill into a detail only when it's load-bearing for a key decision (if approach A vs. B hinges on whether the database supports X, resolve X; otherwise leave it for the spec). When you catch yourself specifying something an implementer would type, you've dropped below altitude — pull back up.
• Write the brief to a fresh OS temp file: $(mktemp -t crank-brainstorm).md. Do not write into the working directory unless the user explicitly asks. Tell the user the path once.
• Every subagent this skill spawns runs at the standard tier (see References → Subagents) unless otherwise specified.

Guidelines

Design for isolation. Describe each piece of the Shape as a module with one clear purpose and a clean boundary — you should be able to say what it does, how you'd use it, and what it depends on without reading its internals. If you can't, the boundaries need another pass. (You're naming the boundaries here, not designing the interfaces across them — that's the spec's job.)

Working in an existing codebase. Let the structure you explored shape the brief: follow the established patterns rather than inventing parallel ones. Where existing code genuinely gets in the way of the idea (a file that's grown too large, a tangled responsibility the work has to touch), fold a targeted improvement into the Approach — the way a good engineer improves code they're working in. Don't propose unrelated refactoring; stay on what serves the idea.

References