Skip to content
Keelson

interactive-prd

interactive-prd writes a product requirements document by interviewing you. It asks foundation questions, researches the market and your codebase, asks deep-dive questions, assesses technical feasibility from what already exists, asks scope questions, drafts the PRD, then validates every technical claim against the real code. The human is the input channel, not a yes/no rubber stamp: three gates capture your answers and thread them into the next phase.

Reach for it when an idea is still fuzzy and you want to think it through. It will not generate a PRD without you, and it does not implement the plan it produces. To take a written plan to code, hand off to plan-act-evaluate or fix-issue.

Invoke it

Section titled “Invoke it”
Terminal window
keelson workflow run interactive-prd --inputs ARGUMENTS="a usage dashboard for workflow runs"

It sets interactive: true and uses three approval gates, so it needs a running server (keelson start); the gates cannot resolve in the headless CLI fallback. It uses a Copilot subscription, and reads your repo to ground the PRD in real code.

The shape

Section titled “The shape”

A single conversational spine: a prompt asks, a gate captures, the next prompt builds on the answer. The three gates partition the work into foundation, deep-dive, and scope, narrowing from problem to MVP before a line of the PRD is written.

The interactive-prd flow, left to right, alternating prompt nodes and brass approval gates: initiate, then foundation-gate, then research, then deepdive-gate, then technical, then scope-gate, then generate, then validate. Each gate captures the user's answers, which feed the following prompt.

Figure 1. The interactive-prd conversation. The brass nodes are human gates; each one captures your answers (capture_response) and the next prompt reads them, so the interview narrows from problem to scope before the PRD is generated and then validated against the code.

Node by node

Section titled “Node by node”
NodeKindWhat it does
initiatepromptRestates the idea and asks the five foundation questions (who, what, why, why now, success).
foundation-gateapprovalCaptures your foundation answers.
researchpromptResearches competitors and explores the codebase for related work, then asks the deep-dive questions.
deepdive-gateapprovalCaptures your deep-dive answers (vision, primary user, job-to-be-done, constraints).
technicalpromptRead-only ([Read, Glob, Grep]): assesses feasibility from real files, cites file:line, asks scope questions.
scope-gateapprovalCaptures your scope answers (MVP, must-haves, hypothesis, exclusions).
generatepromptWrites the PRD to the scratch dir, filled from the three sets of answers, referencing verified paths.
validatepromptRe-reads the PRD and checks every path, API, data model, and component name against the real code, editing corrections in.

The parts worth a second look

Section titled “The parts worth a second look”

The human is the input channel. The three gates set capture_response: true, so each reply becomes $foundation-gate.output, $deepdive-gate.output, $scope-gate.output, and the following prompt substitutes them in. The workflow is a structured interview: it cannot proceed without your answers, and each phase sees everything you have said so far.

It narrows on purpose. Foundation establishes the problem, deep-dive the user and constraints, scope the MVP. Gating between them stops the PRD from running ahead of decisions you have not made yet.

It is grounded in real code, twice. technical runs read-only and must cite file:line for every claim, preferring to extend what exists over inventing new surfaces. Then validate re-checks the finished PRD against the codebase and edits corrections in, so the document does not ship claims the code does not support.

Patterns it demonstrates

Section titled “Patterns it demonstrates”
  • Approval gate, three of them: capture_response turning a human into the input channel.
  • Bound an agent’s reach: technical is read-only; generate and validate widen to write and edit.
  • Progressive disclosure: each phase reads every prior answer, so context accumulates across the gates.

Adapt it

Section titled “Adapt it”
  • Fewer rounds. Two gates (foundation, scope) make a faster interview if you do not need the deep-dive pass.
  • Reshape the questions. The question sets live in the prompt bodies. Swap them for your team’s discovery template without touching the structure.
  • Drop the validation. Cut the validate node for a quicker draft, at the cost of the against-the-code accuracy check.
Section titled “Related”