本文へ移動
cccskills
無料GitHub で公開

customer-research

Turn raw customer material into evidence-backed personas and verbatim voice-of-customer language. Two modes - analyse sources the user already has (call transcripts, support tickets, survey responses, sales notes, reviews), or source new material from public places customers actually talk. Produces quoted pains, objections, and switch triggers that other skills consume, never invented ones. Use when the user says "customer research", "voice of customer", "what do our customers actually say", "we need real quotes", "analyse these call transcripts", "read our support tickets", "build a persona from data", "find what customers complain about", or when a persona is marked provisional. For structuring the finished persona into the knowledge base, see brand-context. For the JTBD persona template itself, see customer-persona.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md8.6 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

customer-research

Closes the loop from nothing to a persona. Most persona work assumes the research already exists. This skill produces it.

The interview discipline

Mode A analyses calls that may themselves be badly run, and Mode B reads what people volunteered. Both need Rob Fitzpatrick's rules from The Mom Test (2013) applied as a filter:

  1. Talk about their life, not your idea. Anything a person says about your product is a compliment or a courtesy, not data.
  2. Ask about specifics in the past, never generics about the future. "What did you do the last time this happened" is evidence. "Would you use this" is noise, and should be discarded rather than coded.
  3. Listen more than you talk. In a transcript, a long interviewer turn before an answer usually means the answer was led.

When coding quotes, discard anything that answers a leading or hypothetical question, and say how many you discarded. A corpus of compliments produces a persona of people who do not exist.

The rule that makes the output worth anything: every pain, objection and trigger is a quote with a source, or it is tagged as an inference. No invented customer language, ever.

Two modes

Ask which, or infer from what the user supplies.

Mode A: analyse what they have

Sources, in descending order of value:

SourceWhat it givesWatch for
Won and lost deal call recordings or notesSwitch triggers, real objectionsSales notes are already paraphrased, treat as second-hand
Support ticketsPains in the customer's own wordsSkews to existing customers with problems, not prospects
Churn or exit interviewsThe strongest signal in the whole listSmall N, treat each as a case not a statistic
Onboarding or sales discovery callsThe trigger event, stated fresh
Open-text survey responsesVolume and language patternsLeading questions produce leading answers, check the question
Reviews of you and of competitorsPublic, comparative, unfilteredSkews to extremes

Mode B: source new material

When the user has nothing. Use WebSearch and WebFetch to find where this audience already talks in public: review sites for the category, relevant subreddits and forums, community threads, comparison and alternatives posts, and question sites. Search for the problem in the customer's language rather than the product category, since people describe symptoms before they know the solution exists.

Always tell the user what Mode B cannot do: it finds language, not your customers. Public complaint skews negative and toward the vocal. It is a strong start and a weak conclusion, and the output must say so.

Process

  1. Define the question. What decision does this research inform? A persona for a new segment, the objections for a sales page, the language for an ad. Research without a decision produces a document nobody uses.

  2. Inventory sources. List what exists, how many of each, and the date range. State the sample size in the output. Twelve tickets is not a pattern, it is a hint, and the output should say which one it is.

  3. Extract verbatim. Pull actual sentences, not summaries. For each, record: the quote, the source type, the date if known, and the role of the speaker if known.

  4. Code the quotes. Group into: pains, desired outcomes, trigger events, alternatives considered, objections, and the vocabulary they use for the problem. A quote can carry more than one code.

  5. Count. How many distinct people expressed each theme, not how many quotes. Ten quotes from one angry customer is one data point.

  6. Separate signal from noise. A theme is worth acting on if three or more distinct people raised it, or if one person raised it and it cost a deal. Everything else is listed as a hint, not a finding.

  7. Write the findings and, if the user approves, merge into knowledge/icp/personas.md.

The vocabulary table

The single most reusable output. Downstream writing skills consume it directly.

They sayWe sayUse theirs when
[customer phrase][our internal or industry term][ads, landing page headline, cold email subject]

Customers search and click on their own words, not the category's. When these two columns differ, that gap is usually worth money.

Output format

# Customer research: [question]

**Decision this informs:** [what changes based on this]
**Mode:** A (existing sources) | B (public sourcing)
**Sources:** [type and count each, date range]
**Distinct people represented:** N
**Confidence:** high (N>=15 distinct, multiple source types) | moderate (N 5-14) | directional (N<5 or single source type)

## Findings

### Pains
| # | Theme | Distinct people | Verbatim | Source |
|---|---|---|---|---|
| 1 | [theme] | N | "[exact quote]" | [type, date] |

### Trigger events
[what was happening the day they started looking, quoted]

### Alternatives considered
[including doing nothing, with how often each appeared]

### Objections
| Objection | Distinct people | Verbatim | Who resolved it and how |
|---|---|---|---|

### Vocabulary
[the they-say / we-say table]

## Hints, not findings
[themes below the threshold, kept because they may matter later]

## What this research cannot tell you
[explicit limits: sample skew, missing segments, source bias, anything Mode B cannot see]

## Recommended next research
[the one gap most worth closing, and the cheapest way to close it]

Merging into personas

Only on explicit approval. When merging into knowledge/icp/personas.md:

  1. Replace any [NEEDS INPUT: real customer language] tag with a real quote and its source.
  2. Upgrade confidence: provisional to high only when the persona has at least three distinct people behind it and at least one real quote per pain.
  3. Never delete an existing quote. Add, and mark the older one with its date.
  4. Append a source line: Research: [file path], DD-MM-YYYY, N=[distinct people].

Self-check before saving

  • Every pain, objection and trigger has a verbatim quote or is explicitly tagged [INFERRED]
  • No quote was smoothed, shortened, or corrected for grammar. Verbatim means verbatim
  • Distinct-people counts are people, not quotes
  • The confidence label matches the actual sample size
  • "What this research cannot tell you" is filled in and specific, not boilerplate
  • Mode B output states plainly that public sources are not your customers
  • Themes below threshold are in Hints, not promoted into Findings

Rules

  • Never write a quote that was not said. This is the whole value of the skill. An invented quote is worse than no research, because it launders a guess into evidence that every downstream skill then trusts.
  • Never present a single loud customer as a pattern.
  • Preserve the customer's grammar and phrasing exactly. The awkward phrasing is often the exact phrase that should appear in an ad.
  • Anonymise by default: role and company type, not names, unless the user confirms permission to use them.
  • If the user asks for a persona and has no sources at all, say so plainly and offer Mode B, rather than producing a plausible persona from nothing.
  • Save to output/customer-research/<DD-MM-YYYY>-<topic-slug>.md.

Related skills

  • /brand-context to write the finished persona into the knowledge base
  • /customer-persona for the JTBD persona structure this feeds
  • /icp-research for segment and firmographic definition, which is a different question from voice
  • /competitor-analyst when the research surfaces competitor comparisons worth pursuing
  • /copy-review to check whether existing copy uses the vocabulary this research found

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Rate any product, feature, or experience on the 11-star scale (Brian Chesky's Airbnb thought experiment). Use when user says "rate this experience", "11-star", "star rating", "experience audit", "how good is this", "experience rating", "product audit", "quality assessment", or wants to evaluate product quality and identify improvement paths. Also trigger when user wants to benchmark a feature, assess where a product stands, or map out what "great" looks like - even if they don't explicitly say "11-star".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Generate A/B copy variants grounded in Eugene Schwartz's awareness and market-sophistication stages and John Caples' tested-headline discipline. Every variant declares its angle, the awareness stage it targets, and a falsifiable hypothesis, and the skill recommends which pair to test first and what delta counts as signal. Use when the user says "A/B test this", "write variants", "give me options", "test different angles", "copy variants", "ab copy", "test this headline", "multiple versions", "which version is better", or wants to test copy before publishing. For reviewing copy that already exists, see copy-review. For sample size and stopping rules, see growth-experiment. For diagnosing a page rather than its words, see page-cro. For full paid ad sets by platform, see ad-campaign-writer.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Write measurable acceptance criteria for requirements or user stories. Use when the user says "write acceptance criteria", "definition of done", "how do we test this", "fit criteria", "given when then", "Gherkin scenarios", "what does done look like", "testable conditions", "how will we know this works" - even if they don't explicitly say "acceptance criteria".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Build a strategic account plan for winning, retaining, or expanding a named account. Use when the user says "build an account plan", "strategic account planning", "how do I grow this account", "account expansion strategy", "whitespace analysis", "QBR prep", "key account review", "map the stakeholders in this account", "land and expand plan", "how do I break into [company]", or wants a structured strategy for a specific account.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Write paid ad copy for LinkedIn, Google, Meta, and YouTube. Produces multiple variants per platform, each targeting a different Eugene Schwartz awareness level and Cialdini persuasion principle. Use when the user asks for ad copy, ad variants, "write LinkedIn ads", Google ads, Meta ads, paid social copy, ad headlines, or wants creative for a paid campaign. Reads brand voice, ICP, and positioning from knowledge/. For organic social posts, see linkedin-post or social-calendar. For the landing page the ad points at, see landing-page-writer. For testing variants, see ab-copy-writer.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Design clean and consistent APIs. Use when the user says "design an API", "API design review", "design these endpoints", "REST API for X", "GraphQL schema", "API contract", "how should this endpoint work", "review my API design", or wants to create or improve an API interface - even if they don't explicitly say "API design".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

qa-aman のスキルをすべて見る

このスキルの問題を報告する