📋 AI PRD Workflow

RFC-driven development for AI coding agents

Vague idea → verified PRD → features → rules → sequenced RFCs → reviewed, tested code

Quick Start · Workflow · Commands · Why RFCs? · Examples

RFC-driven since March 2025 — before planning modes existed in any AI coding agent.

---

A lightweight RFC-driven development workflow for AI coding tools. Ten battle-tested prompts take you from a rough idea to a verified PRD, prioritized features, project rules, and sequenced RFCs — then guide implementation, code review, and testing, one RFC at a time.

Use it two ways:

• Native slash commands in Claude Code and Cursor — /create-prd, /implement-rfc 001, /workflow-status, …
• Copy-paste prompts into any AI assistant or IDE — ChatGPT, Gemini, Windsurf, Copilot, anything

No CLI to learn, no framework to adopt, no lock-in. Just markdown.

Quick Start

Option 1: Install as slash commands (Claude Code & Cursor)

curl -fsSL https://raw.githubusercontent.com/nurettincoban/ai-prd-workflow/main/install.sh | bash -s -- /path/to/your/project

Or from a clone:

git clone https://github.com/nurettincoban/ai-prd-workflow.git
cd ai-prd-workflow
./install.sh /path/to/your/project            # both tools
./install.sh /path/to/your/project --claude   # Claude Code only
./install.sh /path/to/your/project --cursor   # Cursor only

[!IMPORTANT] Restart Claude Code or Cursor after installing. A running session does not pick up newly written command files, so the first command you type fails with Unknown skill — which reads like a broken install but is just a stale session. Type / after restarting to confirm you see create-prd.

Then open your project and work through the pipeline:

/create-prd            # guided interview → PRD.md
/verify-prd            # gap analysis → improved PRD.md + PRD-REVIEW.md
/extract-features      # PRD.md → FEATURES.md (MoSCoW prioritized)
/generate-rules        # → RULES.md (project standards for the AI)
/generate-rfcs         # → RFCs/ folder, in dependency order
/test-strategy         # test plan — before the tests get written
/implement-rfc 001     # plan → your approval → implementation → verification
/review-rfc 001        # fresh session → reviews/REVIEW-RFC-001.md
/manage-changes        # requirements changed mid-build? assess impact first
/workflow-status       # lost? see what's done and what's next

[!TIP] Cloning this repo and opening it in Claude Code or Cursor gives you the commands immediately — try them against the example project.

Option 2: Copy-paste into any AI assistant

1. Pick a prompt from Available Prompts below
2. Copy its contents (or use ./copy-prompt.sh --list to browse)
3. Paste into any AI assistant with your project context attached

Workflow

flowchart LR
    IDEA([💡 Idea]) --> PRD[Create PRD] --> VERIFY[Verify PRD] --> FEAT[Extract Features] --> RULES[Generate Rules] --> RFCS[Generate RFCs]
    RFCS --> TEST[Test Strategy] --> IMPL[Implement RFC] --> REVIEW[Code Review]
    REVIEW -.->|next RFC| IMPL
    CHANGE([Change request]) -.-> CM[Change Management] -.-> RFCS

1. Create PRD — Start with a vague idea and develop it into a complete PRD through a guided interview
2. Verify PRD — Identify critical gaps and improve quality before anything gets built
3. Extract Features — Transform the verified PRD into organized features with priorities and acceptance criteria
4. Generate Rules — Establish technical guidelines the AI must follow, wired into your agent config (CLAUDE.md, AGENTS.md, or .cursor/rules/)
5. Generate RFCs — Break the project into logical, sequenced implementation units
6. Test Strategy — Plan coverage from the RFCs' acceptance criteria, while the tests can still be written to the plan rather than the plan written to the tests
7. Implement RFCs — One RFC at a time: the AI plans first, you approve, then it codes — and runs the build, typecheck and tests to demonstrate every acceptance criterion rather than asserting it
8. Code Review — Review each implementation against its RFC, project rules, security, and performance — in a fresh session, ideally a different model than wrote the code

When requirements change mid-development, run Change Management to assess impact before touching the docs, then continue. Run Workflow Status anytime to see where you are and what's next.

Each step is a different lens

Persistent artifacts are the visible half of this workflow. The half that does the work is that each step looks at the problem through a different lens, and each lens catches defects the others structurally cannot.

That was measured, not assumed — by running all ten commands end to end to build a real, publishable TypeScript library from a real PRD:

Step	What it caught	Could another step have caught it?
/verify-prd	A function silently contradicting the PRD's own documented convention; unspecified color space; a hidden rendering dependency	No — required diffing the spec against the reference implementation
RFC "edge cases" section	That the pinned TypeScript major would break the build; a clone-aliasing bug; an operation-ordering hazard	No — required reasoning about code that did not exist yet
/review-rfc	A geometry leak on an error path; unvalidated NaN inputs; interleaved buffers read as garbage	No — all 17 acceptance criteria already passed
/test-strategy	Normals never asserted finite, so degenerate geometry renders black while the entire suite stays green	No — reasons about coverage that should exist, not about code that does
/workflow-status	Two required files never created, while their RFC was reported complete	No — required auditing claims against the filesystem
CI matrix from an RFC	The declared peer-dependency range was wrong — the suite failed on three published versions	No — required running the suite against each one
Cold-context review	An RFC that contradicted itself; an acceptance criterion satisfiable only by luck; a cross-document signature conflict	No — the author had read past all three, repeatedly

Seven lenses, seven classes of defect, near-zero overlap. No single "plan then code" agent mode reproduces that.

The most striking single result: the workflow predicted a real build failure three steps before the build existed. RULES.md pinned TypeScript 7. The RFC's edge-case section, written before any code, said that if a toolchain plugin lagged TS 7 the fallback was 5.9.x, recorded as a deviation rather than downgraded silently. That is exactly what happened — and tsc --noEmit passed clean throughout, so only running the build ever revealed it.

Cross-referenced artifacts constrain future edits on their own

A prediction going into that run was that re-running /extract-features after a PRD change would silently renumber feature IDs and break every RFC citation. It was tested: a cold agent with no session history, no mention of IDs, and two new features deliberately inserted into the earliest category — the placement most likely to force renumbering.

The IDs held completely. The agent appended the new features at the end and explained itself unprompted: "all six RFCs cite F1–F39 by number … so the new primitives were appended … numbered so no existing citation moves."

Nobody wrote that rule down. Because the RFCs cite features by ID and RULES.md states a critical path in those terms, a cold reader infers that the IDs are load-bearing. Cross-referenced artifacts don't merely record decisions — they constrain future edits with no rule written down to enforce it.

Available Prompts

Command	Prompt	Description
/create-prd	Interactive PRD Creation	Create a PRD through a guided step-by-step questioning process
/verify-prd	PRD Comprehensive Verification	Verify and improve your PRD by identifying gaps and quality issues
/extract-features	PRD to Features	Extract and organize features with MoSCoW prioritization
/generate-rules	PRD to Rules	Generate technical guidelines and standards for development
/generate-rfcs	PRD to RFCs	Break down your PRD into sequenced implementation units
/test-strategy	Testing Strategy	Generate a comprehensive test plan from features and RFCs
/implement-rfc <id>	Implementation Template	Implement a single RFC — plan first, code after approval, then verify
/review-rfc <id>	Code Review	Review an implementation against RFC, rules, security, performance
/manage-changes	PRD Change Management	Assess and integrate requirement changes mid-development
/workflow-status	Workflow Status	See which artifacts exist, detect drift, get the next step

Why RFC-driven development?

AI coding agents are strong enough now to build entire features unsupervised — which makes what you ask for the bottleneck, not the code. If you've heard of spec-driven development (GitHub Spec Kit, Amazon Kiro), this is the same philosophy — and this workflow predates both — with sequenced RFCs as the unit of work and no framework or CLI to adopt. Structured specs fix the real problems:

• Clearer instructions, fewer hallucinations — a PRD and RFCs give the AI precise context and boundaries instead of letting it fill gaps with assumptions
• Scope control — explicitly defined in/out of scope prevents the agent from implementing features nobody asked for
• Incremental verification — sequenced RFCs let you validate at each step instead of reviewing a 5,000-line diff at the end
• Context that fits — focused RFCs work within context limits far better than "here's my whole idea, build it"
• Traceability & knowledge preservation — every implementation traces to a requirement, and the docs outlive any one chat session, team member, or model
• Shared mental model — business stakeholders, developers, and AI tools all work from the same documents

"Doesn't my coding agent already plan?"

Yes — tactically. This workflow shipped in March 2025, before planning modes existed in any AI coding agent, and it solves a different problem than they do:

Built-in plan mode	This workflow
Plans one task — "how do I implement this?"	Plans the product — what are we building, for whom, what's out of scope?
Plan dies with the session	PRD, features, rules, and RFCs persist across sessions, models, tools, and teammates
Takes your request at face value	/create-prd interviews you first — decisions leave your head before code exists
Reviews code by "looks right"	/review-rfc verifies against written acceptance criteria; /workflow-status catches drift

The two compose rather than compete: /generate-rfcs decides what the next unit of work is, and each /implement-rfc hands your agent's planner a well-scoped, context-sized task — exactly what plan mode is good at.

Sweet spot: greenfield products, multi-week builds, and anyone building something real with AI — where scope creep and forgotten decisions, not code quality, are what kill the project. For a small fix in an existing codebase, your agent alone is fine. For everything bigger, write the spec first.

Examples

The examples/url-shortener folder contains complete sample outputs for each step of the workflow:

• PRD — Product Requirements Document
• Features — Extracted features with MoSCoW prioritization
• Rules — Development standards and guidelines
• RFCs — Implementation units (3 RFCs)

Compatibility

The prompts are plain markdown and work with any modern LLM:

• Claude (Anthropic) — Claude 4 and Claude 5 families
• GPT (OpenAI) — GPT-4o, GPT-5 family
• Gemini (Google) — Gemini 2.5 and later
• Open models — Llama, Mistral, Qwen, DeepSeek (with sufficient context)

Tool support:

• Native slash commands: Claude Code, Cursor (via install.sh)
• Copy-paste: Windsurf, GitHub Copilot, Codex CLI, Cline, Aider, or any chat interface (manually or via ./copy-prompt.sh <prompt-file>)

Quick Tips

• Provide complete documents when possible and answer the AI's clarifying questions
• Review and customize AI outputs before implementation — the approval gate in /implement-rfc exists for a reason
• Implement RFCs in order; each one is implementable once its declared predecessors are done, so independent branches can run in parallel if you have the people for it
• Run /review-rfc in a fresh session, ideally on a different model — a reviewer still holding the author's reasoning is not a reviewer
• When two documents disagree, the order of authority is PRD.md > FEATURES.md > RULES.md > RFCs > generated plans, and RULES.md beats any generic advice a prompt gives
• Keep RULES.md referenced from your agent config so standards stay in context

Contributing

See CONTRIBUTING.md for guidelines on submitting new prompts, quality standards, and testing approach.

License

This project is licensed under the MIT License — see the LICENSE file for details.

---