/generate-rfcs

description: Break the PRD into sequential implementation RFCs

You are an expert software architect and project manager tasked with breaking down the Product Requirements Document (PRD.md), features list (FEATURES.md), and project rules (RULES.md) — or the documents provided in the conversation — into manageable Request for Comments (RFC) documents for implementation.

Create a set of well-structured RFC documents that divide the project into logical, implementable units of work. Each RFC should represent a cohesive, reasonably-sized portion of the application that can be implemented as a unit.

**IMPORTANT: RFCs are numbered in a valid implementation order, and the ordering is critical. Each RFC must be fully implementable once its declared predecessors are complete.**

If any critical information is missing or unclear, ask specific questions before proceeding.

SCOPE THE CHECKLIST TO THE PRODUCT TYPE

First classify the product: web app · mobile app · library/SDK · CLI · service/API · data pipeline · game.

Apply only the sections and checks that fit that type. For a library/SDK, skip infrastructure, scalability, regulatory, business-model, accessibility, responsive-design, state-management, and auth concerns -- instead probe: public API surface and consistency, semver/deprecation policy, peer-dependency ranges, bundle size, tree-shaking, types quality, the public/internal boundary, and mutation of caller-owned data. Every other product type has its own equivalents; work them out before applying the generic list below.

State which product type you classified and which checks you skipped. Skipping must be visible and auditable, never silent -- a generated "no SQL injection vectors identified" in a library that has no SQL manufactures false confidence.

This applies per RFC as well as to the set: do not emit a "Database Schema Changes" or "State Management" section in every RFC of a product that has neither.

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.

Generate the RFC files under an RFCs folder by:

1. IMPLEMENTATION ORDER ANALYSIS:

• Analyze the entire project to determine the optimal implementation sequence
• Identify foundation components that must be built first
• Create a directed graph of feature dependencies (described textually)
• Determine critical path items that block other development
• Assign sequential numbers (001, 002, 003, etc.) reflecting a valid topological order of that graph
• **CRITICAL**: Each RFC must be fully implementable once its DECLARED PREDECESSORS are complete -- not necessarily all lower-numbered RFCs. State each RFC's true predecessors, so a team can parallelize independent branches while a solo implementer simply follows the numbers in order.

2. FEATURE GROUPING:

• Group related features that should be implemented together in a single RFC
• Ensure each RFC represents a logical, cohesive unit of functionality
• Balance RFC size -- not too small (trivial) or too large (unmanageable)
• Consider dependencies between features when grouping
• Identify shared components that multiple features depend on

3. RFC STRUCTURE: Each RFC should include:

• Unique identifier reflecting implementation order (e.g., RFC-001-User-Authentication)
• Summary of what the RFC covers
• All features/requirements addressed
• Technical approach and architecture considerations
• Which previous RFCs this builds upon and which future RFCs build on this
• Relative complexity estimate (Low, Medium, High)
• Acceptance criteria for each feature
• API contracts or interfaces exposed
• Data models and database schema changes
• Implementation details: file structure, key algorithms, UI/UX specs, state management, API integration, error handling, and testing strategy
• Every file, behavior and constraint mentioned anywhere in the RFC MUST also appear in the acceptance criteria. In practice the acceptance criteria are the spec and everything else is commentary: anything named in prose but absent from the criteria is effectively optional and will not get built. Cross-check the file-structure section against the criteria before finishing

4. IMPLEMENTATION CONSIDERATIONS:

• Technical challenges and potential edge cases
• Applicable rules from RULES.md
• Testing approaches for the functionality
• Performance, security, and accessibility requirements
• Third-party dependencies or libraries needed
• Error handling strategies and fallback mechanisms

5. IMPLEMENTATION HANDOFF:

• Note in RFCS.md that each RFC is implemented by running `/implement-rfc <id>`
• Do not generate per-RFC implementation prompt files. They duplicate that command and drift from it as soon as it is improved

6. RFCS.MD CREATION:

• Create a master RFCS.md listing all RFCs in implementation order
• Include a dependency table showing relationships between RFCs
• Provide a clear implementation roadmap
• For each RFC, indicate predecessors and successors

7. TECHNICAL SPECIFICATIONS: For each RFC, provide:

• Component architecture and data flow diagrams (described textually)
• Specific algorithms or business logic pseudocode
• Error codes and handling mechanisms
• Logging and monitoring requirements
• Authentication/authorization and caching strategies where applicable

8. IMPLEMENTATION CONSTRAINTS:

• Required coding standards and patterns
• Performance budgets or requirements
• Compatibility requirements (browsers, devices, etc.)
• Regulatory or compliance considerations

First, provide a brief overview of your breakdown approach and the sequential