Proposal: interview-mapper skill — transcript-level analysis, complements research-ops/product-research

What I'd like to propose

I have a skill called interview-mapper — turns a raw interview transcript into a structured, evidence-grounded analysis. Every finding is tied to a verbatim quote, the coding is checked across multiple passes, and anything uncertain gets flagged for a human instead of silently resolved. It supports 16 different interview lenses (JTBD, CustDev/Mom-Test, org-mapping, exit interviews, win/loss, usability, expert validation, focus groups, and others) selected through an intake step (goal × respondent type).

It specifically targets three failure modes I kept hitting with LLM-based transcript analysis:

• Transcription drift — the model paraphrasing instead of quoting
• Fabricated/"regenerated" quotes — a quote that sounds plausible but isn't actually in the source
• Run-to-run instability — the same transcript producing different conclusions on separate passes

Mechanically: a route.py script picks the lens from goal+respondent, then quote-verification and consensus-across-runs scripts check the output before it's presented. There's an eval suite with gold-standard fixtures per lens.

Why I'm opening an issue instead of a PR

I looked through research-ops/skills/product-research first, since it's the closest existing skill by topic (interviews, JTBD, insight synthesis). I don't think it's a duplicate — product-research operates one level up: it helps you pick a method and size a study, then flags single-source anecdotes when synthesizing already-coded observations. It doesn't touch the transcript itself — no quote-verification, no cross-run stability checking, no per-lens templates.

interview-mapper is a level below that: given a transcript you already collected, how do you code and interpret it reliably. Different input, different failure mode it guards against.

That said, the topic overlap (interviews, JTBD, ResearchOps-adjacent) is real enough that I'd rather check before building a PR, per the CONTRIBUTING.md guidance. Two questions:

1. Does this read as a legitimate complement to product-research rather than a competing/duplicate skill?
2. Where would it fit — a new skill inside research-ops/, or somewhere in product-team/ (next to ux-researcher-designer)?

Happy to adjust scope/framing based on what you think fits the repo's structure best.