From PRD-Driven Context Engineering
Transforms vague product ideas into evidence-anchored problem statements for PRD v0.1 Spark. Outputs structured problem tables with CFD evidence IDs.
How this skill is triggered — by the user, by Claude, or both
Slash command
/prd-ce:prd-v01-problem-framingThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Transform market signals into evidence-anchored problem statements.
Transform market signals into evidence-anchored problem statements.
This skill assumes you have zero prior research. It is the starting point.
This skill creates/updates:
All CFD- entries should include:
confidence: 1-3/5 (pre-product research, no usage data)Populate this table for every problem statement:
| Element | Definition | Evidence |
|---|---|---|
| Who is hurting? | Specific, findable, countable persona | Segment size |
| What pain exists? | Observable behavior or workflow friction | CFD-ID |
| Cost of problem | Time, money, or opportunity lost | Quantified |
| Why now? | Market trigger creating urgency | Trend/event |
| What's impossible? | Opportunity cost—what can't they do | User quote |
See assets/problem-statement.md for copy-paste template.
Before drafting, create this status table:
| Element | Status | Source |
|---|---|---|
| Who is hurting? | ⚠️ Hypothesis / ✅ Validated / ❌ Missing | |
| What pain exists? | ⚠️ / ✅ / ❌ | |
| Cost of problem | ⚠️ / ✅ / ❌ | |
| Why now? | ⚠️ / ✅ / ❌ | |
| What's impossible? | ⚠️ / ✅ / ❌ |
Gate: Require ≥2 elements ✅ Validated before drafting. If ≥3 elements ❌ Missing, run deep research first. See references/research-prompts.md for research templates.
Create CFD entries for each pain point with confidence scoring:
CFD-###: [Pain Point Name]
Source: [Where this evidence came from]
Tier: [1-5 evidence quality]
Confidence: [1-5]/5 (pre-product research)
Quote: "[Verbatim from source]"
Dimensions: [List distinct problems extracted from this source]
Next Target: "Would move to 3/5 if we interview X more customers"
Evidence Tier Hierarchy (strength of observation):
Confidence Scoring (pre-product, see PRINCIPLES.md):
Example entry with confidence:
CFD-001: Sales teams waste 5+ hours/week on spreadsheet workflow
Source: 3 customer interviews (SaaS sales director, SMB sales rep, enterprise sales manager)
Tier: 2-3 (workaround + cost quantification)
Confidence: 3/5 (source: 3-customer-interviews-jan-2026)
Quote: "I spend 5 hours every Friday reconciling our pipeline with the actual numbers in our CRM"
Dimensions:
- Manual data reconciliation between systems (workaround)
- Inventory work (scheduling impact)
- Single source of truth fragmentation (data quality risk)
Next Target: "Would move to 4/5 if we validate with 5 more sales leaders or observe workflows directly"
Extract multiple problems from each source. One quote often contains 3-4 distinct pain dimensions.
Example: "USB sticks removed for every update, no scheduling, screens don't communicate, priced for 100+ displays" → Sneakernet workflow, No dynamic scheduling, No centralization, Price mismatch
Every problem needs a number:
| Type | Calculation |
|---|---|
| Time | Hours/week × hourly rate |
| Money | Current spend on workaround |
| Opportunity | Revenue/outcomes missed |
| Risk | Penalty × probability |
Use the core output template. Reference CFD-IDs for every claim.
See references/examples.md for good/bad examples with explanations.
| Pattern | Example | Fix |
|---|---|---|
| Vague "Who" | "Small businesses" | → "SMBs with 1-10 screens" |
| Feature-as-problem | "Need a dashboard" | → "Can't see status" |
| Solution creep | "MVP must solve X" | → Stay on problem (v0.4) |
| Missing cost | "This is annoying" | → "Costs X hrs/week" |
| Speculation | "Users might want" | → Find evidence or reject |
references/research-prompts.md — Deep research templates by gap type. Use when gap assessment shows ≥3 missing elements.references/examples.md — Good/bad problem statement examples with explanations.assets/problem-statement.md — Copy-paste template for problem tables and CFD entries.Problem statement complete when quality gates pass. Next: v0.2 Market Definition (segments, sizing, ICP).
npx claudepluginhub mattgierhart/prd-driven-context-engineering --plugin prd-ceDefine a clear, evidence-based problem statement that frames customer pain without prescribing solutions. Use when discovering unmet customer needs, validating market problems, or prioritizing discovery research.
Use this skill when the user asks to "frame a problem", "define the problem", "write a problem statement", "articulate the user problem", "what problem are we solving", "help me think through the problem", "is this the right problem to solve", "clarify the problem", or when a user presents an idea and needs help distinguishing the problem from the solution. Do NOT use this skill if the user is ready to write a full PRD — use the execution/prd-authoring skill or /write-prd command instead.
Transforms customer insights into a precise, data-backed problem statement. Use when converging on which customer problem to solve or preventing solution-first thinking.