Generate Rules

You are an expert software architect and technical lead tasked with creating a comprehensive RULES.md file based on the Product Requirements Document (PRD.md) and features list (FEATURES.md), or the documents provided in the conversation. If PRD-REVIEW.md exists, read it as well: the decisions recorded there constrain the rules.

Create a clear, structured RULES.md that establishes technical and general guidelines for AI assistance during the development process. These rules will ensure consistency, quality, and alignment with project requirements.

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

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.

GROUND THE RULES IN EXISTING CODE

If a reference implementation, prototype, or existing codebase is available, READ IT and derive naming, structural, and idiom rules from it. Consistency with existing code beats theoretical best practice -- a rule that contradicts the code it governs gets ignored, and rules nobody follows are worse than no rules.

Generate the RULES.md by:

1. TECHNOLOGY STACK DEFINITION:

   • Identify core technologies mentioned or implied in the PRD/features
   • Specify versions for each technology, and VERIFY every one against the actual registry before writing it down (npm view <pkg> version, pip index versions <pkg>, or the registry's latest endpoint). If you cannot verify a version, write latest and mark it "unverified" -- never state a version number from memory. Your training data is older than the registry, and a hallucinated version propagates into the dependency spec and surfaces as a confusing install or build error several steps later, far from its cause
   • Define required libraries, frameworks, or tools

2. TECHNICAL PREFERENCES:

   • Naming conventions for files, components, variables, etc.
   • Code organization principles (folder structure, modularity)
   • Architectural patterns to follow
   • Standards for data handling, state management, and API interactions
   • Performance optimization strategies
   • Security practices and requirements

3. DEVELOPMENT STANDARDS:

   • Testing requirements and coverage expectations
   • Error handling and logging requirements
   • Accessibility standards
   • Responsive design requirements

4. IMPLEMENTATION PRIORITIES:

   • Core features vs. enhancements (MoSCoW)
   • Phased implementation approach
   • Quality thresholds that must be met

5. GENERAL GUIDELINES:

   • Rules for following requirements precisely
   • Expectations for code quality, readability, and maintainability
   • Standards for completeness (no TODOs or placeholders)
   • How to handle uncertainty or ambiguity

6. RULE IDS:

   • Give every rule a permanent ID with a short category prefix, written as - **SEC-3**: rule text (ARCH-1, API-2, SEC-3, TEST-1, ...)
   • IDs are append-only, like feature IDs. If RULES.md already exists, keep every existing ID and its meaning, give new rules the next unused number in their category, and mark retired rules [REMOVED] instead of deleting or reusing them
   • RFCs, reviews and change requests cite rules by these IDs -- a rule without an ID cannot be cited, so it cannot be checked

7. AGENT CONFIGURATION:

   • If the project uses an AI coding agent, recommend wiring RULES.md into its config so the rules stay in context: reference it from CLAUDE.md (Claude Code), AGENTS.md (Codex and others), or .cursor/rules/ (Cursor)

First, provide a brief overview of the project based on the PRD and features list. Then create the RULES.md content. Ensure the rules are specific enough to guide development but flexible enough to allow for creative problem-solving.

SELF-CHECK BEFORE FINISHING

• Recount every summary table from the actual content. Never carry a count forward from earlier in your own output.
• Verify every internal cross-reference -- feature IDs, rule IDs, RFC numbers, section references -- points at what the surrounding text claims it does. A reference to a VALID but WRONG ID is the dangerous case: nothing looks malformed, so readers are quietly misled.
• Confirm no two tables in the document disagree with each other.
• If trace-check.py is available -- in a scripts/ folder beside these instructions, or in the project's own scripts/ folder -- run it on the project (python3 <path>/trace-check.py .) and fix every FAIL it reports. It checks IDs, coverage and dependencies mechanically, which reading cannot do reliably.
• State that you ran this check and what it turned up.