RFC-driven development for AI coding agents

Decide what to build before your agent builds it.

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

AI coding agents write code well. They are worse at deciding what to build, remembering yesterday's decisions, and noticing when two documents disagree. Every step here writes a markdown file the next step reads, so decisions outlive the chat session — and a script checks the files still agree. No CLI to learn, no framework, no lock-in.

Get started View on GitHub

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

Install the plugin from inside Claude Code:

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

Plugin commands carry the plugin's name: /prd-workflow:create-prd.

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

In Codex, type $create-prd instead of /create-prd.

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.

/workflow-status auditing the v2.0 example: the traceability check fails because F7 has no RFC and RFCS.md is missing, then reading the documents against each other finds 20 inconsistencies — A real `/workflow-status` run on the repo's own v2.0 example, condensed. Full report

How it works

Run the commands in order. Each one reads the files the previous ones wrote. Not sure what comes next? /workflow-status tells you.

Define what to build

Start from an idea, or from code that already exists.

/create-prdprompt

Interviews you about the idea, a few questions at a time.

writes PRD.md

/document-existingprompt

Reads an existing codebase, then asks what the code cannot tell it.

writes PRD.md FEATURES.md RULES.md

/verify-prdprompt

Finds gaps, contradictions, and claims that cannot be built as written.

writes PRD.md PRD-REVIEW.md

Plan how to build it

Small units of work, in dependency order, with tests planned up front.

/extract-featuresprompt

Turns requirements into features with permanent IDs and MoSCoW priorities.

writes FEATURES.md

/generate-rulesprompt

Sets the standards the agent must follow, with dependency versions checked against the registry.

writes RULES.md

/generate-rfcsprompt

Splits the work into small RFCs in dependency order, then checks each one with a fresh reader.

writes RFCs/ RFCS.md

/test-strategyprompt

Plans the tests for each RFC before they are written.

writes TEST-STRATEGY.md

Build it, one RFC at a time

Plan, approve, code, prove — then review in a fresh context.

/implement-rfc <id>prompt

Plans, waits for your approval, writes the code, then runs the build and tests to prove each criterion.

writes code, RFC status

/review-rfc <id>prompt

Reviews the code against the RFC, the rules, and the test plan, in a fresh context.

writes reviews/

↻ Then the next RFC.

∗

Anytime

When requirements change, or when you lose track.

/manage-changesprompt

Checks a change against past decisions and rules, then updates every affected file together.

writes changes/

/workflow-statusprompt

Reports what is done, what has drifted, and what to do next.

read-only

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. trace-check.py fails when a citation breaks or a Must-have feature has no RFC.

One file wins

When files disagree, PRD.md wins over FEATURES.md, then RULES.md, then the RFCs — and the other file is flagged for correction.

Your agent has a plan mode. It 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.

Built-in plan mode	This workflow
Plans one task: "how do I build this?"	Plans the product: what are we building, for whom, and what is out of scope?
The plan disappears with the session	PRD, features, rules and RFCs stay — across sessions, models, tools and teammates
Takes your request at face value	Interviews you first, so decisions are written down before any code exists
Reviews code by "looks right"	Reviews against written acceptance criteria, and checks the files against each other

Use it formulti-week builds, and anything real you build with AI, where scope creep and forgotten decisions hurt more than code quality.

Skip it fora one-line fix.

Know Spec Kit or Kiro?Same idea — spec-driven development — with RFCs as the unit of work and no CLI or framework to adopt. It predates both.

Each step catches what the others cannot

Measured by building a real TypeScript library end to end with the workflow, from a real PRD — and checkable by you on the example in this repository.

12 / 13

cross-document problems found by /workflow-status in a fresh context that never saw our list. See the example

10 / 10

PRD problems found by /verify-prd on the same example — plus several we had missed.

A/B

The eval suite runs the same checks with and without the workflow, so the difference is measured, not claimed.

/verify-prd

A function contradicting the PRD's own convention; an unspecified color space; a hidden rendering dependency.

It compared the spec with the reference implementation.

RFC edge cases

That the pinned TypeScript version would break the build; a clone-aliasing bug.

It reasoned about code that did not exist yet.

/review-rfc

A geometry leak on an error path; unvalidated NaN inputs.

All 17 acceptance criteria had already passed.

/test-strategy

Normals never checked for being finite, so degenerate geometry rendered black while every test passed.

It asks which tests should exist, not which do.

/workflow-status

Two required files never created, while their RFC was reported complete.

It checked claims against the files on disk.

Fresh-reader check

An RFC that contradicted itself; a criterion that could only pass by luck.

The author had read past both, repeatedly.

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.

Works where you work

install.sh puts the skills where each tool looks for them, and never overwrites a skill you have edited.

Tool	Folder	Run a command
Claude Code	`.claude/skills/`, or the plugin	`/create-prd`
GitHub Copilot (VS Code, CLI)	`.agents/skills/`	`/create-prd`
Cursor	`.agents/skills/`	`/create-prd`, from the `/` menu
Gemini CLI	`.agents/skills/`	`/create-prd`
OpenCode	`.agents/skills/`	`/create-prd`
Devin	`.agents/skills/`	`/create-prd`
Codex	`.agents/skills/`	`$create-prd`, or pick it from `/skills`

Try it on the example first

The repo's v2.0 example looks complete, and it is not. Run /workflow-status on it and compare the report with the problems we found by hand.

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

Star on GitHub Read the example