blueprint-generate-rules

created	"2025-12-16T00:00:00.000Z"
modified	"2026-05-09T00:00:00.000Z"
reviewed	"2026-05-03T00:00:00.000Z"
description	Generate project-specific rules from PRDs with path-scoped frontmatter. Use when auto-creating architecture, testing, or quality rules from docs/prds/.
allowed-tools	Read, Write, Glob, Bash, AskUserQuestion
name	blueprint-generate-rules

Generate project-specific rules from Product Requirements Documents.

When to Use This Skill

Use this skill when...	Use alternative when...
Need to generate rules from existing PRDs	Use /blueprint:rules to manually create/edit rules
Want path-scoped rules for specific file types	Use /blueprint:claude-md for general project instructions
Automating rule creation from requirements	Writing custom rules without PRD reference
Extracting architecture/testing patterns from PRDs	Need to create one-off rules for specific contexts

Rules are generated to the directory configured in structure.generated_rules_path (defaults to .claude/rules/ when the field is absent). Rules with paths frontmatter are loaded conditionally when working on matching files.

Steps

Prerequisites:

• docs/prds/ directory exists
• At least one PRD file in docs/prds/

0. Resolve the output path:

   Read structure.generated_rules_path from docs/blueprint/manifest.json (default .claude/rules/):

   RULES_DIR=$(jq -r '.structure.generated_rules_path // ".claude/rules/"' docs/blueprint/manifest.json)
   mkdir -p "$RULES_DIR"
   

   Use $RULES_DIR for all subsequent reads/writes. This isolates blueprint-managed rules from any hand-written files in the parent .claude/rules/ directory (issue #1043).

1. Find and read all PRDs:

   • Use Glob to find all .md files in docs/prds/
   • Read each PRD file
   • If no PRDs found, report error and suggest writing PRDs first

2. Check for existing generated rules:

   ls "$RULES_DIR" 2>/dev/null
   

   • Scope conflict checks to files under $RULES_DIR only — never to the parent .claude/rules/. Hand-written files outside $RULES_DIR are invisible to this check.
   • If rules exist, check manifest for content hashes
   • Compare current content hash vs stored hash
   • If modified, offer options: overwrite, skip, or backup

3. Analyze PRDs and extract (aggregated from all PRDs):

   Architecture Patterns:

   • Project structure and organization
   • Architectural style (MVC, layered, hexagonal, etc.)
   • Design patterns
   • Dependency injection approach
   • Error handling strategy
   • Code organization conventions
   • Integration patterns

   Testing Strategies:

   • TDD workflow requirements
   • Test types (unit, integration, e2e)
   • Mocking patterns
   • Coverage requirements
   • Test structure and organization
   • Test commands

   Implementation Guides:

Important:

• Rules should be markdown files with clear headings
• Keep rule content specific and focused
• Include code examples to make patterns concrete
• Reference PRD sections for traceability
• Rules should be actionable, not just documentation

Error Handling:

• If no PRDs found -> Guide user to derive plans first (/blueprint:derive-plans)
• If PRDs incomplete -> Generate rules with TODO markers for missing sections
• If rules already exist and modified -> Offer to backup before overwriting