/review-rfc

name: review-rfc
description: "Review an implemented RFC in a fresh context against its acceptance criteria, RULES.md and the test plan, and save the review to reviews/."
argument-hint: "<rfc-id>"
context: fork
agent: general-purpose
metadata:
  source: "https://github.com/nurettincoban/ai-prd-workflow"
  version: "3.0.0"
  checksum: "sha256:d09031cde2a96a96151860bd2c4f067c7c6b817a2f82e7da193cfd25f5e6a31d"

Target RFC ID: "$ARGUMENTS" -- if that still reads as a literal placeholder, use the RFC ID from my message instead. Substitute it for [ID] everywhere below. If no ID was given, ask which RFC to work on before doing anything else.

**Fresh eyes first.** If this conversation already contains the implementation of this RFC -- you wrote or edited that code here -- stop now. Tell the user to run this review in a new session, ideally on a different model, and do nothing else. A reviewer holding the author's reasoning reads past the same gaps the author did, and the RFC, RULES.md, FEATURES.md and TEST-STRATEGY.md contain everything a reviewer needs -- that is the point of them.

You are an expert code reviewer tasked with reviewing an implementation against its RFC specification and project standards.

Review the implementation of the specified RFC and provide a thorough, actionable assessment. Your review should catch bugs, security issues, and deviations from the specification before the code is merged.

Inputs

• PRD.md for the Product Type section
• RFCS.md for the RFC's declared predecessors and current status
• The RFC being reviewed: `RFCs/RFC-[ID]-*.md`, including its `## Implementation Notes`
• The implementation code
• RULES.md for project standards
• FEATURES.md for requirement traceability
• TEST-STRATEGY.md for the tests planned for this RFC -- a planned test that does not exist is a finding

WHEN ARTIFACTS CONFLICT

Order of authority: PRD.md > FEATURES.md > RULES.md > RFCs > generated plans. Where this prompt's generic guidance conflicts with RULES.md, RULES.md wins -- it was written for this project and this prompt was not. Never resolve a contradiction between two artifacts silently: state it, say which one you followed and why, and flag the other for correction.

STEP 0: RUN IT

Before assessing anything, run the project's build, typecheck, and test suite. Paste the actual output. Then verify each acceptance criterion has a test that would FAIL if the behavior regressed -- a passing suite is not evidence that the criteria are covered. Reading code cannot distinguish "this test asserts the right thing" from "this test passes."

If you cannot execute commands in this environment, say so explicitly and mark every verdict below as unverified rather than assessing by reading alone.

PRODUCT TYPE

Read the **Product Type** section of PRD.md and apply only the checks that fit that type; state which checks you skipped and why. Skipping must be visible, never silent. If PRD.md has no such section, classify the product yourself (web app · mobile app · library/SDK · CLI · service/API · data pipeline · game), say that you did, and recommend running `/verify-prd` so the classification is recorded once for every later step.

Review Dimensions

Mark an inapplicable dimension N/A with one line of reasoning. Do not fill it with reassuring findings.

1. RFC ADHERENCE

• Read the RFC's `## Implementation Notes` first. A recorded, approved deviation is not a defect, but judge whether its reasoning holds. A deviation that is not recorded there is a finding
• Does the implementation satisfy all acceptance criteria in the RFC?
• Are there missing features that should have been implemented?
• Are there extra features implemented that are not in scope?
• Do API contracts match the RFC specifications?

2. RULES COMPLIANCE

• Does the code follow all standards defined in RULES.md?
• Are naming conventions, architecture patterns, and folder structure correct?
• Are error handling and logging standards met?

3. SECURITY

• Input validation and sanitization
• Authentication and authorization correctness
• Data exposure risks (sensitive data in logs, responses, or errors)
• Protection against common vulnerabilities (injection, XSS, CSRF)

4. PERFORMANCE

• Unnecessary computations, database calls, or API requests
• Missing caching opportunities
• N+1 query problems or unbounded data fetching
• Scalability concerns under load

5. MAINTAINABILITY

• Code readability and organization
• Appropriate test coverage
• Proper separation of concerns
• Dead code or unused imports

Output Format

For each review dimension, provide:

• **Verdict**: PASS / NEEDS WORK / FAIL
• **Findings**: Specific issues with file and line references
• **Suggestions**: Concrete fixes or improvements

Then provide:

• **Overall Risk Level**: Low / Medium / High / Critical
• **Summary**: 2-3 sentence overall assessment
• **Blocking Issues**: Issues that must be fixed before merge (if any)
• **Improvement Suggestions**: Non-blocking recommendations for better code quality

Save the complete review to `reviews/REVIEW-RFC-[ID].md`. If that file already exists, append this review as a new `## Round N -- <date>` section instead of overwriting it: the earlier rounds record what was found and fixed, and a re-review is judged against them. Then set the RFC's Status in RFCS.md to Reviewed, or to Changes requested if any blocking issue remains. A review that exists only in chat leaves the next session looking at fixed code with no record of what was checked, what was found, or what was consciously accepted as non-blocking -- and `/workflow-status` looks for this file when reporting whether an RFC has actually been reviewed.