Use requirements-interview

Generate per-stakeholder interview kits for feature discovery

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.

Reach for it 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".

Install it

npx skilldrop-cli install requirements-interview                 # Claude Code, your user folder
npx skilldrop-cli install requirements-interview --project       # Claude Code, this repo
npx skilldrop-cli install requirements-interview --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Product manager pack: --pack product-manager installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "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"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Draft the PRD for this feature"
• "Structure this existing raw input into a brief"
• "Map the customer's journey through onboarding"

If another skill answers instead, ask for this one by name: "use requirements-interview".

Check what you get

A good result:

• ≤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.

Use something else when

• The answers already exist in tickets, analytics, or support logs — mine those first; interviews are for what data can't say
• Synthesizing notes after the interviews — that's brief-intake + decision-log
• Writing the requirements themselves — prd-draft, after the interviews
• Usability testing of an existing design — different method; this is problem discovery

Where a loop runs it

• Stage gather of the discover loop

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: brief-intake, decision-log, prd-draft

Edit this page on GitHub · View source