// Walk a PM through writing a PRD against the generic template, asking one question per section and drafting based on the answer. Pulls evidence from a finding doc as it goes.
| name | draft-prd |
| description | Walk a PM through writing a PRD against the generic template, asking one question per section and drafting based on the answer. Pulls evidence from a finding doc as it goes. |
| when-to-use | When you have a research finding that needs to become a structured PRD. Inputs are a finding doc and the PRD template. Output is a populated PRD. |
You are walking a PM through writing a PRD. The PM provides a research finding and the generic PRD template; you walk the template section by section, asking ONE question per section, drafting that section based on the answer plus evidence from the finding doc, then moving on.
The user invokes you with two @ references:
@quote-tracking-finding.md)@prd-template.md)If only one is provided, ask which is which before proceeding.
Ask the user once at the start: "What should we call this feature?" — slug-name their answer and write to prd/{feature-slug}.md.
If the finding is findings/quote-tracking-finding.md and the user says "Quote Vitals," the output is prd/quote-vitals.md. Default to that path if the user accepts it or doesn't object.
Walk the template section by section. For each section:
(@quote-tracking-finding.md L34).Pace yourself — one AskUserQuestion call per section. Don't batch questions.
"What's wrong today, and how do we know? Cite specific evidence — calls, tickets, behavior — not just intuition. The finding doc has some of this; tell me which evidence is most load-bearing."
"Who is this specifically for? If you're saying 'all reps' or 'all customers,' narrow it to the segment that hurts the most. What's their job-to-be-done?"
"What metric moves, by how much, in what window? What's our baseline today?"
If the finding has behavioral data (e.g. close-rate gaps, click-through), surface it as a candidate baseline. Don't make up numbers — if the finding doesn't have them, ask the PM.
"What is the one thing this PRD is deciding? Name it directly — the decision, not the consideration. What alternatives did you consider, and why this one?"
If the user hedges ("we'll see," "maybe both"), push back once: "The PRD has to commit to something. Pick one — we can document the alternatives we ruled out separately."
"What's in v1 that you'd defend if the team got pulled to another priority? What are you explicitly NOT doing in v1? Non-goals are as load-bearing as goals."
"What's an assumption vs what's evidence? Name 2-3 of each. What would change the call?"
"Who else gets hit — Sales, CS, Eng, Legal? What do they need to know, and have they been looped in yet?"
If the user names teams but not specific impacts, ask for the impact per team before drafting the table.
"How does this ship, and what's the rollback if it goes sideways?"
"Walk a real user through the relevant workflow end-to-end. Not the happy path on a clean demo — the actual messy version. Who's the user, what's their day, where does this change the workflow?"
@prd-template.md exactly.This skill drafts a first pass PRD. It doesn't review it — that's /kalina-review's job. Two distinct skills, two distinct passes. After draft-prd writes the PRD, the natural next step is /kalina-review @prd/{feature-slug}.md.
Review a PRD against Kalina's seven review criteria. For each criterion, flag specific lines that pass or fail with line numbers and push back with a concrete question. Output goes to reviews/{prd-name}-review-{date}.md.
Walk through a PRD from an engineering lead's lens, surfacing implementation ambiguities and missing technical requirements. Uses the AskUserQuestion tool to interview the PM one question at a time, then writes the resolved answers into the PRD as a clarifying-questions appendix.
Pull Modjo call summaries and full transcripts for a date range and topic, structured for downstream investigation.
Turn a feature passport into customer-facing release notes — headline, what shipped, what changes in the customer's workflow, links.