Problem Solving — Brainstorm → Decide → Plan → Review

For problems where the approach is the hard part. The output is a decision the user owns, a short solution doc, and a reviewed build plan. Part of the dev-* development-cycle skill set (see dev-cycle).

Downgrade to dev-feature if, after Phase 1, only one sensible approach exists — say so in one line and switch. Don't manufacture alternatives for a solved problem.

Phase 1 — Understand and Collect Data

1. Restate the problem in one paragraph: current behavior, desired behavior, constraints (perf, compat, deadline, team preferences). Confirm you got it right.
2. If the user brought their own ideas, treat them as first-class candidates — they enter Phase 2 alongside yours, evaluated by the same criteria, listed first.
3. Gather evidence before opinions:
   • Codebase: how the affected area works today, existing patterns/utilities that constrain or help
   • Configured memory/knowledge store (see dev-knowledge): retrieve only relevant prior decisions; do not create or read a parallel store by default.
   • Externals when relevant: library options and their maintenance state, prior art, known pitfalls (web search)
4. Ask the questions that change the answer — requirements you can't infer, tolerance for new dependencies, operational constraints. Two rules: facts are looked up, decisions are asked — if the codebase or docs can answer it, grep instead of asking; and every question ships with a recommended answer so the user can just say "yes" or push back on something concrete. Batch the questions; don't drip-feed.
5. Map the decision tree before asking. List every decision the problem implies (architecture, data model, edge cases, ops) and order questions so earlier answers constrain later ones. A question whose relevance depends on another answer waits for the next batch — never ask both in one batch and never discover the decision mid-implementation.

Phase 1b — Experiments (spikes)