Run the research pass on one problem — where it lives, whose words voice it, what the failure cost, the SHAPE of help sought or bought, and who circles it — into the market thread. TRIGGER when one problem needs its buyer language mined deep. DO NOT TRIGGER to enumerate the field (discover-audience), to study a competitor's own pages (research-competitor), or to draw the competitive set (discover-competitors).
Installs into .claude/skills of the current project.
Are you the author of Research Problem?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/heyjordanparker-research-problem)
---
name: research-problem
description: Run the research pass on one problem — where it lives, whose words voice it, what the failure cost, the SHAPE of help sought or bought, and who circles it — into the market thread. TRIGGER when one problem needs its buyer language mined deep. DO NOT TRIGGER to enumerate the field (discover-audience), to study a competitor's own pages (research-competitor), or to draw the competitive set (discover-competitors).
---
# Research Problem
Run /research on one problem. Subject: the one problem, in its own thread folder `research/<problem-slug>/` — a short kebab-case slug of the problem, never the sentence. The base owns the trust check, the page gate, the verbatim-or-PARAPHRASE record format with full citations, the unreadable-page rule, the leave-unjudged rule, and the write into `research/<subject>/<topic>.md`. This skill adds only the problem axis below.
Inputs: the one problem, and the population the product serves, stated as people, from the research `Brief.md`. Excluded: owner facts, product facts, competitor records, and any persona or target buyer — you mine what the people actually say, never confirm a guess about who they are, and you stay blind to the competitor thread.
## Capture the problem in every dimension
The target is the problem in every dimension: what it is, how people refer to it, its symptoms, where it hurts exactly, how people react to it, their fears around it, their dreams around it — and the buying situation the problem sits inside. Sort each captured quote into:
- **Pain** — what is broken in their current situation: the symptoms, where it hurts exactly, the words they use for it.
- **Desire** — the outcome they want and the dreams surrounding the problem, in their words.
- **Objection** — the reason they hesitate, doubt, or walk, and the fears surrounding the problem.
- **Trigger event** — what put them in-market: the moment or change that turned the problem urgent, in their words.
- **Incumbent stack** — what they run now to cope: the tools, workarounds, and manual process the problem lives inside.
- **Switching threshold** — what it would take to move them off the incumbent: the cost, risk, or last straw they name.
Concrete on-page facts that fit no dimension — counts, prices, platform behaviors stated on the page — are filed in the thread's `observed-facts.md`, unjudged.
The thread's files carry exactly these names: `pain.md`, `desire.md`, `objection.md`, `trigger-events.md`, `incumbent-stack.md`, `switching-threshold.md`, `speaker-stories.md`, `observed-facts.md`.
## Capture the concrete story behind the problem, per speaker
For each place the problem is voiced, capture the concrete story from ONE speaker: what that person was trying to do, what specifically failed, what they did next, what it cost them, whether they sought or bought a solution and the SHAPE of help they sought or paid for (paid diagnosis, a redesign, a DIY course, a hire), and what the thread resolved to for that speaker — a sale, no sale, a fix that worked, gave up. Tag each speaker problem-holder or advisor — an advisor's or replier's words never describe the problem-holder's state, and one speaker's words never fill another's story. Capture who circles the problem — the advisors, sellers, and peers who reply. Suppressing a positive outcome is fabrication.
## Get the speaker mix right
The problem is proven by the people who hold it, so buyer voices are the required core of the file — the problem-holders describing their own situation in their own words. Vendor and seller content is legal to record, but only tagged vendor-claim: a vendor page describing the problem is the vendor's marketing framing of the problem, never a buyer voicing it, and it never fills a problem-holder's story. A problem file carrying zero problem-holder claims — built only from vendor-claim and advisor material — fails Verification: it records how the problem is sold, not that anyone holds it.
Verification: the file carries at least one problem-holder claim in the buyer's own words; every vendor or seller line is tagged vendor-claim and never counted as a buyer voicing the problem; each speaker is tagged problem-holder or advisor; and no speaker's words fill another's story.