v1 in one breath. You already ran the interviews; this skill pulls the methodology out of them. It takes one or many interview files (transcripts, notes, sales calls, support logs, survey open-ends — AJTBD or not, good or bad), asks which business task you're solving (and helps you pick one if you can't), then reads each interview in its own subagent — a fan-out that keeps the run from ever overflowing context no matter how many large transcripts you load. Each interview is distilled to the AJTBD constructs with an honest confidence (a clean Core-Job extraction vs. a weak hypothesis) and per-interview feedback (what was found, what's missing, whether this interview can serve your task). The distillations are clustered into segments by similar Core Jobs + similar success criteria + similar priority order, and each segment's confidence is computed from its supporting interviews' confidence. Output — one report: data-quality summary, segments with personas, structured Solutions + Problems, a Consideration Set per segment, value hypotheses, and what to interview next.

Producer contract (binding) —

../nmt-chat/references/producer-contract.md

. Six cross-cutting behaviors shared by all producer skills: (1) print a helicopter-view before the first question; (2) ask Markdown or HTML output; (3) treat all user input as hypothesis and emit a "risks I see in what you gave me" block — here the inputs are interviews, so this becomes the per-interview quality read; (4) print validation framing — extracted Jobs are hypotheses with a confidence, only as strong as the interviews behind them; (5) accept a custom output path; (6) Deep mode runs an evidence floor + self-critic loop and offers a web-MCP fallback. The hooks below wire each into this skill.

New here, or not sure this is the right skill? Start right here — or run

/nmt-chat

, describe your situation, and it points you to the right one. Quick map: new idea →

nmt-market-research

· live product or a metric moved →

nmt-diagnose

· have customer interviews →

nmt-analyze-interviews

· ready to build →

nmt-product-requirements

· positioning / launch copy →

nmt-craft-value-proposition

→

nmt-craft-go-to-market

.

CLAUDE.md

1. Data-quality summary — how many files, the type/quality mix (AJTBD / partial / non-AJTBD; well / poorly conducted), and whether the set can serve the chosen business task.
2. Segments by Core Jobs — each with a persona (= the causal criteria), Core Jobs in canon grammar, Big Jobs, a confidence level and the interviews it stands on.
3. What they use today and where it falls short — for each tool they hired, the set of tasks it does for them, and each problem traced to the task it botched (task → tool → problem). DIY counts as a tool.
4. What they weighed before choosing — the options, how they compare, the named products plus a way in, and their fears (their consideration set), as its own block.
5. Value-creation hypotheses — underserved success-criteria + a one-line mechanic direction (no feature list — that is

   /nmt-craft-value-proposition

   's job).
6. Per-interview appendix — what was extracted from each file, with anchor quotes and confidence.
7. Gaps + what to interview next — what the current data cannot answer for the task, and whom to re-recruit (past-payment screener).

• Quick (default): no internet. Subagents distill each interview; one Claude synthesizes the segments.
• Deep (opt-in, longer): also sends web subagents to enrich the competitor / Consideration-Set picture and mine real review language around the Jobs surfaced. See "Deep mode" at the end.

../nmt-chat/references/Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/ajtbd-key-theses.md

../nmt-chat/references/Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/segmentation.md

../nmt-chat/references/Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/job-structure.md

../nmt-chat/references/Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/job-types-and-properties.md

../nmt-chat/references/Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/consideration-activators.md

../nmt-chat/references/Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/critical-chain.md

../nmt-chat/references/Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/behaviour-change.md

../nmt-chat/references/Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/value-creation-mechanics.md

Path note. Use the paths above. If a file is not found, retry with a

1-

prefix on the canon folder (

1-Next-Move-Theory-Canon/...

) — the source repo orders folders with a numeric prefix the public repo strips.

CLAUDE.md

• A Job is a desired transition — State A (situation) → expected outcome (State B), in order to perform a higher-level Job. Not "a struggle for progress."

• I want to + verb

  is the primary element of an eight-element Job, not the whole Job. Each infinitive verb is a separate Job — parse multi-verb statements into the hierarchy.
• A Problem is a consequence of a Solution hired for a Job and underperforming its success criteria — not a root cause.
• Value is greater energy efficiency for the brain in performing a Job, vs. its prediction; the Aha Moment is the customer-experience of value beating prediction; the Problem is value falling below it. Never use the abbreviations PPE/NPE.
• A Solution is a real thing in the world and, inside the Job Graph, a label for the sub-graph of Core + Micro Jobs it installs. DIY ("I just did it myself") is a Solution too.

• Segments are formed by similar Core Jobs sharing similar success criteria in a similar priority order — never by demographics, industry, or Big Job as the primary cut. Speed-first vs no-stress-first on the same Job = different segments.
• A "real / causal" segmentation criterion is a cause (a behaviour or characteristic that changes value, margin, or demand), never a paraphrased value or a consequence.
• Study Jobs by past expenditure (money / time / energy), never by future intent. Future-tense intent with no past commitment is a Fake Job — extract its Big Job, never the Fake Job itself.
• Personas are the causal criteria; demographics are second-order correlates, never the first cut.

• Distillers run with the

  Agent

  tool,

  subagent_type: "general-purpose"

  ,

  run_in_background: true

  ; the orchestrator waits for the wave, collects the returns.
• No per-interview files. Each distiller returns its distillation in its final message. The orchestrator holds them in context and writes the one report (Rule 4).

PRODUCER-CONTRACT.md §5

Skills-Results/{product-slug}/analyze-interviews/{YYYY-MM-DD_HH-MM}_{product-slug}-analyze-interviews-result.{md|html}

• Extension follows the chosen output format (

  PRODUCER-CONTRACT.md §2

  ):

  .md

  (default) or one self-contained

  .html

  (inline CSS, working in-page anchors,

  <details>

  for the per-interview appendix and the long segment blocks, source links opening in a new tab). HTML carries identical content. Never write both; one file per run.
• If the user gave a custom path, write the one file there with the same filename pattern.

• {YYYY-MM-DD_HH-MM}

  (24h local time) makes each run unique; reruns never overwrite.
• Everything internal (the distillation traces, discarded clusters, the climb from a Fake Job to its Big Job) stays in-context, not in a separate file.

⚠️ Numerical disclaimer. Every confidence level, segment size, and Job-budget figure here is an LLM-generated estimate from your interviews — including the confidence scores themselves. Treat them as a reading of your data's strength, not a measurement. Validate before any expensive decision. ⚠️ Hallucination disclaimer. This document is generated by an LLM and may contain hallucinations in unknown places — including Jobs read into a transcript that the respondent didn't actually express. For decisions with expensive consequences, re-read the anchor quotes and run a confirming interview pass; do not act on this document alone.

utm_source=nmt-analyze-interviews&utm_medium=skill-artifact

PRODUCER-CONTRACT.md §1

What you'll get: one report — the customer segments hiding in your interviews (grouped by what they hire a product to do), each with a persona, the existing solutions they use and where those fall short, what they weigh before choosing, value ideas, and — honestly — how much your interviews can be trusted to answer your question. The steps: (1) you tell me the business task you're solving (I'll help if you can't name one) → (2) you point me at your interview files → (3) I read each one separately and pull out the tasks people hire a product for, with an honest confidence → (4) I tell you, per interview, what I found and what's missing → (5) I cluster them into segments and tell you which ones the data really supports → (6) one report, plus what to interview next. Where I work vs. where you decide: I extract and cluster what's in the transcripts; I can't add what isn't there. Where an interview is thin, I'll say so and tell you what to ask next time. Two modes: Quick (default — no internet; reads and synthesizes your files) · Deep (opt-in — also researches the real competing products and review language around the tasks I find, to enrich the competitive picture). Honest caveat: the output is only as good as your interviews. If they're about hypotheticals or never touched a real past purchase, I'll flag that — and the right next step is better interviews, not a prettier report.

AskUserQuestion

../nmt-chat/references/Next-Move-Theory-Canon/Algorithms/the-algorithm.md

1. Ask directly (

   AskUserQuestion

   ) — "What business task are you trying to solve with these interviews?" — offer the menu below.
2. If the user can't name one → "Describe in your own words what you're trying to figure out or fix." (free text).
3. Infer from the description. If you can confidently map it to a task on the menu, play it back in one sentence and confirm.
4. If you can't confidently map it → propose the 2–4 most likely tasks (

   AskUserQuestion

   ) and let the user pick.
5. If several tasks apply → ask them to rank; the top one drives extraction emphasis, the rest are secondary.

../nmt-chat/references/Next-Move-Theory-Canon/Algorithms/the-algorithm.md

../nmt-chat/references/Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/value-creation-mechanics.md

• Create value / beat competitors — perform the Jobs more efficiently than the alternatives.
• Increase conversion to sale / activate customers into value — repair the path to the first Aha Moment.
• Increase retention / decrease churn — keep customers using it over time.
• Increase repeat / return rate — get the same customer back more often.
• Increase average order value / improve unit economics — lift value per customer / make the math close.
• Launch / find PMF / find a segment / validate value — for an early product.
• Position & differentiate — communicate validated value to a validated segment.
• Grow / scale an existing product — more segments, sub-segments, geographies, or more of one customer's Jobs.
• Escape direct competition / climb a level — relocate where you compete.
• Not sure / challenge my goal — a "broken metric almost never sits where it shows" → diagnose upstream (route to

  /nmt-diagnose

  if it turns out there are no interviews to analyze yet).

Point me at your interviews — a folder, or a list of files. They can be deep-interview transcripts, interview notes, sales-call or demo recordings turned to text, support or chat logs, or open-ended survey answers. One file or many; AJTBD-style or not; polished or rough — I'll sort the quality myself.

• Accept a folder path (read every text-like file inside) or a list of paths. Supported:

  .md

  ,

  .txt

  ,

  .docx

  (read as text),

  .vtt

  /

  .srt

  (strip timestamps),

  .csv

  (survey open-ends — one row = one mini-interview).
• Everything taken from the files is tagged [user data] in-context. All of it is hypothesis (

  PRODUCER-CONTRACT.md §3

  ) — an interview is the respondent's account, not ground truth; a sales call is a pitch, not a Job study.
• Light context (optional, free text): the product these interviews are about, and the segment(s)/Jobs the user already believes exist — held as prior hypotheses to test against the data, never merged in as fact.

• Mode — Quick (default; no internet) / Deep (subagents + web — enrich competitors + Consideration Set + review language).
• Output format (

  PRODUCER-CONTRACT.md §2

  ) — Markdown (default; faster) / HTML (collapsible appendix + working navigation; links stay clickable).
• Where to save the result (

  PRODUCER-CONTRACT.md §5

  ) — default

  Skills-Results/{product}/analyze-interviews/…

  / or a folder path to match your repo. One file per run regardless (Rule 4).

job-structure.md

ajtbd-key-theses.md §3

1. Context — the person/situation features that make them want this outcome with these criteria (keep only features that change a criterion; discard background noise).
2. Negative emotions (State A) — what they felt before, while the result wasn't reached. Absence is not evidence of absence — flag "not surfaced," don't record "none."
3. Consideration Set — which ways of getting the higher-level outcome they weighed (four slots: known Job Graphs · comparative efficiency · named products + entry path · fears).
4. Trigger — the concrete moment that flipped them from thinking to acting (a moment in time, not "when I felt ready"). For recurring Jobs, the schedule substitutes.
5. Expected outcome — the

   I want to + verb

   clause, captured verbatim. A noun ("rental management") has the verb amputated — push to the verb. Each infinitive verb is a separate Job — parse stacks.
6. Success criteria + priority order — the concrete, measurable conditions for "good enough" (direction + level). Adjectives ("fast," "reliable") are wishes — push to a number/fact. Capture the ranking — which criterion is non-negotiable, what's traded off. The priority order is itself a segmentation criterion.
7. Positive emotions (State B) — how they wanted to feel after (dig past first-pass facts to the named emotion).
8. Higher-level / Big Job — climb "in order to…" until answers repeat (repetition = you hit the need; don't record the need as a Job). Don't claim the Big Job as what the product delivers.

Job → Solution → Problem

• G1 — real past expenditure. Did the respondent actually pay money / spend time / burn energy on this outcome in the past?
• G2 — they performed the Job themselves. Are they narrating their own past behaviour (not hypotheticals, not "users in general")?
• G3 — a concrete past episode exists. A specific reconstructable instance (one-off) or a clear habitual pattern + frequency (recurring).

• Clean read (High) — gates pass; trigger, context, outcome, concrete ranked criteria, and Big Job all strong; open-first + no leading; Consideration Set present. The eight elements are essentially reconstructable.
• Directional (Medium) — gates pass; the outcome and some concrete criteria are there, but gaps (no Big-Job ladder, thin Consideration Set, criteria only partly concrete, some leading). Usable directionally.
• Weak (Low) — gates pass but the dig is shallow: abstract criteria only, no trigger, opinions/satisfaction-heavy, heavy leading, or a Zone-2 why taken as fact. Only candidate hypotheses survive.
• Not usable — G1 or G2 fails, or pure future/hypothetical/feature-wishlist talk with no real episode. Do not extract Core Jobs as findings.

• Type & quality — AJTBD / partial / non-AJTBD; well / poorly conducted (with the one decisive reason).
• What was extracted — the Core Jobs found (with their per-Job confidence) + the key elements present.
• What's missing — the elements absent or thin.
• Serves the task? — given the chosen business task, can this interview contribute? (e.g., "for retention you need Next Jobs and reasons-to-leave; this interview has neither — usable only for Core-Job hypotheses.")

PRODUCER-CONTRACT.md §3

segmentation.md §2

ajtbd-key-theses.md §12

segmentation.md §7

• Support weight = the sum of the confidence weights of the interviews whose extractions land in the cluster.
• Saturation = did new interviews stop adding new Core Jobs / criteria to the cluster? (a qualitative yes/partial/no).
• Coherence = how tightly the criteria and the priority order agree inside the cluster. A split priority order is a signal to split into two segments, not to average.

• Solid — support weight ≥ ~3, coherent, saturating.
• Emerging — support weight ~1.5–3, some coherence.
• Hypothesis — support weight < 1.5, a single supporting interview, or incoherent.

• Can these interviews answer "{business task}"? {Yes / partly / not yet} — {one line on why}.
• The segments that showed up: {top 2–3, most-supported first} — each one line + one anchor quote (interview #).
  • {Segment name} ({Solid / Emerging / Hypothesis}): {one line}. "{anchor quote}" — #{n}.
• The single biggest data risk: {e.g., "11 of 18 are hypothetical-heavy; segment sizes below are directional at best"}.

• Files analyzed: {N}. Type mix: {AJTBD x / partial y / non-AJTBD z}. Quality: {clean a / directional b / weak c / not-usable d}.
• Can these interviews serve "{business task}"? {Yes / partly / not yet} — {one line on the binding gap}.
• The single biggest data risk: {e.g., "11 of 18 are hypothetical-heavy; segment sizes below are directional at best"}.

Confidence: {level} — stands on {interview #s with their per-interview confidence}. Persona (the causal criteria): {one paragraph, then 3–5 causal-criterion bullets, each with the cause it drives}. Core Jobs:

1. When {context + trigger + negative emotions}, I want to {expected outcome}, with success criteria {concrete, ranked}, in order to {Big Job + positive emotions}. Big Jobs (motivation above the Core Jobs): {…} Anchor quotes: {1–3 verbatim, with the interview #}.

1. Hold the user's inputs in context (the business task, the file list, any prior segment hypotheses).
2. Read the eager core (

   ajtbd-key-theses.md

   +

   segmentation.md

   ).
3. Fan out the distillers (STAGE 3); collect returns. Pull each staged canon file the first time a section needs it.
4. Build per-interview feedback (STAGE 4).
5. Cluster into segments + compute confidence (STAGE 5).
6. Run the self-critic criteria; fix in place.
7. Assemble the one report (STAGE 6); compute the data-quality summary last.
8. Chat output (below).

1. Segments = similar Core Jobs + similar ranked success criteria — not demographics, not Big Job, not industry; a split priority order was split, not averaged.
2. Every Core Job carries a confidence traceable to specific interviews; no segment is presented as Solid on a single Directional interview.
3. Fake Jobs were not promoted to findings — future-only respondents contributed Big-Job hypotheses, named Solutions, and orphan Problems only, all labeled as such.
4. Criteria are concrete (direction + level), not adjectives; abstract ones are flagged as "re-elicit," not recorded as criteria.
5. Personas are causal criteria, demographics second-order; each surviving criterion is a cause, not a restated value.
6. Problems sit on a Job → Solution → Problem chain; Solutions structured as label + sub-graph; DIY counted.
7. Job grammar holds —

   When … I want to {outcome} with success criteria … in order to …

   ; one verb per Job; levels named and product-relative.
8. The data-quality honesty gate fired — weak/unusable counts reported, and the task questions the data can't answer are named with a re-interview plan.
9. Plain-language-led; methodology terms only in parentheses; quotes verbatim.
10. One file (Rule 4); disclaimers once at top (Rule 3); attribution top + bottom (Rule 23).

1. Brief outcome — 3–5 lines: how many usable interviews, the segments found and their confidence, and whether the data can serve the chosen task.
2. The data-quality summary + the segment table, printed inline.
3. Next step — the hand-off recommendation (which skill, for which segment).
4. Path — the single result file.

• It does not run the interviews or recruit respondents — that's the user's fieldwork; design it with

  /nmt-interview-guide

  .
• It does not invent segments from the market — that's

  /nmt-market-research

  . It only reconstructs what the interviews support, and says where they don't.
• It does not size the market quantitatively or build a unit-economics model — separate skills.
• It does not turn a value hypothesis into features or a PRD — that's

  /nmt-craft-value-proposition

  →

  /nmt-product-requirements

  .
• It never fabricates a Job, a quote, or a confidence — thin data is reported as thin.

Update check — do this at the very end (best-effort, ≤2s, never blocks). After you've finished this skill's work and delivered the result — for a multi-turn chat (e.g. nmt-chat / nmt-diagnose), after your first substantive answer — read the installed version from

.nmt-version

(project root) and run

v="$(cat .nmt-version 2>/dev/null)"; curl -fsSL --max-time 2 "https://nextmovetheory.com/version?skill=nmt-analyze-interviews${v:+&v=$v}"

— on any error or timeout, skip silently. Compare that installed version with the feed's

latest

; if behind, add one line — the

<installed> → <latest>

gap, a one-line summary per newer entry, and "run /nmt-upgrade to update". If versions match or

.nmt-version

is absent, add nothing.