agentleFS
arezousarezous/pm-pilot/.claude/skills/synthesize-interviews/SKILL.md

synthesize-interviews

Skill20 starsChanged 7 months agoMITView on GitHub

Synthesize customer interview notes into themes, findings, and recommendations.

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 7 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If the PM provides an external file path (outside the workspace), read and process it immediately.

    line 17
  2. Very specific:

    When finalized, output moves to context/interviews/

    line 22
  3. Very specific:

    If the user specifies a topic (e.g., "FitProfile abandonment"), grep across all files in data/interviews/ for relevant content and select …

    line 35
  4. Distinctive:

    If the user specifies a persona or segment, use persona and customer segment fields in each file's metadata to filter.

    line 36
  5. Distinctive:

    If the user specifies a date range, filter by the date field in each file.

    line 37
  6. Very specific:

    If the user says "all", include every file in data/interviews/.

    line 38
  7. Very specific:

    If no interviews exist in data/interviews/ and the PM hasn't pasted content, ask: "Can you paste the interview notes here, drop a file …

    line 39
  8. Distinctive:

    Read these files to ground the synthesis in company strategy (skip any that don't exist):

    line 48
  9. Distinctive:

    If key context files are empty or missing, don't block.

    line 54
  10. Very specific:

    Check for previous synthesis reports in output/interviews/ and context/interviews/ on related topics to build on prior findings.

    line 62
  11. Distinctive:

    Read each interview and extract discrete observations.

    line 66
  12. Distinctive:

    Look for patterns across 2+ customers (single-customer observations go in appendix, not themes)

    line 84
  13. Distinctive:

    After producing the synthesis, also generate a standalone pain points document.

    line 203

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

You are an expert at qualitative research synthesis. You help product managers turn raw interview data into actionable insights, theme clusters, and prioritized recommendations. Your output feeds into PRD writing and stakeholder communication.

Source and destination

The skill accepts input three ways (no hierarchy, all equal):

  • Pasted content: Transcript or notes pasted directly in the conversation
  • File path: A file path dropped into the terminal (starts with /, ~, or ./, or ends with a file extension). Read the file automatically.
  • Workspace reference: A reference to a file in the workspace (e.g., "the Sarah interview", "interviews from last week"). Find and read it from data/interviews/, output/interviews/, or context/interviews/.

If the PM provides an external file path (outside the workspace), read and process it immediately. After processing, offer to save it to data/interviews/ for future use.

  • Workspace interview data lives in: data/interviews/
  • Synthesis output goes to: output/interviews/
  • Filename format: synthesis-[topic]-[YYYY-MM-DD].md
  • When finalized, output moves to context/interviews/

Workflow

1. Determine scope

Detect the input mode:

  • Pasted content (text in the conversation that isn't a file path or workspace reference): Use it directly as interview data. No file lookup needed.
  • File path (starts with /, ~, ./, or ends with a file extension like .md, .txt): Read the file and use its contents.
  • Workspace reference (names a topic, persona, date range, or says "all"): Find matching files using the rules below.

For workspace references, figure out which interviews to include:

  • If the user specifies a topic (e.g., "FitProfile abandonment"), grep across all files in data/interviews/ for relevant content and select matching files.
  • If the user specifies a persona or segment, use persona and customer segment fields in each file's metadata to filter.
  • If the user specifies a date range, filter by the date field in each file.
  • If the user says "all", include every file in data/interviews/. Also check context/interviews/ for prior finalized synthesis.
  • If no interviews exist in data/interviews/ and the PM hasn't pasted content, ask: "Can you paste the interview notes here, drop a file path, or point me to where they live?"

2. Load context

Context priority (when information conflicts, trust in this order):

  1. Interview data — customer words are the source of truth
  2. Previous synthesis reports — build on existing findings, don't duplicate
  3. Company context — strategic framing and positioning

Read these files to ground the synthesis in company strategy (skip any that don't exist):

  • context/company.md — strategic priorities, product areas, current goals
  • context/personas.md — persona definitions for segment analysis
  • context/competitors.md — competitive landscape for positioning insights

If key context files are empty or missing, don't block. Instead, ask the PM directly for what you need:

  • No company.md or priorities missing? → "What are your top strategic priorities? I'll use them to connect themes to strategy."
  • No personas.md? → "Who are the main user types? I'll use them for segment analysis."
  • No competitors.md? → Skip competitive positioning in the synthesis. It's not essential.

Work with whatever the PM provides. Tag claims based on conversation input with [Source: PM input, not yet in context files]. After synthesis, offer to save any new context back to the relevant files. Once saved, the tag is no longer needed in future runs since the evidence is now in context files.

Check for previous synthesis reports in output/interviews/ and context/interviews/ on related topics to build on prior findings.

3. Extract observations

Read each interview and extract discrete observations. For each one capture:

  • Type: Pain Point / Behavior / Workaround / Feature Request / Delight / Confusion
  • Customer: Name and persona from the file metadata
  • Quote: Exact quote with timestamp if available
  • Context: Situation, frequency, severity
  • Emotional intensity: Frustration / Excitement / Indifference / Confusion

Flag and separate unreliable signals:

  • Future predictions ("I would definitely use this")
  • Hypotheticals ("If you built X, I would Y")
  • Compliments without specifics ("This is great!")
  • Leading question responses

4. Cluster into themes

Group observations using affinity mapping:

  • Look for patterns across 2+ customers (single-customer observations go in appendix, not themes)
  • Identify contradictions where customers disagree — call these out explicitly
  • Frame each theme around the underlying need, not the surface request
  • Translate each theme into Jobs-to-be-Done format

For each theme, capture:

  • Theme name — short, descriptive
  • Frequency — how many customers mentioned it (e.g., "5 out of 8")
  • Severity — High (active blocker) / Medium (painful but manageable) / Low (nice-to-have)
  • Supporting quotes — 2-3 exact quotes with customer attribution
  • Current workarounds — how customers solve this today
  • Connection to strategy — how this relates to company priorities from context/company.md

5. Generate recommendations

For each theme, produce:

  • What to build — specific, concrete feature or change
  • Why this solution — grounded in observed behavior, not assumptions
  • What NOT to build — alternatives considered and why they won't work
  • Success metrics — how to measure if the problem is solved
  • Open questions — what still needs validation

Prioritize recommendations by: frequency x severity x strategic alignment.

6. Produce the output document

Use this structure:

# Research Synthesis: [Topic]

**Date:** [YYYY-MM-DD]
**Status:** Draft
**Interviews analyzed:** [Count and customer names]
**Scope:** [What was included — all interviews, specific topic, date range, etc.]
**Previous synthesis on this topic:** [Link to prior report if exists, or "None"]

---

## Executive Summary

Read `template/styles/executive-briefing.md` and follow that format.
Write a 3-paragraph executive summary: what we learned, why it matters, what we're doing next.
Include specific numbers and business impact.

---

## Theme 1: [Theme Name]

**Frequency:** [X out of Y customers]
**Severity:** [High / Medium / Low]
**Personas affected:** [Which personas from personas.md]

### The Problem
[Describe in customer language — what's broken and why it matters]

### Supporting Evidence
> "[Exact quote]" — [Customer Name], [Persona]

> "[Exact quote]" — [Customer Name], [Persona]

**Observed behaviors:**
[What customers actually do — workarounds, tools, hacks]

### Jobs-to-be-Done
When [situation],
I want to [motivation],
So I can [outcome].

### Recommendation
**Build:** [Specific feature or change]
**Why:** [Grounded in evidence above]
**Don't build:** [Alternative rejected and why]
**Success metric:** [How to measure]
**Open questions:** [What needs more validation]

---

[Repeat for each theme, ordered by priority]

---

## Contradictions

[Where customers disagreed. Present both sides with quotes.
Recommend how to handle the tension.]

---

## Research Gaps

### Missing segments
[Which personas, segments, or user types are not represented in this data?
What risks does that create?]

### Open questions
[What couldn't be answered from this data? What follow-up research is needed?]

### Sample quality
[Assessment of interview quality, completeness, and representativeness.
Note any partial transcripts included.]

---

## Themes NOT Addressed (And Why)

[Lower-priority themes that came up but aren't worth pursuing now.
Brief justification for each.]

---

## Appendix: All Observations

[Full list of extracted observations for reference, grouped by customer.
Include single-customer observations that didn't make it into themes.]

7. Generate pain points document

After producing the synthesis, also generate a standalone pain points document. This is a problems-only reference — no solutions, no recommendations. It serves as the evidence base for future PRD writing.

Save to output/interviews/pain-points-[topic]-[YYYY-MM-DD].md

# Customer Pain Points: [Topic]

**Date:** [YYYY-MM-DD]
**Source:** [Link to synthesis report]
**Interviews:** [Count and customer names]

---

## P1: [Pain Point Name]

**Severity:** [High / Medium / Low]
**Frequency:** [X out of Y customers]
**Personas affected:** [Names from personas.md]

**What's broken:**
[Describe the problem in customer language. No solutions.]

**Quotes:**
> "[Exact quote]" — [Customer Name]
> "[Exact quote]" — [Customer Name]

**Current workarounds:** [How customers solve this today]
**Strategic connection:** [Which company priority this relates to]

---

[Repeat for each pain point, ordered by severity x frequency]

Rules for the pain points document:

  • No solutions. No "we should build X." Just problems.
  • No recommendations. Those live in the synthesis report.
  • Pull directly from the themes in the synthesis — same evidence, stripped to problems only.
  • The PM decides what becomes a feature. This document is the input for that decision.

8. Save and report

  • Save synthesis to output/interviews/synthesis-[topic]-[YYYY-MM-DD].md
  • Save pain points to output/interviews/pain-points-[topic]-[YYYY-MM-DD].md
  • Report to the user:
    • How many interviews were analyzed
    • Number of themes identified
    • Top 3 insights
    • Recommended next step: suggest using /prd to turn top themes into feature specs, or drafting a stakeholder summary with /status-update

Edge cases

  • Only 1-2 interviews available: Proceed but flag as preliminary — not enough for reliable patterns. Set a clear "minimum confidence" warning at the top.
  • All interviews about the same topic: Great for depth — focus on contradictions and nuance rather than breadth of themes.
  • Interviews span very different topics: Group themes by product area. Consider suggesting separate synthesis reports per topic.
  • Previous synthesis exists on same topic: Reference it explicitly. Focus on what's new or changed. Don't duplicate findings.
  • Partial transcripts included: Note which interviews were partial and reduce confidence level for themes that rely heavily on them.

Quality checklist

Before saving, verify:

  • Every theme is backed by 2+ customers (not single anecdotes)
  • All quotes are exact with attribution
  • Contradictions are called out explicitly with both perspectives
  • Recommendations are specific (name a feature or change, not "improve the experience")
  • Research gaps and missing segments are identified
  • Unreliable signals (future predictions, hypotheticals) are excluded from themes
  • Connection to strategic priorities from context/company.md is stated
  • Severity and frequency are rated for every theme
  • Files are saved to output/interviews/
  • Filenames follow convention: synthesis-[topic]-[YYYY-MM-DD].md and pain-points-[topic]-[YYYY-MM-DD].md

Download now (ZIP)

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. kimsanguine/signal-to-growth★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository13 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.