Customer-research can analyze interviews, surveys, and support records, investigate public discussions, or plan follow-up interviews. The easiest first task to verify is a synthesis of real material with clear links between themes and evidence, rather than a polished but invented persona.
Install and invoke
Run this in your project terminal to install only this skill for Claude Code:
npx skills add coreyhaines31/marketingskills --skill customer-research -a claude-code
Node.js and npx must be available. For Codex, replace -a claude-code with -a codex. In the agent conversation, explicitly ask it to use customer-research and supply your material. The installation command belongs in the terminal, not in your content brief.
Connect the research to a decision
State what the findings should inform: onboarding changes, pricing explanations, or why a particular group stopped using the product. Provide transcripts, tickets, or survey responses with dates, customer categories, and sample counts.
Example brief:
Use customer-research on twelve transcripts in interviews/.
Investigate why users did not continue collaborating after first use. Separate individuals from team leaders.
For each theme, report independent participant count, quote locations, contradictory evidence, and confidence.
End with three questions to validate next. Do not invent persona details.
Extract each person’s intended job, pain, search trigger, desired outcome, and previous alternatives before clustering. Keep quotations separate from editorial interpretation. A smoother model-written sentence must not be presented as a verbatim quote. Do not infer company size or job role from weak hints.
Move from recurring themes to action
Analyze segments separately and distinguish defects, confusion, missing capabilities, and mismatched expectations. Count independent sources, not repeated posts by the same person across channels. Strong emotion can be informative, but frequency and impact need separate explanations.
The skill provides confidence categories and suggested sample thresholds. These prompt caution about weak evidence; they are not statistical guarantees. Tickets overrepresent problems, reviewers often have unusually strong experiences, and older interviews may describe an earlier product. Keep conflicting observations because they may reveal meaningful differences between groups.
Choose a deliverable that supports the immediate decision: a thematic report, traceable quote bank, or interview plan. If evidence is inadequate, a clear research-gap list is more useful than filling a fictional persona. Check the permitted use of quotations before placing them on public pages. An individual’s recorded experience also cannot automatically establish a result the product delivers for everyone.
Turn customer language into checkable findings
Choose the research mode from the material available. With interviews and tickets, extract triggers, attempted alternatives, desired outcomes, and exact source locations before synthesizing. With only public reviews, treat observations as leads, not a representative sample of your customers. With no evidence and a consequential question, design interviews before producing a “typical persona.” Preserve interview IDs and locations for quotations, and separate verbatim language, your paraphrase, and your inference.
A useful brief is: “Analyze these twelve churn interviews. Segment by company size and identify reasons for stopping within the first thirty days. For every theme, list the interviews where it appears, one approved internal quotation, and any contrary example. Do not turn the sales team’s assumptions into customer statements.” That makes the synthesis traceable and prevents a few vivid comments from becoming a universal claim.
Ask for a final table of theme, evidence, affected segment, product or messaging decision, and unanswered question. If two segments report opposite causes, keep them separate. In follow-up interviews, ask about a specific past action and what triggered it, rather than whether someone hypothetically would buy. The deliverable should improve the next decision, not merely produce an attractive persona slide.
Example: use public discussions to design interviews, not declare findings
Prepare ten public discussions related to your target task, with original links, dates, and surrounding context, and describe the customer segment you care about. Ask: “Use customer-research’s online-signal mode. Extract current workarounds, the step people struggle with, and their own words for the problem. Cite thread IDs for every theme and propose five follow-up interview questions. Do not call forum participants our existing customers.”
Open a sample of referenced threads during review to make sure the summary fits the context. A popular joke is not a purchase objection; three posts by one person are not three independent observations. Once an apparently important theme emerges, interview people who actually match the target segment and ask about their most recent concrete experience. Without that validation, label the conclusion an exploratory signal, not a customer-wide finding.
Preserve differences between evidence sources
Tell the agent whether this run analyzes interviews you already have or discovers signals in public communities. Interviews can be compared with observed behavior; public posts are better treated as interview hypotheses, not population estimates. Ask each theme for a count, representative quote, and counterexample, and separate buyers, admins, and daily users. Intercom’s research practice similarly uses data to spot what happened, interviews to investigate why, and a concrete product decision to make the work useful.
Phoebe Fu’s public field test shows a useful public-signal workflow. She started with a narrow question about Agent Skills readers, extracted quotes and context from eight Reddit and GitHub discussions, and grouped them into five themes with links, frequency, confidence and sample-bias notes. “Source proof” and workflow drift emerged as leads, but she explicitly did not treat forum posts as substitutes for interviews. Keep the post inventory and coding decisions so another editor can check each theme.