problem-statement
/problem-statement
Define the framing. Change the statement, change the solution space.
A problem statement is not the problem — it's the lens. Different framings open different solution spaces. The right framing makes good solutions obvious; the wrong framing makes them invisible.
When to Use
- Starting new work — before solutions, articulate what you're solving
- Solutions feel off — proposed solutions seem convoluted or like workarounds
- Oscillating on approach — direction keeps changing; framing might be wrong
- Suspected X-Y problem — someone asks for a specific solution but underlying need is unclear
- Requirements expanding — scope creep signals framing mismatch
- After
/aimbut before/solution-space— aim defines outcome, problem statement frames challenge
Skip when: You have a crisp problem statement. Move to /solution-space.
The Framing Process
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.
82problem-space
Map what we're optimizing and what constraints we treat as real. Use before jumping to solutions, when hitting repeated blockers, or when patches keep accumulating.
80execute
Do the work. Pre-flight, build, detect drift, salvage if needed. Use when you have a clear aim and are ready to implement.
79solution-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