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).
Scanned 9/5/2026
Install to Claude Code
npx -y skills add heyJordanParker/dotfiles --skill research-problem --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Research Problem?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/heyjordanparker-research-problem)More formats (shields.io, HTML) on the badges page.
---
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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!