brainstorminglisted

# Brainstorming Classify a request before touching it, then gate implementation on that classification. `requirements-specification` turns an already-concrete ask into testable requirements; this skill runs *before* that — while the ask is still "build me X" or "can we..." and scope isn't pinned down yet. ## The gate <HARD-GATE> Do not write code, scaffold a project, or invoke an implementation skill until the request is classified, its path's design step is done, and — for Bounded and Architectural — the user has approved it. This holds for every path below; only the size of the design artifact changes, never whether approval is required. </HARD-GATE> The gate is one-way: if a task turns out bigger than its classification mid-work, stop and reclassify upward. Never reclassify downward to skip a step you've already started. ## Classify first State the classification out loud before asking anything else — "this reads as Bounded, so I'll sketch the design in chat rather than write a spec" — so the user can correct it immediately. - **Spike** — a feasibility question ("can we...", "is X possible...", "quick and dirty is fine"). The output is an answer, not code to keep. State the question and the 2-3 sentence probe plan, get a nod, then investigate as cheaply as correctness allows. No design doc. Report back as a recommendation; label anything you built as throwaway. - **Bounded** — a well-scoped change to a flow that already exists in this repo: a new flag, a s