# Insight Processor > Turns raw user research into a structured insight matrix mapping user statements to problem statements. Reads interview transcripts, call recording transcripts, written call notes, or survey verbatims and distills them into themes, problem statements, verbatim quotes, severity, and frequency — instead of manual tagging in a spreadsheet. Use whenever the user uploads or references interview transcripts, call notes, user interviews, customer feedback, or qualitative research, or asks to "synthesize," "find themes in," "pull insights from," "tag," "code," or "make sense of" research data — even without saying "insight matrix." Also use for casual phrasings like "what are customers complaining about" or "what's coming up across these calls," or requests to find pain points, recurring complaints, or unexpected/workaround user behaviors. Handles a single transcript or a batch from the same project, offering a combined cross-interview matrix once each is processed. - Skill: `pruthivim/insight-processor` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add pruthivim/insight-processor` - Raw SKILL.md: https://api.skillmd.com/api/skills/pruthivim/insight-processor/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Data & Analytics - Author: pruthivim (https://skillmd.com/u/pruthivim) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/pruthivim/insight-processor --- # Insight Processor Turn raw, messy interview transcripts or notes into a structured insight matrix that a PM or researcher can hand straight to stakeholders. ## Workflow ### 1. Identify inputs Check what was provided: one file, or several files from the same research project (e.g. multiple interviews for one study). If it's unclear how many files or which ones belong to the same project, ask before proceeding. ### 2. Read each file Read the full transcript or notes file. If it's not in your context (only a path was given), use the file-reading skill's guidance to read it properly rather than guessing from the filename. Note whether interviewees are identified (name, "P1"/"P2", role, segment). If so, carry that identifier through to the matrix. If not, use a generic placeholder like "Interviewee" or the filename. ### 3. Extract insights against the theme taxonomy Use this starter taxonomy, but treat it as a hybrid seed list, not a fixed one — if something important doesn't fit, create a new theme rather than forcing it into the wrong bucket: - Onboarding friction - Pricing / value confusion - Feature discoverability - Trust & credibility concerns - Workflow interruption / context-switching - Support & documentation gaps - Performance / reliability complaints - Unexpected / workaround behavior (user doing something the product wasn't designed for) For each distinct insight in the transcript: - Assign it to a theme (existing or new) - Write a **problem statement**: a concise, neutral sentence describing the underlying user problem (not just a restatement of what they said). E.g. "Users can't tell which plan tier includes API access until after signup." - Pull the **best verbatim quote** that evidences it. Clean up filler words (um, uh, like, you know) and false starts for readability, but never change the substance, add words the person didn't say, or soften/sharpen their meaning. If cleaning would materially change the claim, keep it closer to verbatim instead. - If the source material is paraphrased notes rather than a transcript (no actual quote exists to pull from), do not invent or reconstruct a quote-like fragment. Write "Not directly quoted — paraphrased from notes" in that cell instead. A missing quote is more honest and more useful than a fabricated one. - Note the **source** (interviewee identifier / file) - Flag **severity** (High / Medium / Low) based on how strongly it blocks the user or how much frustration is expressed - Note **frequency** — within a single transcript this is usually 1, but if the same person raises it multiple times, or if you're synthesizing across files, count mentions - If the insight reflects the user doing something unexpected (a workaround, misuse, or off-label use of the product), flag it explicitly in a Notes column — these are easy to bury and are often the most valuable finds Don't force coverage — not every part of a transcript contains an insight. Skip small talk, scheduling, and generic praise unless it reveals something concretely useful. Two insights landing under the same theme name does not mean they're the same insight. If two sources raise "onboarding friction" but one is about permission scoping and the other is about template collaborators, keep them as separate rows with separate problem statements — don't merge or generalize them into a vaguer shared statement just because the theme label matches. If two rows are causally linked — one insight is a direct downstream consequence of another, like a data-trust issue leading to a workaround, or a workaround leading to a support burden — keep them as separate rows (each should stand on its own), but note the link explicitly in the Notes column of the downstream row, e.g. "Downstream consequence of [other row's problem statement]." Don't silently leave the connection implicit; it's often the most actionable part of the story. ### 4. Output the matrix Output as a markdown table with these columns: | Theme | Problem Statement | Verbatim Quote | Source | Severity | Frequency | Notes / Unexpected Behavior | Put this directly in the conversation (not as a file) unless the user asks for a downloadable version. If the table is long, it's still fine as one markdown table — don't split it up. After the table, add a short (3-5 bullet) "Top signals" summary above or below it, calling out the highest-severity or most-recurring items — this is what busy stakeholders will actually read first. ### 5. Multiple files from the same project Process each file into its own matrix first. Once all files are done, ask the user whether they want a combined cross-interview matrix that merges recurring themes and rolls up frequency counts across sources. Don't combine automatically — some users want to review each interview individually first. When building the combined matrix: - Keep genuinely distinct insights as separate rows even if they share a theme name (see the note above — this applies across sources too, not just within one). - Report frequency as "X of N interviews" rather than a raw count, so it's clear how many separate sources corroborate the insight versus how often one person repeated themselves. - If the same insight is corroborated across sources but they'd individually earn different severity ratings (e.g. a small team calls it "annoying," a security-conscious enterprise calls the same bug "high severity"), don't flatten them to one rating. Report the range or the higher end (e.g. "Medium–High, varies by org size") and note in the Notes column what's driving the difference — that context is often exactly what a stakeholder needs to prioritize correctly. - Watch for **cross-cutting patterns**: cases where the same *kind* of behavior (not the same literal insight) shows up independently across multiple sources — e.g. two unrelated interviewees both repurposing a feature for something it wasn't built for, even if it's a different feature each time. This is a stronger signal than any single instance and is easy to miss if you only merge identical rows. Call it out explicitly in the Top Signals summary. ## Notes - If a transcript is ambiguous about who is speaking (interviewer vs. interviewee), do your best from context (questions vs. answers) and flag any genuinely unclear attributions rather than guessing silently. - Preserve participant anonymity conventions already used in the source (e.g. if the file says "P3," keep using "P3," don't invent a name). - If asked to prioritize a fixed roadmap or score business impact, that's out of scope for this skill — it produces the raw insight matrix; prioritization against business goals is a separate step for the user.