Problem Framing
Turn an ambiguous request into a bounded problem statement before choosing an implementation.
Workflow
- Identify the affected users, operators, or systems and the outcome each needs.
- Record current evidence separately from assumptions, reports, and preferences.
- Describe the current state, triggering condition, impact, and why action is warranted now.
- List constraints, authority boundaries, dependencies, and decisions already ratified.
- Name material unknowns and the cheapest evidence that would resolve each one.
- Compare at least two plausible response options, including leaving the system unchanged when credible.
- Define success criteria, failure signals, exclusions, and stopping conditions.
- Recommend whether to research, diagnose, plan, prototype, implement, or defer next.
Boundaries
- Do not treat a requested solution as proof of the underlying problem.
- Do not invent users, requirements, metrics, or authority.
- Do not begin implementation unless the request also authorizes it and the problem is sufficiently bounded.
- Escalate choices that would materially change scope, risk, cost, or ownership.
Output
Return Problem, Affected parties, Evidence, Constraints, Unknowns, Options, Success criteria, Non-goals, and Recommended next step. Mark each statement as observed, reported, assumed, proposed, or ratified when the distinction matters.
1---2name: problem-framing-23description: Frame a proposed feature, defect, workflow, or system change before implementation by identifying users, outcomes, evidence, constraints, unknowns, options, and measurable success. Use when a request is important but the problem or desired result is not yet decision-ready.4license: MIT5---67# Problem Framing89Turn an ambiguous request into a bounded problem statement before choosing an implementation.1011## Workflow12131. Identify the affected users, operators, or systems and the outcome each needs.142. Record current evidence separately from assumptions, reports, and preferences.153. Describe the current state, triggering condition, impact, and why action is warranted now.164. List constraints, authority boundaries, dependencies, and decisions already ratified.175. Name material unknowns and the cheapest evidence that would resolve each one.186. Compare at least two plausible response options, including leaving the system unchanged when credible.197. Define success criteria, failure signals, exclusions, and stopping conditions.208. Recommend whether to research, diagnose, plan, prototype, implement, or defer next.2122## Boundaries2324- Do not treat a requested solution as proof of the underlying problem.25- Do not invent users, requirements, metrics, or authority.26- Do not begin implementation unless the request also authorizes it and the problem is sufficiently bounded.27- Escalate choices that would materially change scope, risk, cost, or ownership.2829## Output3031Return `Problem`, `Affected parties`, `Evidence`, `Constraints`, `Unknowns`, `Options`, `Success criteria`, `Non-goals`, and `Recommended next step`. Mark each statement as observed, reported, assumed, proposed, or ratified when the distinction matters.
JovaniPink