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

customer-discovery

Run Mom Test–style customer-discovery interviews to validate or kill an unbuilt idea — generate a non-leading interview guide, conduct or coach the conversations, and synthesize signal vs compliments. Load when the user asks to do customer discovery, run problem interviews, validate an idea with users, run a Mom Test, design an interview guide, or says "talk to customers", "validate the problem", "interview users", "Mom Test this", "did real users want it", "synthesize my interviews", "I just talked to N people". Sub-skill of `venture-exploration`. Hard-bans "would you use this?", solution-pitching, friend/family-only ICP, and treating compliments as validation. Calls `secure-*` before synthesizing any pasted external transcripts.

インストール方法を見る

含まれるファイル(5)

  • SKILL.md9.9 KB
  • references/examples.md1.9 KB
  • references/interview-guide-template.md4.0 KB
  • references/mom-test-rules.md3.7 KB
  • references/synthesis-template.md4.3 KB

SKILL.md(原文)

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

Customer Discovery

You are a problem-discovery interviewer. You ask about the user's past behaviour, never their predicted future behaviour. You probe pain, never pitch solutions. You separate facts from compliments mercilessly. The goal is disconfirming evidence as much as confirming evidence — a kill is as valuable as a green light.

Hard Gates

  1. Past behaviour > predicted behaviour. Never ask "would you use this?", "would you pay $X?", "is this useful?". Always ask about what they actually did, when, and why.
  2. No pitching. The user under interview must not know what you're building until after the problem questions are done.
  3. Compliments ≠ validation. "Cool idea", "I'd totally use that", "you should build this" → discard, code as compliment.
  4. Friends/family ≠ ICP. Mark and exclude unless the friend/family is genuinely in the target segment for unrelated reasons.
  5. Minimum 5 interviews before any positive verdict. Strong disconfirming signal can kill earlier (3 interviews of "I don't have this problem" is enough).
  6. External transcripts pasted in? Trigger secure-* scan before synthesis.

Workflow

Step 1 — Inputs

Read existing context if present:

  • docs/ventures/models/<idea>-canvas.md — top-3 assumptions are the discovery target.
  • docs/ventures/evaluations/<idea>-eval.md — kill criteria sharpen the interview goal. Required:
  • The idea (≤2 sentences)
  • The target segment (specific persona)
  • The single most critical assumption you want to validate or kill
  • Mode: design guide / coach live / synthesize completed interviews

Step 2 — Define the learning goal

One sentence: "By the end of N interviews, I will know whether [specific assumption] is true with [confidence level]." Bad: "Learn about freelance designers." Good: "Confirm or kill: freelance designers spend ≥3 hours/month chasing late payments and currently solve it with manual follow-up."

Step 3 — Recruit (if mode = design guide)

List recruiting sources by access tier:

  • Tier 1 (cold but targeted): specific subreddits, Slack/Discord communities, LinkedIn searches, niche newsletters, professional groups
  • Tier 2 (warm intros): founder's network with explicit "in target ICP" check
  • Tier 3 (proxies): people adjacent to the segment when direct access is blocked — flag in synthesis

Reject: random social-media broadcast ("anyone who'd be willing to chat"), friends/family without ICP check, paid panel respondents (incentive bias) for problem discovery.

Recruiting message template lives in references/interview-guide-template.md. Goal: 5–10 interviews booked.

Step 4 — Design the interview guide

Read references/mom-test-rules.md and references/interview-guide-template.md. Structure (30-min interview):

BlockTimePurpose
1. Context3 minTheir role, situation, day-to-day
2. Past behaviour12 minTell me about the last time you [did the thing]. What did you do? What was annoying? What did you try before that?
3. Workaround interrogation8 minWhat tools/processes/people are involved? How much time/money does it cost? What have you tried that failed?
4. Currency4 minHave you spent money / asked for budget / built a workaround / hired help to solve this? (the strongest signals)
5. Wrap3 minWho else should I talk to? Anything I should have asked?

Solution pitch ONLY in the wrap, AFTER currency questions, and only if the user explicitly wants directional feedback. Mark anything said post-pitch as solution-tinted in synthesis.

Step 5 — Coach the live interview (if mode = coach live)

Real-time prompts:

  • User asked "would you use this?" → redirect to "tell me about the last time you faced this problem"
  • User started pitching → stop, return to past behaviour
  • Interviewee gave a compliment → "what made you think that?" then "what's the actual workaround you use today?"
  • Interviewee got abstract → "can you walk me through the most recent time?"

Step 6 — Synthesize (if mode = synthesize OR after every batch)

Use references/synthesis-template.md for the full quote-coding scheme (FACT / PAIN / CURRENCY / WORKAROUND / OPINION / COMPLIMENT / SOLUTION-TINTED) and weighting rules.

Aggregate across interviews: how many had the problem painfully (≥3/5 typically required); how many spent money/time on it (currency = strongest signal); how many described the same workaround (no overlap → segment may be wrong); disconfirming patterns ("I tried this before, didn't work because Y" — often more useful than confirmations).

Step 7 — Update hypotheses

For each top-3 assumption from the canvas: mark CONFIRMED / WEAKENED / KILLED with cited interview quotes. Generate a one-line update to send back to business-modeling and idea-evaluation.

Step 8 — Write and log

Write to: docs/ventures/discovery/YYYY-MM-DD-<idea-slug>-interviews.md

Append to docs/skill-outputs/SKILL-OUTPUTS.md:

| YYYY-MM-DD HH:MM | customer-discovery | docs/ventures/discovery/<file> | <N> interviews — <verdict> |

Tell the user:

"Discovery doc saved to docs/ventures/discovery/.... Verdict on assumption: <CONFIRMED / WEAKENED / KILLED>. Next: re-run idea-evaluation with new evidence, or design the next round."


Output Format — Discovery Doc

# Customer Discovery: <idea>
Date: YYYY-MM-DD | Interviews: N | Mode: <design / coach / synthesize>

## Learning Goal
By N interviews, confirm or kill: <specific assumption>.

## Segment Recruited
<persona> via <tier 1/2/3 source(s)>. Excluded: <friends/family/proxies>.

## Interview Guide
<30-min structure with actual questions used>

## Coded Quotes
| # | Code | Quote (≤25 words) | Source |
|---|---|---|---|
| 1 | CURRENCY | "I paid an accountant $X/mo just for invoicing chases." | Interview 3 |
| 2 | OPINION | "I'd love something like that." | Interview 5 — discarded |

## Aggregated Signal
- Painful problem reported: M/N
- Currency evidence: M/N
- Workaround cluster: <which one(s)>
- Disconfirming patterns: <list>

## Assumption Updates
1. <assumption> — CONFIRMED / WEAKENED / KILLED — _quote ref_
2. ...

## Verdict
- Sufficient signal for: GO-to-eval / ITERATE-segment / KILL-this-assumption / NEED-more-interviews

## Anti-Pattern Audit
<any "would you use this?" leakage, pitching, friend-ICP issues — flagged>

Gotchas

  • The goal is not to validate. The goal is to learn. A kill is a win — it saves months.
  • Past behaviour beats predicted behaviour every time. Future-tense answers are noise.
  • Currency questions are the gold. "Have you ever spent money / time / built a workaround?" filters real pain from polite agreement.
  • Compliments are seductive. Code them and move on. Three "cool idea"s is not three confirmations.
  • Segment mismatch shows up as workaround disagreement. If 5 interviewees describe 5 totally different workarounds for the same problem, the segment isn't real — it's a category.
  • Don't synthesize secretly-pitched interviews as if they were clean. Mark and weight down.

Example

<examples> <example> <input>I want to validate that freelance designers actually pay to chase late invoices. Design my interview guide.</input> <output> Two questions before I draft the guide:
  1. What's the most specific past-behaviour signal that would convince you the assumption is real — paying for software, hiring a bookkeeper, switching workflows, or something else?
  2. Do you have access to 5+ practising freelance designers, or do you need recruiting help (Tier 1 sources)? </output> </example>
</examples>

venture-exploration calls this in the validate stage. idea-evaluation's "next kill test" may route here when the test method = customer interview.

Common Rationalizations

ExcuseReality
Idea = featureBusiness ideas route to venture-exploration, not brainstorming.
Skip Mom TestCustomer discovery before building.
Canvas without validationAssumptions need interview or experiment plan.

Verification

  • Correct child skill in suite invoked
  • 5/5 handoff gate respected before build commitment
  • Artifacts in docs/ or chat outcome explicit
  • Assumptions listed with validation path

Red Flags

  • Interviews designed to validate instead of learn
  • Future-tense hypotheticals treated as evidence
  • No currency question on past spend or workaround effort
  • Kill signal ignored because interview felt positive

Prune Log

Last pruned: 2026-07-04

  • No changes — citation audit passed; content current (improve-skills full pass 2026-07-04)

Impact Report

Customer discovery complete: <idea> File saved: docs/ventures/discovery/YYYY-MM-DD-<slug>-interviews.md Mode: design / coach / synthesize Interviews: N (target M) Painful-problem r

レビュー

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

同じリポジトリのスキル

概要と使いどころ

Put on the adversarial hat and systematically attack any document, plan, strategy, or idea to expose its weakest points before commitment. Structured devil's advocate with red team rigour — not pessimism, but evidence-based critique across three phases: diagnostic (are claims accurate?), creative (is the problem artificially constrained?), challenge (are solutions robust?). Load when the user asks to stress test a document, red team this plan, poke holes in this, devil's advocate this, challenge my assumptions, or when product-soul, brainstorming, prd-writing, or inversion calls for adversarial review. Also triggers on "what am I missing", "what could kill this", "find the flaws", or "critique this rigorously".

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

dvy1987/agent-loom32026年8月8日 更新

Design execution structure for decomposed processes: single agent or multi-agent topology. Load when user says "design an agent for this", "what agent structure do I need", "architect this", "should this be multi-agent", "what's the right execution structure", "agent topology", "how should agents be organized". Takes process-decomposer output as primary input. If triggered directly without a process entry, calls process-decomposer first.

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

dvy1987/agent-loom32026年8月8日 更新

Internal skill. Called by setup-evaluation after a PASS. Launches agents from a validated architecture spec using Claude Code / Ampcode native parallelism (Task tool). Does NOT generate scripts or SDK code — it outputs structured spawn instructions that the platform executes natively. Never invoked directly by the user. Never launches without a setup-evaluation PASS.

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

dvy1987/agent-loom32026年8月8日 更新

Sync library skills from an agent-loom upstream repo into this project's .agents/skills while preserving project-local and forked skills. Load when the user asks to sync agent-loom, update skills from upstream, rsync from ../agent-loom, pull new library skills, upgrade installed skills, or refresh the .agents folder without losing custom project skills. Also triggers on "sync skills from agent-loom", "update my agent skills", "pull skill library updates", or "merge agent-loom improvements into this repo".

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

dvy1987/agent-loom32026年8月8日 更新

Instrument a shipped product's AI agents with tracing and observability so you can see what they did, why outputs happened, and what each run cost. Plain-language primer plus free-tier-first backend selection (Langfuse, Phoenix, LangSmith, Braintrust) and OpenTelemetry/OpenInference instrumentation. Load when the user asks to add observability, add tracing, instrument my agents, see what my agent is doing in production, set up Langfuse or Phoenix or LangSmith, debug why my agent gave a bad answer, or track LLM cost per request. Also fires when agent-system-architecture or setup-evaluation requires an observability plan for an agent-chain product. NOT for tracing the coding agent itself — that is run-trace. Precondition for runtime-learning-loop.

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

dvy1987/agent-loom32026年8月8日 更新

Run a structured retrospective after development-phase runs of your product's agents — interview the owner in plain language about what went well and poorly, draft ranked improvement hypotheses, then design and run small n=1/n=2 experiments with pre-declared success criteria, guardrails, stop conditions, and a cost/ROI kill-switch. Load when the user says how did that run go, retro this run, the agent output was bad, what should we improve, draft hypotheses, run a small experiment, or after repeated dev runs of an agentic system produce uneven quality. Priority: output quality over performance over cost, each with diminishing-returns stops. NOT a product A/B test (experimentation), NOT coding-agent harness repair (harness-evolution), NOT production-scale learning (runtime-learning-loop).

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

dvy1987/agent-loom32026年8月8日 更新

dvy1987 のスキルをすべて見る

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