القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Clarify the outcome you want - a change in user behavior, not a feature shipped. Use at the start of any work to ground the session in strategic intent.
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 people are converging too quickly.
Human-led curation of accumulated metis and guardrails. Surface patterns across sessions, propose what to promote, compact, or dismiss. Use after multiple sessions, before a new phase, or when search results feel noisy.
Do the work. Pre-flight, build, detect drift, salvage if needed. Use when you have a clear aim and are ready to implement.
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.
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.
| name | problem-statement |
| description | 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. |
Define the framing. Change the statement, change the solution space.
A problem statement is a lens, not reality. The goal is a plausible, coherent story that enables action and names what would make it wrong — not an exhaustive account.
Skip when: You already have a crisp problem statement. Move to /solution-space.
Load references/framing.md only when the request may be X-Y shaped, examples would help, or the frame is becoming too detailed.
"The problem is currently framed as: [how it's being described]."
Capture only what changes the next move: stated problem, embedded assumptions, fixed vs. flexible constraints, and the simplest story that would make action sensible.
A good problem statement says what must change, not how to change it.
Test:
Name hard constraints, soft constraints, and assumptions. Question soft/assumed constraints; do not negotiate hard ones away.
Use this shape:
[Who] needs [what outcome] because [why it matters], but currently [what's blocking].
Good statements are crisp, outcome-focused, testable, solution-agnostic, and plausible enough to guide the next move.
Ask:
## Problem Statement
**Current framing:** [How the problem is currently being described]
**Reframed as:** [Your crisp problem statement]
**The shift:** [What changed in how we see it]
### Working Story
[The plausible story that makes this problem worth acting on now — concise, not exhaustive]
### Constraints
- **Hard:** [Actually immovable constraints]
- **Soft/assumed:** [Constraints that may be flexible]
### Assumptions Being Tested
- [assumption embedded in this framing]
### Frame Pressure Test
- Reveals/enables: [what this framing makes visible or easier]
- Hides/risks: [what this framing may obscure]
- Plausible alternate: [one alternate story that would change the solution space]
- Who disagrees: [stakeholder/role and the alternate story they would tell]
### Signal This Framing Is Wrong
[What evidence would show this frame is misleading or only a symptom]
If a session file is in use, read prior Aim / Problem Space, then replace or append ## Problem Statement. Later phases carry forward the working story, constraints, assumptions, and invalidation signal.