/problem-space

Map the terrain where solutions live. What are we optimizing? What constraints do we treat as real? Which constraints can be questioned?

Problem space exploration precedes solution space. Understanding the terrain is the work. Jump to code too early and you'll build the wrong thing fast.

When to Use

Invoke /problem-space when:

• Starting new work - Before jumping to implementation, understand what you're actually solving
• Hitting repeated blockers - The same problems keep appearing in different forms
• Patches accumulating - Third config flag for the same bug signals you're treating symptoms
• Estimates feel off - When time estimates are wrong by an order of magnitude, the problem isn't understood
• Agent is talking itself out of constraints - "For this prototype we don't have time" when the constraint matters

Do not use when: The problem is well-understood and you're already in execution. Problem space is for grounding, not for stalling.

The Problem Space Process