Transcript Analysis

This reference file guides the end-to-end workflow after a founder has conducted a customer discovery interview and wants to analyze it: extract statements, link them to existing hypotheses, evaluate hypothesis state, and review interview technique.

It is loaded by the interviews skill when the founder has a transcript, paste, or recollection to analyze. It is not a skill and should not be invoked independently.

---

Context

You already have:

• startup/core.md — the project definition
• startup/hypotheses/*.md — existing testable hypotheses
• Optionally startup/interview-scripts/*.md — scripts the founder may have used

You are about to acquire a transcript (or recollection) and turn it into:

• startup/interviews/transcripts/{slug}.md — raw source material
• startup/interviews/{slug}.md — analysis file with statements, backlinks, and technique feedback
• Zero or more hypothesis state updates routed through the existing hypotheses skill
• Zero or more new hypothesis files, also routed through the existing hypotheses skill

Goal

Close the loop on a single interview: persist what was said, tie it to what was assumed, update state where evidence warrants, and give the founder honest feedback on how they ran the conversation.

---

Single most important rule

Two subagents do the heavy work; you orchestrate and mediate. You do not extract statements yourself. You do not evaluate hypothesis state yourself. You do not edit hypothesis files directly. Your job is to route transcripts to interview-analyst, route results to hypotheses-manager, summarize recommendations to the founder, and — on confirmation — invoke the hypotheses skill to make the actual file edits.

---

How to run the workflow

Step 1 — Identify the input branch

Determine which branch applies and act accordingly.

Branch A — file in designated location. Founder says something like "the transcript is at startup/interviews/transcripts/2026-04-12-jane.md" or "I saved it in the usual place." Read the file to confirm it exists and has frontmatter with at minimum date, interviewee, persona, source. If frontmatter is missing or incomplete, propose adding it and edit the file — see the persona intake question below if persona is missing.

Branch B — pasted into chat. Founder pastes the transcript text. Before analyzing:

1. Propose a slug following the convention: {date}-{short-descriptor} (e.g., 2026-04-12-jane-freelance-designer). Use date: today and a short descriptor from what the founder tells you about the interviewee.
2. Ask the founder to confirm the slug, date, and interviewee descriptor.
3. Ask the persona intake question (see below).
4. Write the transcript to startup/interviews/transcripts/{slug}.md with this frontmatter:

---
date: YYYY-MM-DD
interviewee: {name or anonymized handle}
persona: {one-line descriptor from the founder's answer}
script: {script-slug if known, otherwise omit}
source: pasted
---

{the pasted text, verbatim}

5. Briefly mention the convention without being preachy: "Saved to startup/interviews/transcripts/{slug}.md — keeping transcripts here lets us re-read them later and sharpens future hypothesis assessments."

Branch C — recollection. Founder describes a conversation from memory (e.g., "I talked to someone at a coffee shop"). Treat this as paste, with two differences:

1. Let the founder dump everything they remember first — ask once "anything else you want to capture before I write this down?" to prompt recall.
2. Ask the persona intake question (see below).
3. Write to startup/interviews/transcripts/{slug}.md with source: recollection and the persona field from the founder's answer. The body is the founder's recollection as they told it.

Note that technique feedback may be limited or omitted by the interview-analyst when source: recollection — the founder's own questions may not be captured. Mention this lightly if relevant.

Persona intake question (all branches):

Ask a single question to capture who the interviewee actually is — the analyst needs this to frame the analysis. Adapt wording, but aim for something like:

"Quick context on who you talked to — a line or two. Role, relationship to your target audience, how you met, anything that'll help sharpen the analysis."

The answer becomes the persona field on the transcript frontmatter. Aim for a rich one-liner (e.g., "Freelance designer, US, 5+ years solo, invoices ~8 clients monthly — met through Designers Guild Slack") rather than a bare role descriptor. If the founder used a script, mention that the script's target_persona is what was being targeted; the transcript's persona captures who they actually talked to (which may differ, and that's valuable signal).

If the founder genuinely has nothing to add beyond what's in the transcript, note persona: {best reasonable descriptor from transcript} and move on — don't belabor it.

Always scaffold the directory if it doesn't exist:

mkdir -p startup/interviews/transcripts

Step 2 — Dispatch the interview-analyst

Dispatch the interview-analyst subagent with:

• transcript_path: the path you just wrote (or confirmed) under startup/interviews/transcripts/
• slug: the shared slug (same as the transcript filename, without extension)
• script_path: path to the interview script under startup/interview-scripts/ if one was used; omit otherwise

The subagent reads the transcript, core.md, hypotheses, the script, and any existing interview analysis files. It writes startup/interviews/{slug}.md and returns a short structured summary: which hypothesis slugs were linked, how many statements were unlinked, and technique feedback highlights.

Wait for the subagent to return before proceeding.

Step 3 — Dispatch the hypotheses-manager

Dispatch the hypotheses-manager subagent with:

• slugs: the list of hypothesis slugs the interview-analyst linked in this interview
• scope: include instruction to also synthesize candidate new hypotheses from unlinked statements across all interviews (relevant because this interview's unlinked statements may be the one that tips a pre-existing cluster over the threshold)

The subagent greps for each linked slug across startup/interviews/*.md, re-reads statements in context, and returns state recommendations — each with a What changed line, reasoning, evidence pointers, and a Next action — plus a single cross-hypothesis Top pick. It also scans unlinked statements across all interview files for cross-interview patterns.

Wait for the subagent to return before proceeding.

Before summarizing, do the eager bookkeeping the hypotheses skill defines: for each evaluated hypothesis, write its last_assessed to today and overwrite its ## Next Action section with the subagent's suggested next action. This is advisory and needs no per-item confirmation; route the edits through the hypotheses skill conventions (read before writing, touch only frontmatter and the ## Next Action section).

Step 4 — Summarize to the founder

Write a single conversational message summarizing everything for the founder. Lead each touched hypothesis with what changed → the next action — not just a status. This is the point of the whole loop: the founder should walk away knowing the next small, observable move, not just an updated label. Follow this shape, adapting tone to the content:

"Interview with {interviewee} is analyzed and saved to startup/interviews/{slug}.md.

What this interview moved:

• {slug-1} — {what changed: weaker/stronger/no change} → next: {next action} ({recommended status if a change is proposed})
• {slug-2} — {what changed} → next: {next action} ({recommended status if a change is proposed})

Sharpest move right now: {the Top pick — {slug} and the one-line why}.

Candidate new hypotheses (if any): {proposed title} — {cluster size} — {reasoning}.

Technique feedback: {1–3 highlight bullets from the analysis file}.

Want to act on any of the state recommendations or candidates? You can also refine any of them before we make changes."

Do not act on status recommendations yet. The founder drives state changes; you never flip a hypothesis status or create a new hypothesis file without explicit confirmation of that specific change. (The ## Next Action sections and last_assessed, written in the eager bookkeeping step above, are the exception — they are advisory and already persisted.)

Step 5 — Route confirmed changes through the hypotheses skill

For each change the founder confirms, invoke the hypotheses skill to make the edit. The hypotheses skill already handles:

• Reading the hypothesis file, proposing the change, writing back — for status updates
• The full new-hypothesis file creation conventions — frontmatter, tag, slug rules — for new hypotheses

Do not bypass the skill. Route every hypothesis-file edit through it so conventions stay centralized.

Before making each edit, show the founder exactly what will change and get explicit confirmation. Read before writing.

Step 6 — Confirm and close

After edits are complete, confirm briefly:

"Done. Analysis file at startup/interviews/{slug}.md. Updated {N} hypotheses, created {M} new ones."

Mention natural next steps without pushing:

• Run more interviews — a few more in the same persona often changes the picture
• Revisit the script — if technique feedback surfaced specific things to adjust
• Check overall project direction — if state changes were meaningful, the whats-next skill can reassess

Let the founder decide.

Invite feedback (first time only). Turning a raw transcript into linked, analyzed evidence is one of the tool's strongest moments. As the final beat of the close, follow the Layer 0 Feedback invites protocol for stage first-interview-analyzed: read startup/.superpowers/feedback.md, and unless the founder opted out, the tag is already recorded, or FORM_ID is still the placeholder, emit the invite tying it to the analysis they just got, then append the ledger line.

---

Style guidelines

• One question at a time when gathering missing information from the founder (slug confirmation, branch disambiguation, specific edits to confirm).
• Propose before writing — this applies to every file you touch: the transcript, hypothesis edits, new hypothesis files. Show the founder what goes in first.
• Do not edit hypothesis files directly. Always route through the hypotheses skill.
• Do not evaluate hypothesis state yourself. Always dispatch the hypotheses-manager.
• Do not extract statements yourself. Always dispatch the interview-analyst.
• Keep subagent results in the subagent output. Don't paraphrase the analysis file back into chat — point the founder to the file and highlight the few things worth discussing.

---

Completion criteria

• Transcript saved at startup/interviews/transcripts/{slug}.md with frontmatter
• Analysis file written at startup/interviews/{slug}.md by the interview-analyst
• Hypothesis state recommendations surfaced to the founder
• Any confirmed state changes or new hypotheses routed through the hypotheses skill
• Founder has seen the technique feedback summary

---

What comes next

After a handful of interviews are analyzed this way, natural directions are:

• Cross-interview review — ask the hypotheses-manager to reassess all hypotheses at once (standalone, no new interview needed) to see the aggregate picture
• Project-level reassessment — invoke the whats-next skill; its lean-startup-advisor can now evaluate against interview evidence
• Script iteration — revise the interview script based on technique feedback patterns across interviews

Mention these as available directions, but don't push — let the founder decide.