problem-space
/problem-space
Map the terrain where solutions live. What are we optimizing? What constraints are real? Which can be questioned?
Problem space precedes solution space. Jump to code too early and you build the wrong thing fast.
When to Use
- Starting new work — before implementation, understand what you're solving
- Hitting repeated blockers — same problems in different forms
- Patches accumulating — third config flag for the same bug means you're treating symptoms
- Estimates off by 10× — the problem isn't understood
- Agent talking itself out of constraints — "for this prototype we don't have time" when the constraint matters
Skip when: Problem is well-understood and you're in execution. Problem space is for grounding, not stalling.
The Problem Space Process
Step 1: State the Objective Function
More from open-horizon-labs/skills
dissent
Devil's advocate. Seek contrary evidence before locking in. Use when about to make a significant decision, when confidence is high but stakes are higher, or when the team is converging too quickly.
89review
Check work and detect drift before committing. A second opinion that catches misalignment early. Use at natural pause points, before PRs, or when something feels off.
82ship
Deliver code to users. Optimize the path from merged code to working install. Use when execution is complete and you need to get changes into users' hands.
82execute
Do the work. Pre-flight, build, detect drift, salvage if needed. Use when you have a clear aim and are ready to implement.
79problem-statement
Define the framing of a problem. Change the statement, change the solution space. Use when starting work, when solutions feel wrong, or when you suspect an X-Y problem.
78solution-space
Explore candidate solutions before committing. Use when you have a problem statement and need to evaluate approaches - band-aid, optimize, reframe, or redesign.
76