Windsurf + Aider targets, MCP server, and demo placement (#33)

Broadens both reach (more tools) and content types (an MCP server), continuing
the multi-platform story.

Windsurf + Aider:
- build-exports.mjs gains two platforms: exports/windsurf/*.md (workspace rules,
  trigger: model_decision) and exports/aider/*.md (conventions for `aider --read`).
  Now 5 platforms (ChatGPT, Gemini, Cursor, Windsurf, Aider).
- install.sh + bin/cli.mjs install both (windsurf -> .windsurf/rules, aider ->
  .aider/skills with a --read hint); generated README index is excluded from copies.
- One-line windsurf-install.sh / aider-install.sh wrappers for parity.

MCP server (new content type):
- mcp/server.mjs — zero-dependency stdio MCP server exposing list_skills,
  search_skills, get_skill. Published as a second bin (pm-claude-skills-mcp).
  Logs to stderr; reads bundled skills/ at startup. mcp/README.md documents
  client config.

Also: README hero "See it in action" demo placement (ready to swap in a GIF;
recording guide in web/docs-assets/README.md), Works-With table + exports +
install docs updated, CHANGELOG Unreleased. package.json files/bin updated.


Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px

Co-authored-by: Claude <noreply@anthropic.com>

exports/aider/pm-discovery/assumption-mapper/assumption-mapper.md

@@ -0,0 +1,61 @@
+# Assumption Mapper Skill
+
+Surface and prioritize the untested assumptions embedded in any product plan before development begins.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Product brief, PRD, or concept description** (even rough notes work)
+- **Stage** (concept / discovery / pre-build / post-launch — affects which assumptions matter most)
+
+## Process
+1. Read the provided brief, PRD, or concept description
+2. Extract assumptions across four categories:
+   - **Desirability** (do users want this?)
+   - **Feasibility** (can we build it?)
+   - **Viability** (will it sustain the business?)
+   - **Usability** (can users actually use it?)
+3. Score each assumption:
+   - Confidence (1-5): How sure are we this is true?
+   - Impact (1-5): How badly does the plan fail if this assumption is wrong?
+   - Priority = Impact − Confidence (higher = test first)
+4. **Validate completeness** — Ensure at least one assumption per category. If a category is empty, re-read the brief looking specifically for that type.
+5. Output a ranked list with recommended validation methods
+
+## Output Structure
+
+### Assumption Map: [Feature/Product Name]
+
+| Assumption | Category | Confidence | Impact | Priority | Validation Method |
+|------------|----------|------------|--------|----------|-------------------|
+| [assumption] | [type] | [1-5] | [1-5] | [score] | [method] |
+
+#### Critical Assumptions (Impact 4+ and Confidence 2 or below)
+[Flagged items with detailed validation recommendations]
+
+#### Top 3 Assumptions to Validate First
+[Detailed recommendations including specific research method, estimated effort, and what the result would change]
+
+## Example (Partial)
+
+Input: *"We're building a self-serve onboarding flow to reduce time-to-value for SMB customers."*
+
+| Assumption | Category | Confidence | Impact | Priority | Validation Method |
+|------------|----------|------------|--------|----------|-------------------|
+| SMB users can complete onboarding without human help | Usability | 2 | 5 | 3 | Unmoderated usability test (n=8) |
+| Faster onboarding correlates with higher retention | Viability | 3 | 4 | 1 | Cohort analysis of current onboarding times vs. 90-day retention |
+| The current onboarding is the primary reason for slow time-to-value | Desirability | 2 | 4 | 2 | User interviews with recent churned SMB accounts |
+
+## Anti-Patterns
+
+- [ ] Do not only surface desirability assumptions — feasibility and viability assumptions are equally likely to kill a product and are often overlooked
+- [ ] Do not assign high confidence to an assumption just because it hasn't been challenged yet — absence of evidence is not evidence
+- [ ] Do not recommend "user interviews" as the validation method for every assumption — some assumptions require quantitative data, competitive analysis, or technical spikes
+- [ ] Do not list assumptions that cannot be tested — every assumption in the map must have a plausible validation method, or it should be flagged as unknowable and treated as a risk
+
+## Quality Checks
+
+- [ ] At least one assumption per category (Desirability, Feasibility, Viability, Usability)
+- [ ] All Impact 4+ / Confidence 2− assumptions flagged as CRITICAL
+- [ ] Each validation method is specific (not just "do research" — name the method and sample size)
+- [ ] Priority scores are consistent (Impact − Confidence, higher = more urgent)

exports/aider/pm-discovery/customer-journey-map/customer-journey-map.md

@@ -0,0 +1,218 @@
+# Customer Journey Map Skill
+
+This skill produces a complete customer journey map covering every stage from awareness through advocacy. Each stage includes touchpoints, customer actions, emotions, pain points, and specific improvement opportunities. Output is ready for use in product discovery, UX design, or cross-functional alignment workshops.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Product or service** being mapped
+- **Customer persona** — which customer segment is this map for? (be specific — one persona per map)
+- **Journey scope** — full end-to-end (awareness → advocacy), or a specific phase (e.g. onboarding only)?
+- **Current state or future state?** — mapping how it works today, or designing how it should work?
+- **Data sources** — any research, user interviews, support tickets, NPS comments, analytics available?
+- **Goal of the map** — what decision will this inform? (redesign, prioritisation, stakeholder alignment, new feature)
+
+## Output Structure
+
+---
+
+# Customer Journey Map: [Product / Service]
+
+**Persona:** [Name — e.g. "Sarah, the overwhelmed HR manager"]
+**Journey scope:** [Full end-to-end / Onboarding / Purchase / Renewal]
+**Current or future state:** [Current state / Desired future state]
+**Prepared by:** [Name / Team]
+**Date:** [Date]
+**Based on:** [Research sources — interviews, analytics, support data, assumed/hypothetical]
+
+---
+
+## Persona Summary
+
+| | |
+|---|---|
+| **Name** | [Sarah] |
+| **Role** | [HR Manager at a 200-person professional services firm] |
+| **Goal** | [Reduce time spent on manual employee data management] |
+| **Frustrations** | [Too many tools that don't talk to each other; always chasing approvals] |
+| **Tech comfort** | [Moderate — comfortable with SaaS tools but not a power user] |
+| **Decision power** | [Recommends tools; budget approved by CHRO] |
+
+---
+
+## Journey Overview
+
+```
+AWARENESS → CONSIDERATION → DECISION → ONBOARDING → ADOPTION → ADVOCACY
+   [Stage 1]      [Stage 2]      [Stage 3]    [Stage 4]     [Stage 5]   [Stage 6]
+```
+
+**Overall experience rating (current state):** [😤 Frustrating / 😐 Neutral / 😊 Positive]
+
+---
+
+## Stage 1: Awareness
+
+*How does the customer first discover the product exists?*
+
+**Customer goal at this stage:** [e.g. Realise they have a problem worth solving — or find a solution to a specific pain]
+
+| Element | Detail |
+|---|---|
+| **Trigger** | [What event makes them start looking? — e.g. Manual process breaks down / peer recommendation / saw ad] |
+| **Where they are** | [Google search / LinkedIn / conference / colleague conversation / email newsletter] |
+| **What they do** | [e.g. Searches "automate employee onboarding" / asks peers in HR community / clicks LinkedIn ad] |
+| **Emotion** | [😤 Frustrated — overwhelmed by manual processes and hoping for a better way] |
+| **Pain points** | [Overwhelming number of options / hard to know which tools are credible / can't tell what's B2B vs B2C from homepage] |
+| **Opportunities** | [SEO content targeting the trigger keyword / LinkedIn thought leadership / peer community presence] |
+
+---
+
+## Stage 2: Consideration
+
+*The customer is actively evaluating options. What do they do to decide?*
+
+| Element | Detail |
+|---|---|
+| **Customer goal** | [Narrow down from many options to a shortlist of 2–3] |
+| **What they do** | [Reads G2/Capterra reviews / watches demo video / downloads comparison guide / asks peers who use something similar] |
+| **Touchpoints** | [Website / review sites / social proof / demo request flow / sales email] |
+| **Emotion** | [😕 Anxious — worried about making the wrong choice; past tool purchases haven't delivered] |
+| **Pain points** | [Pricing not visible on website / demo requires a call before seeing the product / unclear if it works with their existing stack] |
+| **Opportunities** | [Self-serve demo or interactive product tour / transparent pricing page / ROI calculator / case studies from similar company size] |
+
+---
+
+## Stage 3: Decision
+
+*The customer is ready to buy — or not. What makes them commit?*
+
+| Element | Detail |
+|---|---|
+| **Customer goal** | [Get sign-off from CHRO and justify the decision with a business case] |
+| **What they do** | [Books sales call / requests security questionnaire / builds internal business case / negotiates contract] |
+| **Touchpoints** | [AE / sales call / security review / contract / procurement process] |
+| **Emotion** | [😬 Cautious — doesn't want to be wrong; presenting to leadership adds pressure] |
+| **Pain points** | [Sales process is slow / security questionnaire takes weeks / contract terms are non-standard and require legal] |
+| **Opportunities** | [Security FAQ self-serve / standard contract with predictable terms / champion toolkit (slides, business case template) to help them sell internally] |
+
+---
+
+## Stage 4: Onboarding
+
+*The customer has bought. Now they need to get value fast.*
+
+| Element | Detail |
+|---|---|
+| **Customer goal** | [Get the product working and show their CHRO it was a good decision] |
+| **What they do** | [Receives welcome email / attends kickoff call / configures integrations / invites team] |
+| **Touchpoints** | [Onboarding email sequence / in-product onboarding checklist / CSM / help centre / integrations marketplace] |
+| **Emotion** | [😬 Anxious but hopeful — excited about potential but stressed about the setup work] |
+| **Pain points** | [Setup is more complex than expected / IT required for SSO but IT is slow to respond / generic onboarding doesn't match their use case] |
+| **Opportunities** | [Role-specific onboarding paths / IT connector with pre-filled request template / quick win email at day 3 (show them one thing that already works)] |
+
+**Key moment of truth:** [What single moment in this stage determines whether they'll become an active user or ghost? — e.g. "First time the product saves them 30 minutes on a task they used to do manually"]
+
+---
+
+## Stage 5: Adoption
+
+*The customer is using the product. Are they getting consistent value?*
+
+| Element | Detail |
+|---|---|
+| **Customer goal** | [Make the product a regular part of their workflow; demonstrate ROI to leadership] |
+| **What they do** | [Uses core features daily / discovers new features / hits a limitation / contacts support / attends webinar] |
+| **Touchpoints** | [Product UI / in-app notifications / email / support / community / customer success manager] |
+| **Emotion** | [Variable — some days 😊 when the product works well; some days 😤 when hitting a gap or bug] |
+| **Pain points** | [Feature they expected isn't there / reporting doesn't show the metric leadership wants / power features are too complex / feels like they're underutilising what they're paying for] |
+| **Opportunities** | [Proactive CSM check-in at day 30 / in-product feature discovery / usage dashboard for the customer to see their own ROI / community for peer learning] |
+
+**Adoption health indicators:**
+- [DAU/MAU ratio — what does healthy look like?]
+- [Feature X used by Y% of seats within Z weeks]
+- [First NPS survey at 60 days — target score]
+
+---
+
+## Stage 6: Advocacy
+
+*The customer loves the product. How do you turn them into a referral engine?*
+
+| Element | Detail |
+|---|---|
+| **Customer goal** | [Solve problems faster; feel like an expert; feel valued as a customer] |
+| **What they do** | [Refers a peer / writes a G2 review / participates in case study / speaks at event / becomes a power user / joins community] |
+| **Touchpoints** | [CSM / community / review request email / referral programme / case study outreach / conference sponsorship] |
+| **Emotion** | [😊 Proud — the tool is part of their professional identity; they feel smart for choosing it] |
+| **Pain points** | [Referral programme is clunky / no structured way to connect with peers / case study process is slow and effortful for them] |
+| **Opportunities** | [One-click G2 review request at high-satisfaction moment / peer community / referral programme with meaningful reward / case study process that does most of the work for them] |
+
+---
+
+## Emotion Curve
+
+Plot the customer's emotional experience across the journey:
+
+```
+High  😊 │        *                              *          *
+          │                                   *
+Neutral 😐│  *         *
+          │                  *
+Low   😤 │                        *    *
+          └────────────────────────────────────────────────────
+            Aware   Consider  Decide  Onboard  Adopt   Advocate
+```
+
+**Lowest point:** [Which stage has the worst experience — and why?]
+**Highest point:** [When is the customer most delighted — what drove it?]
+**Biggest drop:** [Where does sentiment fall most sharply — this is usually the biggest opportunity]
+
+---
+
+## Prioritised Opportunities
+
+| Opportunity | Stage | Impact on customer | Effort to fix | Priority |
+|---|---|---|---|---|
+| [Self-serve product tour before sales call] | Consideration | [High — removes top buying barrier] | [Medium] | P1 |
+| [Quick win email at day 3] | Onboarding | [High — builds early habit] | [Low] | P1 |
+| [IT SSO setup template] | Onboarding | [Medium — removes specific blocker] | [Low] | P2 |
+| [30-day proactive CSM check-in] | Adoption | [Medium — catches churn signals early] | [Medium] | P2 |
+| [Peer referral programme] | Advocacy | [High for growth — reduces CAC] | [High] | P3 |
+
+---
+
+## What We Don't Know (Research Gaps)
+
+| Gap | How to close it | Priority |
+|---|---|---|
+| [What actually triggers the decision to start looking?] | [5 JTBD interviews with recent buyers] | [High] |
+| [What causes customers to stall in onboarding?] | [Drop-off analysis in onboarding funnel + 3 interviews with churned customers] | [High] |
+| [What % of customers have reached the advocacy stage?] | [Product analytics — identify power users; NPS by cohort] | [Medium] |
+
+---
+
+## Quality Checks
+
+- [ ] Map covers one specific persona — not "all customers"
+- [ ] Each stage includes the customer's emotional state — not just actions
+- [ ] Pain points are the customer's pain — not the company's pain
+- [ ] Opportunities are specific enough to become backlog items or design prompts
+- [ ] Emotion curve shows the real experience — not an aspirationally positive version
+- [ ] Research gaps are documented — the map reflects what is known, not assumed
+
+## Anti-Patterns
+
+- [ ] Do not build the map from assumptions alone — ground at least the pain points in real customer data or research
+- [ ] Do not treat all journey stages as equally weighted — identify the highest-friction moments explicitly
+- [ ] Do not omit the emotional layer — a journey map without emotions is a process flow, not a customer map
+- [ ] Do not create generic touchpoints that apply to any product — each touchpoint must be specific to this product and customer
+- [ ] Do not leave opportunities unranked — prioritise by impact and feasibility
+
+## Example Trigger Phrases
+
+- "Map the customer journey for [product]"
+- "Build a user journey from awareness to advocacy"
+- "Create a journey map for our onboarding experience"
+- "Map out the touchpoints and pain points for [customer type]"
+- "Design an experience map for [process or product]"

exports/aider/pm-discovery/discovery-interview-guide/discovery-interview-guide.md

@@ -0,0 +1,110 @@
+# Discovery Interview Guide Skill
+
+Design interviews that surface genuine insight — not validation of what you already believe. Every guide follows a story-based, past-behaviour-focused structure.
+
+## Core Principles
+
+1. **Never ask about the future.** "Would you use X?" tells you nothing. "Tell me about the last time you did X" tells you everything.
+2. **Interview for behaviour, not opinion.** Opinions are cheap. Behaviour is evidence.
+3. **The 5 Whys.** Every surface answer is a door. Keep opening doors.
+4. **Confirm the problem before exploring the solution.** Never show a prototype until you've confirmed the pain exists unprompted.
+
+## Interview Structure (60 minutes standard)
+
+### 1. Warm-Up (5 min)
+Build rapport. Get them talking. Don't discuss the topic yet.
+- "Tell me a bit about your role and what a typical week looks like for you."
+- "What tools do you rely on most day-to-day?"
+
+### 2. Context Setting (10 min)
+Understand their world before diving into the problem space.
+- "Walk me through how you currently [handle the domain area]."
+- "What does that process look like from start to finish?"
+- "Who else is involved when you do this?"
+
+### 3. Problem Exploration (25 min) — THE CORE
+Surface pain without leading.
+- "Tell me about the last time you had to [relevant task]. What happened?"
+- "What was the hardest part of that?"
+- "How did you handle it?"
+- "What did you try before settling on that approach?"
+- "What does it cost you when this goes wrong?" (time, money, stress, reputation)
+- "If you could wave a magic wand and change one thing about this process, what would it be?"
+
+⚠️ **Do not mention your product or feature during this phase.**
+
+### 4. Current Solutions (10 min)
+Understand the competitive landscape from their perspective.
+- "What tools or workarounds do you use today for this?"
+- "What do you like about [current solution]? What frustrates you?"
+- "Have you tried other approaches? What happened?"
+
+### 5. Wrap-Up (10 min)
+- "Is there anything about this topic we haven't covered that you think I should know?"
+- "Is there anyone else you'd recommend I speak to?"
+- "Would you be open to a follow-up if I have more questions?"
+
+---
+
+## Output Format
+
+### Discovery Interview Guide — [Topic] — [Date]
+
+**Research Goal:** [One sentence: what decision will this research inform?]
+**Target Participant Profile:** [Role, company size, behaviour qualifier]
+
+**Screener Questions** (for recruiting):
+1. [Question] → Must answer: [Y/N or specific]
+2. [Question] → Must answer: [Y/N or specific]
+3. [Disqualifier question] → Disqualify if: [answer]
+
+**Interview Guide:**
+
+[Full structured guide using the format above, customised to the specific research topic]
+
+**Synthesis Template** (fill after each interview):
+- Key quote: "[verbatim]"
+- Core pain: [1 sentence]
+- Current workaround: [what they're doing today]
+- Intensity (1–5): [how painful is this?]
+- Surprise/unexpected finding: [anything that challenged your assumptions]
+
+**Pattern Detection** (after 5+ interviews):
+- Pain mentioned by [X/N] participants: [theme]
+- Workaround used by [X/N] participants: [theme]
+- Most emotionally charged moment in interviews: [observation]
+
+---
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Research topic or question** (what decision will this inform?)
+- **Target participant profile** (role, behaviour, company type)
+- **Session length** (30 / 45 / 60 / 90 minutes)
+- **Number of interviews planned**
+- **Known hypotheses to test or avoid confirming prematurely** (optional)
+
+## Quality Checks
+
+- [ ] No future-tense questions ("would you...") — only past-behaviour questions
+- [ ] Product or solution not mentioned until after pain is confirmed
+- [ ] Questions open-ended (cannot be answered yes/no)
+- [ ] Synthesis template included for per-session notes
+- [ ] Screener questions identify and disqualify wrong participants
+
+## Guidelines
+
+- Recommend 5–8 interviews to reach thematic saturation for most discovery questions
+- Always record with permission — transcripts beat notes
+- If user is new to interviewing: remind them to stay silent after asking a question (aim for 80/20 participant-to-interviewer talking ratio)
+- Never synthesise during the interview — do it after, when you can look across sessions
+- Flag confirmation bias: if user writes questions that lead toward a predetermined answer, rewrite them as open-ended alternatives
+
+## Anti-Patterns
+
+- [ ] Do not use future-tense questions ("Would you use this?") — hypothetical responses do not predict real behaviour and produce false confidence in an idea
+- [ ] Do not mention your product or solution before problem exploration is complete — doing so anchors the participant's responses and invalidates the discovery
+- [ ] Do not synthesise across fewer than 5 interviews — themes from 2–3 interviews reflect anecdote, not pattern; wait for saturation
+- [ ] Do not write screener questions that are too easy to pass — if participants can guess the "right" answer, you will recruit the wrong people
+- [ ] Do not treat participant opinions as evidence of future behaviour — what people say they will do consistently diverges from what they actually do

exports/aider/pm-discovery/job-story-mapper/job-story-mapper.md

@@ -0,0 +1,133 @@
+# Job Story Mapper Skill
+
+Stop writing features. Start understanding jobs. This skill translates product requirements and user interviews into precise job stories that keep the team focused on outcomes — not outputs.
+
+## Jobs-to-be-Done Fundamentals
+
+A "job" is the progress a customer is trying to make in a given situation. People don't buy products — they hire them to get a job done.
+
+Three dimensions of every job:
+- **Functional job:** The practical task ("get from A to B")
+- **Emotional job:** How they want to feel ("feel confident I made the right choice")
+- **Social job:** How they want to be perceived ("look like a competent professional to my team")
+
+Great products address all three. Most roadmaps only address the functional one.
+
+---
+
+## Job Story Format
+
+**Template:**
+> When [situation/trigger], I want to [motivation/goal], so I can [expected outcome].
+
+**Not a user story:**
+User stories focus on roles and features: "As a [role] I want [feature] so that [benefit]."
+Job stories focus on situations and motivations: "When [I'm in this specific situation] I want [this capability] so I can [achieve this outcome]."
+
+**The situation is the most important part.** "When I'm in the middle of a sprint and my PM asks for an update" is a much richer trigger than "As a developer."
+
+---
+
+## Mapping Process
+
+### Step 1: Identify the main job
+One sentence: What is the core job your product is hired for?
+> "Help [user type] [accomplish outcome] when [context]."
+
+### Step 2: Break into job steps
+What are all the sub-tasks within the main job?
+(Use a job map: Define → Locate → Prepare → Confirm → Execute → Monitor → Modify → Conclude)
+
+### Step 3: Identify pain points per step
+Where does the job fall down today? Where do customers use workarounds?
+
+### Step 4: Write job stories for each pain point
+One job story per distinct situation-motivation pair.
+
+### Step 5: Map to product opportunities
+Which job stories are underserved? Which have existing solutions? Where is your differentiation?
+
+---
+
+## Output Format
+
+### Job Story Map — [Product/Feature Area] — [Date]
+
+**Core Job Statement:**
+> When [context], [user type] wants to [main job outcome], so they can [ultimate goal].
+
+---
+
+**Job Map:**
+
+| Step | Sub-Job | Current Solution | Pain Points | Underserved? |
+|---|---|---|---|---|
+| Define | [What user does] | [Tool/method used] | [Frustration] | H/M/L |
+| Locate | | | | |
+| Prepare | | | | |
+| Confirm | | | | |
+| Execute | | | | |
+| Monitor | | | | |
+| Modify | | | | |
+| Conclude | | | | |
+
+---
+
+**Job Stories (prioritised by underservice):**
+
+**Job Story 1 — [Situation label]**
+> When [specific situation], I want to [motivation], so I can [outcome].
+
+Functional dimension: [What they need to get done]
+Emotional dimension: [How they want to feel]
+Social dimension: [How they want to be perceived]
+
+Current workaround: [What they do today]
+Pain intensity: [High / Medium / Low]
+Frequency: [How often this situation occurs]
+Product opportunity: [What we could build to address this]
+
+---
+
+Repeat for each major job story.
+
+**Opportunity Scoring:**
+Rate each job story on:
+- Importance to customer (1–10)
+- Satisfaction with current solution (1–10)
+- Opportunity score = Importance + max(Importance – Satisfaction, 0)
+- Prioritise: Opportunity score > 10
+
+---
+
+## Quality Checks
+
+- [ ] Job stories use the "When / I want to / So I can" format (not user story format)
+- [ ] Situation is specific (not "as a user" — a real moment or trigger)
+- [ ] All three dimensions covered: functional, emotional, social
+- [ ] Opportunity score calculated for each job story
+- [ ] Current workaround identified for each high-opportunity story
+- [ ] Product opportunity is distinct from "build the feature" (it's an outcome)
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Product or feature area** to map (e.g. onboarding, checkout, dashboard)
+- **User type or persona** (who are we mapping jobs for?)
+- **Source material** (user interview notes, support tickets, discovery findings, or describe from memory)
+- **Scope** (full product job map vs. a single feature area)
+
+## Anti-Patterns
+
+- [ ] Do not write job stories that describe a feature rather than a situation-motivation pair
+- [ ] Do not skip the social and emotional dimensions — mapping only functional jobs misses the most defensible differentiation opportunities
+- [ ] Do not define situations too broadly ("as a user who wants to manage their work") — the situation must be a specific moment or trigger
+- [ ] Do not conflate opportunity scoring with priority — a high opportunity score still requires feasibility and strategic fit assessment
+- [ ] Do not produce a job map without identifying current workarounds — the workaround reveals what the job is worth to the customer
+
+## Guidelines
+
+- Never write a job story for a feature — write it for the situation that makes the feature valuable
+- If you can't identify the situation, you don't understand the job yet — go back to user research
+- Social and emotional jobs are harder to surface but often the most defensible differentiators
+- Recommend sharing job stories with engineering — they make better technical decisions when they understand the "why"

exports/aider/pm-discovery/user-interview-synthesis/user-interview-synthesis.md

@@ -0,0 +1,55 @@
+# User Interview Synthesis Skill
+
+Transform raw interview transcripts into a structured synthesis document that surfaces themes, pain points, and actionable insights.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Interview transcripts or notes** (even rough notes work)
+- **Number of participants and their profiles** (role, company size, context)
+- **Research questions** (what was the study trying to answer?)
+- **Date range** of research (for context)
+
+## Process
+1. Read all provided transcripts fully before drawing conclusions
+2. Identify recurring themes (minimum 3 mentions to qualify as a theme)
+3. Categorize findings into: Pain Points, Workflow Insights, Feature Requests, Delight Moments
+4. Select 2-3 verbatim quotes per theme that best represent the pattern
+5. Draft "So What" implications for each theme — what does this mean for the product?
+6. **Validate** — Confirm every theme has quotes from at least 3 participants. Flag any insight resting on fewer as low-confidence.
+
+## Output Structure
+
+### Research Synthesis: [Study Name]
+**Participants:** [n]
+**Date Range:** [dates]
+**Research Questions:** [list]
+
+#### Theme 1: [Theme Name]
+- Summary (2-3 sentences)
+- Supporting quotes (from at least 3 participants)
+- Implication for product
+
+[Repeat for each theme]
+
+#### Low-Confidence Signals (1-2 participants only)
+[Findings worth tracking but not acting on yet — note what further research would confirm or deny]
+
+#### Recommended Next Steps
+[Specific, actionable recommendations based on findings]
+
+## Quality Checks
+
+- [ ] Every theme is supported by quotes from at least 3 participants
+- [ ] Implications connect to specific product decisions, not just observations
+- [ ] Researcher bias check: no leading language, findings don't all support one hypothesis
+- [ ] Single-source signals are flagged separately, not mixed into main themes
+- [ ] Research questions from the study brief are each addressed (even if the answer is "inconclusive")
+
+## Anti-Patterns
+
+- [ ] Do not mix single-source signals into main themes — insights cited by only one participant must be flagged separately
+- [ ] Do not write implications that are observations restated rather than product decisions enabled
+- [ ] Do not include themes that only support the project hypothesis — contradictory findings must be surfaced, not omitted
+- [ ] Do not present findings without quotes — every theme requires verbatim evidence from at least 3 participants
+- [ ] Do not leave research questions unanswered — each question from the study brief must be explicitly addressed, even if the answer is inconclusive