Generate per-stakeholder interview kits for feature discovery — ≤7 questions per stakeholder ranked by how much the answer changes the design, each naming the decision it informs, with at least one disconfirming question per script and an assumptions-to-validate ledger. Use when the user is gathering business requirements, preparing stakeholder or user interviews, or asks "what should I ask the sponsor/users/ops before we build this".
Pack product-managerTier standardJob Decide what to buildv0.1.0
In Claude Code, with the product-manager plugin installed, invoke it as:
/product-manager:requirements-interview
Try it
A realistic prompt from the skill's acceptance evals:
We're scoping a billing-migration feature. Build interview kits for the stakeholders we should talk to.
What a good result looks like
≤7 questions per stakeholder, ranked, each annotated with the decision it informs and how the answer moves the design. Unannotated questions don't ship.
Zero leading questions in discovery position. Anything shaped "wouldn't it be great if…" or answerable with a polite yes fails the kit.
Every script contains a kill-question — and the kit says what a kill-answer looks like, so the interviewer recognizes it instead of softening it.
End-user scripts open with a concrete recent episode, never "typically".
Every assumption in the ledger has a falsification condition. "We'll validate adoption appetite" without what-would-disprove-it is theater.
The synthesis path is named. Kits that don't say where the notes go produce interviews that end at the notes.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 82% of its checks, against 53% without it, and a blind judge preferred it. How skills are checked
18 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
Each stakeholder script has at most 7 questions, ranked by how much the answer changes the design
Every question is annotated with the decision it informs and how the answer moves the design
No leading questions in discovery position — nothing answerable with a polite yes
Every script contains a kill-question, and the kit states what a kill-answer would mean
Stakeholders are chosen and named by role, with a reason each one is on the list
Does not plan to interview patients directly in the next two weeks, given ethics approval takes about six weeks; the patient view is sought another way (such as the Patient Liaison Officer's complaint themes) or deferred
Questions probe the pharmacy wait (median 3.1 hours) rather than accepting the sponsor's view that late discharge summaries are the main cause, and at least one question tests the sponsor's theory
Does not spend questions on adding staff, given there is no budget for new staff, or notes that this is already decided
Catches that 14% of 1,200 monthly discharges is 168, not 280
Each stakeholder's set of questions fits a 20-minute interview (no more than about 7 questions each)
Covers all four named stakeholders
Does not invent data, stakeholders, or hospital systems not in the brief
Gives questions for both the groomers and the front-desk person without asking the user clarifying questions first
A few bullets per person — no more than about 7 questions each — and short overall
Questions get at how the salon works today and what could go wrong (for example how long different dogs take, no-shows, deposits, walk-ins, special handling), not just 'what features do you want'
At least one question tests the owner's assumption that online booking will help, for example by asking what actually goes wrong with bookings today
Questions are worded so a groomer can answer them easily, without software jargon
Does not invent facts about the salon (prices, customer counts, current software) presented as known
When it should and shouldn't activate
Should activate:
Build interview questions for our stakeholders on this feature
Who should we talk to for this discovery, and what should we ask them?
Create a discovery interview kit per stakeholder
I need non-leading questions that would actually change the design
Should leave to another skill:
Draft the PRD for this feature
Structure this existing raw input into a brief
Map the customer's journey through onboarding
Write the design doc for the billing migration
Hands off to
brief-intake — when the interview is done and the notes are raw. Collect the transcript into a tagged brief before any generator sees it.