problem-framing
Skill0 starsChanged 4 months agoMITView on GitHub
9-step systematic problem diagnosis. Define the problem before designing the solution. Uses root cause analysis, force field analysis, and structured evaluation. Adapted from BMAD Creative Intelligence Suite (Dr. Quinn). Activates on "diagnose this problem", "root cause", "why isn't this working", "what's really going on", "problem framing", "five whys", or "systems thinking."
9 other projects use a version of this.
Adopted by
Most recently taken up by
- Harrypatria/data-mining-mltheir own version, first seen Nov 1, 2026
- taichuy/1flowbasetheir own version, first seen Oct 23, 2026
- mariomile/builder-ostheir own version, first seen Oct 9, 2026
- Mozurok/fhorja.devtheir own version, first seen Oct 8, 2026
- jtsang4/efficient-codingtheir own version, first seen Sep 12, 2026
- Dyfree/problem-navigatortheir own version, first seen Sep 8, 2026
Other versions9 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 9
- taichuy/1flowbase★ 292same name
- Mozurok/fhorja.dev★ 10same name
- CN-WenYu/skills★ 3same name
- gmanch94/claude-code-aidlc-template★ 2same name
- Harrypatria/data-mining-ml★ 2same name
- jtsang4/efficient-coding★ 2same name
- mariomile/builder-os★ 2same name
- tommy-ngn/skills★ 2same name
- Dyfree/problem-navigator★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository15 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- ai-graduationSkill
- arbitrage-auditSkill
- assumption-mapperSkill
- b2b-idea-vettingSkill
- codifySkill
- decision-briefSkill
- design-thinking-liteSkill
- grill-meSkill
- grill-with-docsSkill
- innovation-diagnosticSkill
- kill-goSkill
- preflightSkill
- pull-frameworkSkill
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 7 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 19
Ask: "Describe the problem in one sentence.
- Distinctive: line 38
Use Five Whys. Ask "Why?" five times, drilling past symptoms to root causes.
- Distinctive: line 42
Stop when you reach something the user can change
- Distinctive: line 44
If "Why?" produces a shrug, that's an open question to investigate
“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
The 9 Steps
Walk through each step in order. Do not skip to solutions. The ur-problem is to define the problem.
Step 1: Define the Problem
Ask: "Describe the problem in one sentence. Who is affected, and what's the observable impact?"
Push back if the user names a solution disguised as a problem. "We need a dashboard" is a solution. "Regional managers can't compare quarterly performance without emailing the analytics team" is a problem.
Step 2: Is/Is Not Analysis
Narrow the scope. What IS the problem? What is it NOT?
| Dimension | IS | IS NOT |
| What | [specific symptoms] | [things that look similar but aren't this] |
| Where | [where it happens] | [where it doesn't happen] |
| When | [when it occurs] | [when it doesn't occur] |
| Who | [who's affected] | [who's not affected] |
The distinctions reveal the boundary conditions. Problems that happen everywhere are different from problems that happen in specific contexts.
Step 3: Diagnose Root Causes
Use Five Whys. Ask "Why?" five times, drilling past symptoms to root causes.
Rules:
- Each "Why?" must point to a cause, not a person
- Stop when you reach something the user can change
- Branch when there are multiple causes at any level
- If "Why?" produces a shrug, that's an open question to investigate
Step 4: Force Field Analysis
What forces push toward solving this problem? What forces resist?
| Driving Forces (push toward change) | Restraining Forces (resist change) |
| [list specific forces with strength 1-3] | [list specific forces with strength 1-3] |
The strategy isn't always to add more driving force. Sometimes reducing a restraining force is cheaper and more effective.
Step 5: Generate Solutions
Now — and only now — generate solutions. At least 3, max 7. For each:
- One sentence describing the solution
- Which root cause it addresses
- Estimated effort (hours/days/weeks)
- Key risk
Include at least one "do nothing" option with explicit consequences.
Step 6: Evaluate Against Criteria
Define 3-5 evaluation criteria BEFORE scoring. Common ones:
- Impact on root cause (not symptoms)
- Feasibility with available resources
- Time to first result
- Reversibility (can you undo it if wrong?)
Score each solution 1-5 on each criterion. Present as a decision matrix.
Step 7: Recommend
Pick the highest-scoring solution. Explain why in 2-3 sentences. Name what would change your recommendation.
Step 8: Define Success Metrics
How will you know the problem is actually solved (not just addressed)?
- Leading indicator: what changes first?
- Lagging indicator: what confirms the problem is gone?
- Timeline: when should you see each indicator?
Step 9: Identify What Could Go Wrong
Pre-mortem: "This solution failed. What happened?"
Name 2-3 failure modes and a mitigation for each. If a failure mode has no mitigation, flag it as an accepted risk.
Output
# Problem Diagnosis: [Problem Name]
Date: [date]
## Problem Statement
[One sentence from Step 1]
## Is/Is Not
[Table from Step 2]
## Root Causes
[Five Whys chain from Step 3]
## Force Field
[Table from Step 4]
## Solutions Considered
[Numbered list with effort/risk from Step 5]
## Decision Matrix
[Scoring table from Step 6]
## Recommendation
[From Step 7]
## Success Metrics
[From Step 8]
## Risks & Mitigations
[From Step 9]Adapted from BMAD Creative Intelligence Suite problem-solving workflow (Dr. Quinn).
Next step
Diagnosis done → run assumption-mapper to extract what you're betting on, or grill-me to pressure-test the chosen solution.
Part of the ThinkHaven Method Kit by Kevin Holland. Full Board of Directors experience: ThinkHaven
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

