Home / Guides & Tutorials / The AI Coding Workflow That Ships: From …

CHAPTER 3 OF 7 · 15 min · 3 COPYABLE ASSETS

How to create a PRD with Claude Code from a raw brain dump

Live demo: brain-dump a sprint into Claude Code, answer AskUserQuestion prompts, then run /create-prd to generate a structured, reviewable requirements document.

TL;DW

In Claude Code, paste your brain dump and let the agent interview you through the AskUserQuestion tool. Accept its recommendations for speed, or correct wrong assumptions the moment they surface. When the conversation feels aligned, run /create-prd with an output path as the argument. It converts the entire conversation into a structured PRD with an executive summary, mission, target users, and in-scope work. Review the document before creating any tickets: the PRD is the source of truth everything downstream inherits.

Watch: FULL Guide to Becoming a Principled Agentic Engineer (Build Anything with AI)

▶ Watch this chapter on YouTube from 14:20

Lesson · 11 parts

The demonstration app is a minimal poll builder. Type a question, add options, create the poll. It is simple on purpose: the course is about the process, not the product, and a small app keeps every step legible. Everything shown sits in the companion repository if you want to follow along literally.

Cole pastes a prepared brain dump for phase two of the app: a live presentation mode with results that update without a refresh, QR-code generation for joining polls, multi-question polls, and multiple-choice questions. The end goal is stated inside the prompt itself. Everything should become JIRA tickets that can be handed to developers, or to coding agents.

Brain-dump shape (works in any domain)

Today: <what the app does now>.
Next phase: <features and fixes, with behavior described>.
Constraints: <what must not break, stack, deadlines>.
Goal: turn this into tickets under <epic> that a developer or coding agent can pick up.
Before you write anything, ask me clarifying questions one at a time using the AskUserQuestion tool.

The agent starts asking questions one at a time through AskUserQuestion, each with multiple-choice answers. Two moves matter. Blitz through by accepting recommendations when they are right, and stop hard when one is wrong: that is an incorrect assumption you are deleting before it reaches code. Agents without this tool still work; you just type your answers.

The instruction that triggers the interview

Before you write anything, ask me clarifying questions one at a time using the AskUserQuestion tool.

'How should real-time updates work?' is a technical question. If you know the architecture, use it to clear assumptions precisely. If you sit on the PM side, accepting the recommendation is fine: a wrong guess gets caught later in sprint planning with the developers. The goal is a strong starting point in the tracker, not perfection.

The conversation you just had is the agent's short-term memory, and /create-prd turns it into the PRD. Commands are just prompts loaded on demand, and they take space-separated arguments exactly like a CLI. Here the argument is the output path for the document. Claude Code often recognizes the moment and loads the command's skill by itself.

Under the hood the command is a markdown file describing a procedure: read the current conversation, extract requirements, and write a document with the exact sections the file specifies. Nothing magical, which is the point. You can open it, read it, and change it in five minutes.

Generation takes a few minutes for a large scope because the agent reasons through the whole conversation before writing. Let it run. If you plan to create stories in a separate session later, that works too: the PRD file itself carries all the context forward.

Invoke it. The argument is the output path

/create-prd .agents/prd-phase-2.md

The command file defines the structure every PRD must have: executive summary, mission, target users, scope. That is where the compounding happens. Take how your team already writes PRDs and teach it to the agent, so every generated document lands in your house style. You are not adopting a new format. You are automating your existing one.

Output lands in a .agents/ folder as markdown, but where it lives long-term is your call. Check it into source control, upload it to Confluence through the Atlassian MCP server, attach it to a GitHub issue, or drop it in Google Drive. What matters is that this single document is the initial source of truth for the sprint.

PRD creation and story creation are deliberately two separate commands, because the gap between them is where you validate. Maybe the interview went too shallow. Maybe an answer was misunderstood. Reviewing the artifact keeps you in the driver's seat, and even with careful review time included, this beats writing the document yourself by hours.

A practical review pass takes ten minutes and looks for four things. First, the in-scope list: does it match what you actually said, with nothing invented? Second, the assumptions that survived: anything the interview never asked about got decided silently. Third, priority and sequencing: the agent's ordering is a guess until you confirm it. Fourth, language drift: if the PRD describes a feature more ambitiously than you intended, tickets will inherit the inflation. Edit the file directly or tell the agent what to change; both work because the document, not the chat, is the source of truth.

As the PRD renders, Cole tours the next command. /create-stories is a phase-by-phase procedure: load the PRD (it can run in a completely fresh session, since the document carries all context), break it into user stories in a defined format, and write acceptance criteria for each. The same principle applies here. Your team's story format goes in the command.

The stories command even validates its own work, checking that it extracted every phase of the PRD before finishing. And the JIRA integration is optional by design. Solo developers who manage everything in local markdown files use the same command with the tracker step skipped. Adoption gets easier when the tool bends to the team, not the reverse.

The generated document matches the command's structure exactly: executive summary, mission, target users. The in-scope section mirrors the brain dump, from multi-question polls to the presenter page. Cole's framing is worth remembering. This PRD is the conversation plus the process. Two inputs produced one reviewable artifact.

Study notes

Part 1 of 11 · 14:20 to 15:41

Meet the demo app: a deliberately boring poll builder

Concept The demo codebase is a poll builder: create a question, add options, share it. You will not be learning the app. You will be learning the process against it, which is exactly why the app was chosen to be forgettable: nothing about polls will distract from the artifacts.

Why it matters Small demo, real transfer: every artifact you are about to watch (the dump, the interview, the PRD, the tickets) scales with codebase size while the process stays identical. On your monolith, the only thing that changes is how long the agent reads before it answers.

Try it Decide your follow-along mode before the demo accelerates: clone the repo and mirror each step against the poll builder, or run the same steps against a small project of your own. The second option is slower and teaches roughly double, because your assumptions differ from the demo's.

Do this

Open the poll-builder demo app in the companion repo.
Run it locally if you want to follow along literally.

Part 2 of 11 · 15:41 to 17:09

Paste the brain dump for the next sprint

Concept The dump you are watching has a reusable shape worth extracting: current state, desired next phase, feature list with behavior sketches, and the explicit end goal of tickets a developer or agent could pick up. Steal the shape, not the words; the copyable template sits below.

Example The same shape in a different domain, so you can see past polls: 'Our invoicing app sends single invoices today. Phase two: recurring invoices with pause and cancel, a dunning email sequence for failed payments, and CSV export for accountants. Ship as tickets under the BILLING epic.' Four sentences, and it is fully plannable.

Concept Track the QR-code feature from this list with special attention: it becomes the worked ticket for the entire PIV loop in chapters five through seven, including the debugging lesson at the end where a missing consumer fools everyone for a minute.

Do this

Draft your own phase-two brain dump for a project you know well.
Be specific: name the features, the bugs, and the end goal (tickets).

Part 3 of 11 · 17:09 to 18:32

Answer the interview, or correct it

Why it matters Stating the destination inside the prompt, everything becomes JIRA tickets, is not filler. The agent shapes its questions toward the declared output: told the work is heading to a tracker, it starts probing priorities, dependencies, and slicing, not just feature behavior.

Concept AskUserQuestion turns the interview into structured multiple choice: each question arrives with options and a recommended answer. Your two moves: accept quickly when the recommendation matches your intent, and stop hard when it does not, because that stop is an assumption dying before it can reach code.

Pitfall Do not rubber-stamp recommendations just to get through the list. That quietly converts the interview back into vibe coding with extra steps. The recommendations are usually right, which is precisely what makes the occasional wrong one dangerous: it arrives wearing the same confident formatting as the good ones.

Do this

Paste the interview instruction from the lesson panel at the end of your dump.
Accept recommendations that match your intent. Correct any wrong assumption on the spot.

Part 4 of 11 · 18:32 to 19:37

How deep you go depends on who you are

Concept Calibrate answer depth to your knowledge, not your pride. Technical questions like how real-time updates should work deserve your real answer if you know the architecture, and an honest delegation to the recommendation if you do not. Both are legitimate moves; pretending is the only losing one.

Why it matters The organizational safety net exists by design: PM guesses that survive the interview get caught later in sprint refinement with developers. The interview's job was never perfection. It was a starting backlog good enough that the humans refine instead of rewrite.

Do this

Set your depth rule now: which technical questions you answer yourself, and which you delegate.

Part 5 of 11 · 19:37 to 21:05

Run /create-prd: conversation in, document out

Concept Watch what the input actually is: the conversation itself, the agent's short-term memory. /create-prd converts that memory into a durable document before a context reset can destroy it. This is the exploration-to-structure move you will repeat at every level of the system.

Concept The invocation is barely ceremony: Claude Code recognizes the intent and loads the create-prd skill on its own. Commands are prompts loaded on demand, which is why building your own costs minutes. The agent treats a well-named procedure like a tool it already knows how to hold.

Try it Open create-prd.md in the companion repo while this section plays. Find three things: the section list, the output-path argument, and the tone instructions. Everything you see is editable text. Change one heading tonight and you have started customizing the system instead of renting it.

Do this

Copy the /create-prd invocation from the lesson panel and adjust the output path.
Run it and let it work. Large scopes take a few minutes.

Part 6 of 11 · 21:05 to 22:28

Encode your team's PRD format into the command

Concept Arguments are what make one command serve every project: space-separated values after the command name, exactly like a CLI. Here it is the output path; in create-stories it will be the tracker IDs. The procedure stays constant while the targets change per invocation.

Example House-style encoding in practice: if your PRDs always carry a Risks section and an Out-of-scope section, add those two headings to the command file once. Every future PRD, in every repository, arrives with them filled in. That is one line of markdown doing a style guide's job forever.

Why it matters Generation takes a few minutes on purpose: the agent re-reasons over the entire interview before writing a word. Starving it with a two-minute conversation produces a faster, emptier document. The document's ceiling is set by the interview's depth; feed the interview and the quality follows.

Do this

Open the create-prd command file.
Replace its section list with your team's PRD headings.

Part 7 of 11 · 22:28 to 23:37

The PRD is an artifact. Store it like one

Concept The .agents folder is a staging area, not an archive. The PRD's real home is wherever your team already trusts documents: source control beside the code, Confluence through the same Atlassian MCP connection, or attached to the epic in the tracker.

Why it matters Initial source of truth is a strong phrase with a practical meaning: when a ticket looks ambiguous three weeks from now, this document is what settles the argument. Store it where the argument will actually happen, and version it so the settlement is auditable.

Do this

Choose the durable home for your PRDs: source control, Confluence, or Drive.
Commit the generated file before moving on.

Part 8 of 11 · 23:37 to 25:03

Review before you generate tickets

Why it matters The two-command split, create-prd then create-stories, exists to force a human pause at the moment of maximum leverage. Errors caught in the PRD cost minutes to fix. The same errors caught after they have fanned out into a dozen tickets cost a sprint.

Example A ten-minute review pass that actually works: check the in-scope list against what you said, nothing invented and nothing dropped. Hunt for one silent assumption the interview never covered. Sanity-check the ordering. Flag any feature described more ambitiously than you intended, because language drift here becomes scope creep downstream.

Concept The economics survive the review time comfortably: correcting a generated document is a different and cheaper job than writing one. You edit at decision level while the agent handled production level. That division is the entire productivity story of this workflow, in miniature.

Do this

Read the PRD top to bottom before creating stories.
Check the four review points: scope match, silent assumptions, ordering, language drift.

Part 9 of 11 · 25:03 to 26:47

While it generates: inside /create-stories

Concept The create-stories tour begins while the PRD renders. Its arguments preview the next chapter: the PRD path, the JIRA project, and the epic. An epic, if you need the term, is JIRA's container for related tickets, the shelf this sprint's work will sit on.

Pitfall One thing the command will not do: create the epic itself. Cole made it by hand beforehand, the single manual JIRA action in the whole pipeline. Forget yours and the run fails at the final step, after all the expensive reasoning has already been spent.

Concept Inside the command, the phases mirror what you just watched: load the document, break it into stories, apply the defined format. Because the input is a file rather than chat history, this command runs identically in a fresh session tomorrow, or on a teammate's machine next month.

Do this

Open create-stories in the repo and skim its phases.
Find where the acceptance-criteria format is defined. That part is yours to edit.

Part 10 of 11 · 26:47 to 28:13

Conventions plus self-checks make commands team-safe

Concept A user story in this command's format is a one-line need from a user's perspective plus acceptance criteria, the testable conditions that define done. The format is a command setting, not a law. Make it match what your team already writes so adoption is invisible.

Why it matters The built-in self-check, verifying that every PRD phase became a story, is a pattern worth copying into every command you write. Agents are strong at producing and mediocre at noticing omissions, so make the procedure check its own coverage explicitly instead of hoping.

Concept Solo developers get first-class treatment: skip the tracker arguments and the stories land as local markdown files. Same pipeline, no JIRA anywhere. That also makes this command safe to trial on a side project before your team commits to anything organizational.

Do this

If you skip JIRA, decide your local markdown layout for stories now.

Part 11 of 11 · 28:13 to 28:54

Read the finished PRD

Concept The verification is structural, not aesthetic: the document's sections match the command's specification exactly. When output format is encoded in the procedure, format review becomes a glance, and your attention goes where it belongs, to the substance of the scope.

Why it matters Cole's equation, the PRD is the conversation plus the process, is the mental model to keep. Quality has exactly two inputs: a thin interview or a sloppy command produces a weak document, and you now control both dials. Nothing about the output is luck.

Do this

Compare the generated PRD's sections against the command's structure.
Verify your entire brain dump appears in the in-scope list.

Key terms

AskUserQuestion: Claude Code's tool for asking the user structured multiple-choice questions during a task.
Short-term memory: The current conversation context; it vanishes on reset unless converted into a document.
Source of truth: The single document that settles later disagreements about scope and intent.

Key takeaways

Commands take space-separated arguments like a CLI, so one command serves every project and output location.
Encode your team's existing PRD format into the command, so the agent writes documents the way your team already does.
Never pipe a fresh PRD straight into ticket creation. Reviewing the artifact is the human-in-the-loop step that makes delegation safe.
The finished PRD equals your conversation plus the /create-prd structure. Cole calls it the baby of both.

Watch out

Cole ends the interview early and skips PRD iteration for demo speed only. His words: do as I say, not as I do. In real work the questions run 10 to 15 minutes and the PRD gets a proper edit pass.
Store the PRD somewhere durable: source control, Confluence, or a GitHub issue. It is the input for every downstream step, not a throwaway chat artifact.

Check your understanding

Why are /create-prd and /create-stories two separate commands instead of one?

Because the gap between them is the human review step. A fresh PRD may contain misunderstood answers or unasked questions, so you validate the artifact before it becomes tickets.

What two things combine to produce the final PRD?

Your clarifying-question conversation (the agent's short-term memory) and the structure encoded in the /create-prd command.

01 14:20 Note Meet the demo app: a deliberately boring poll builder ▾

02 15:41 Step Paste the brain dump for the next sprint ▾

03 17:09 Step Answer the interview, or correct it ▾

04 18:32 Concept How deep you go depends on who you are ▾

05 19:37 Step Run /create-prd: conversation in, document out ▾

06 21:05 Concept Encode your team's PRD format into the command ▾

07 22:28 Concept The PRD is an artifact. Store it like one ▾

08 23:37 Watch out Review before you generate tickets ▾

09 25:03 Note While it generates: inside /create-stories ▾

10 26:47 Concept Conventions plus self-checks make commands team-safe ▾

11 28:13 Step Read the finished PRD ▾