📋 AI PRD Workflow

RFC-driven development for AI coding agents

Idea or existing code → verified PRD → features → rules → sequenced RFCs → reviewed, tested code

Quick start · How it works · Why · Evidence · Install options

English · 简体中文 · Türkçe · 日本語 · 한국어 · Español

_{RFC-driven since March 2025 — before Claude Code or Cursor had a plan mode, and before Kiro or Spec Kit existed.}

AI coding agents write code well. They are worse at deciding what to build, remembering yesterday's decisions, and noticing when two documents disagree. This workflow handles that part. It takes an idea — or a codebase that already exists — to a reviewed PRD, prioritized features, project rules, and small RFCs in dependency order. Then it implements and reviews them one at a time.

Every step writes a markdown file that the next step reads, so decisions outlive the chat session. A script checks that the files still agree with each other. No CLI to learn, no framework to adopt, no lock-in.

_{A real /workflow-status run on the repo's own v2.0 example, condensed. Full report · what it was checked against}

Quick start

Claude Code — install the plugin:

/plugin marketplace add nurettincoban/ai-prd-workflow
/plugin install prd-workflow@ai-prd-workflow

Codex, GitHub Copilot, Cursor, Gemini CLI, OpenCode or Devin — install the skills into your project:

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

Any chat assistant (ChatGPT, Claude.ai, …) — copy a prompt from the command table and paste it in.

[!IMPORTANT] Restart your AI tool after installing. A running session does not see new skills, so the first command fails with Unknown skill — which looks like a broken install but is only a stale session.

Then run the commands in order:

/create-prd          # interview → PRD.md   (existing code? use /document-existing instead)
/verify-prd          # gaps and contradictions → improved PRD.md + PRD-REVIEW.md
/extract-features    # → FEATURES.md
/generate-rules      # → RULES.md
/generate-rfcs       # → RFCs/ + RFCS.md, in dependency order
/test-strategy       # → TEST-STRATEGY.md, before any test is written
/implement-rfc 001   # plan → your approval → code → proof that it works
/review-rfc 001      # review in a fresh context → reviews/REVIEW-RFC-001.md

Run /workflow-status whenever you are unsure what comes next, and /manage-changes when requirements change. In Codex, type $create-prd instead of /create-prd. With the Claude Code plugin, commands carry the plugin's name: /prd-workflow:create-prd.

Try it on the example first. The repo's v2.0 example looks complete, and it is not:

git clone https://github.com/nurettincoban/ai-prd-workflow.git
cd ai-prd-workflow
./install.sh examples/url-shortener/before

Open examples/url-shortener/before in your AI tool, run /workflow-status, and compare its report with the problems we found by hand.

How it works

flowchart TB
    subgraph define ["1 · Define what to build"]
        direction LR
        idea([💡 New idea]) --> create["/create-prd"] --> verify["/verify-prd"]
        code([🗂️ Existing code]) --> document["/document-existing"] --> verify
    end
    subgraph plan ["2 · Plan how to build it"]
        direction LR
        features["/extract-features"] --> rules["/generate-rules"] --> rfcs["/generate-rfcs"] --> tests["/test-strategy"]
    end
    subgraph build ["3 · Build it, one RFC at a time"]
        direction LR
        implement["/implement-rfc"] --> review["/review-rfc"]
        review -.->|next RFC| implement
    end
    subgraph anytime ["Anytime"]
        direction LR
        changes["/manage-changes"] ~~~ status["/workflow-status"]
    end
    define --> plan --> build
    build ~~~ anytime

A few rules hold it together:

• Plan, approve, then code. /implement-rfc stops after the plan and waits for you.
• Review with fresh eyes. /review-rfc will not review code written in the same conversation. In Claude Code it runs in a separate context automatically.
• IDs never change. Requirements, features, rules, and RFCs cite each other by ID. scripts/trace-check.py fails when a citation breaks or a Must-have feature has no RFC, and the commands run it for you.
• When files disagree, PRD.md wins over FEATURES.md, which wins over RULES.md, then the RFCs. The commands say which file they followed, and flag the other for correction.

Why this workflow

Your coding agent probably has a plan mode. A plan mode plans one task. This workflow plans the product:

The two work together: /generate-rfcs decides what the next piece of work is, and /implement-rfc hands your agent's planner a small, well-defined task.

Use it for multi-week builds, and anything real you build with AI, where scope creep and forgotten decisions hurt more than code quality. Skip it for a one-line fix.

If you know spec-driven development (GitHub Spec Kit, Amazon Kiro), this is the same idea, with RFCs as the unit of work and no CLI or framework to adopt. It predates both.

Evidence

Each step looks at the project from a different angle, and each catches problems the others cannot. This was measured by building a real TypeScript library end to end with the workflow, from a real PRD:

The most striking result: before any code existed, an RFC's edge-case section predicted that a build plugin would not support TypeScript 7 yet, and named the fallback version. That is exactly what happened. Type-checking passed throughout, so only running the build revealed it.

IDs held, too. When the PRD changed mid-project, a fresh agent re-ran /extract-features and added the new features at the end instead of renumbering — without being told to, because the RFCs cite features by number.

That library is not part of this repository, so here is evidence you can check yourself:

• The url-shortener example — fresh-context runs that never saw our list of known problems found 12 of 13 cross-document problems (/workflow-status) and 10 of 10 PRD problems (/verify-prd), plus several we had missed.
• The eval suite — runs the same checks with and without the workflow, so the difference is measured, not claimed.

Install options

install.sh puts the skills where each tool looks for them:

From a clone of this repository:

./install.sh /path/to/your/project            # both folders (the default)
./install.sh /path/to/your/project --claude   # Claude Code only
./install.sh /path/to/your/project --agents   # the other tools only

• install.sh never overwrites a skill you have edited. --force replaces it after saving a backup.
• --ref v3.0.0 installs a specific release. Use the same tag in the curl URL.
• Upgrading from v2? Add --remove-legacy to move the old command files into a backup folder.
• Prefer copy-paste? ./copy-prompt.sh --list shows the prompts, and ./copy-prompt.sh <file> copies one to your clipboard.

Tips

• Answer the questions. The interview commands work best with your real decisions, not the agent's guesses.
• Read each file before you move on. Fixing a PRD takes minutes; fixing code built on a wrong PRD takes days.
• Keep the rules in context. Reference RULES.md from your agent config (CLAUDE.md, AGENTS.md, or .cursor/rules/). /generate-rules suggests how.
• Parallelize if you can. An RFC can start as soon as its declared predecessors are done. Working alone, just follow the numbers.

Contributing

See CONTRIBUTING.md. The prompt files at the root are the source; everything else is generated or checked from them.

Acknowledgments

Thank you to Anthropic for supporting this project and welcoming it into its open source program.

License

MIT — see LICENSE.

If this workflow saves you time, a ⭐ helps others find it.