docs: add review-plan command + rules templates (inspired by Garry Tan)

Structured plan review across 4 axes (architecture, code quality, tests,
performance) as a reusable custom command with separate rules files.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

examples/rules/architecture-review.md

@@ -0,0 +1,33 @@
+---
+description: "Architecture review criteria for plan and code reviews"
+---
+
+# Architecture Review Criteria
+
+When reviewing architecture (plans or code), evaluate these dimensions:
+
+## System Design
+- Are component boundaries clear and well-defined?
+- Does each component have a single, well-understood responsibility?
+- Are interfaces between components minimal and well-documented?
+
+## Dependencies
+- Is the dependency graph acyclic and manageable?
+- Are there circular dependencies that need breaking?
+- Are external dependencies justified and up-to-date?
+
+## Data Flow
+- Is data ownership clear (which component is source of truth)?
+- Are there potential bottlenecks in the data pipeline?
+- Is data transformation happening at the right layer?
+
+## Scaling
+- What are the single points of failure?
+- Where will the system break under 10x load?
+- Are stateless and stateful components properly separated?
+
+## Security
+- Are authentication and authorization properly layered?
+- Is data access controlled at the right boundaries?
+- Are API boundaries validated (input sanitization, rate limiting)?
+- Are secrets properly managed (no hardcoded values)?

examples/rules/code-quality-review.md

@@ -0,0 +1,33 @@
+---
+description: "Code quality review criteria for plan and code reviews"
+---
+
+# Code Quality Review Criteria
+
+When reviewing code quality, evaluate these dimensions:
+
+## Organization
+- Is the module structure logical and consistent?
+- Are files in the right directories?
+- Is the naming convention consistent across the codebase?
+
+## DRY Violations
+- Flag any duplicated logic (be aggressive)
+- Identify copy-paste patterns that should be abstracted
+- Check for repeated configuration or magic values
+
+## Error Handling
+- Are errors handled at the right level (not swallowed, not over-caught)?
+- Are edge cases explicitly handled or documented as out-of-scope?
+- Do error messages provide enough context for debugging?
+- Are there silent failures (empty catch blocks, ignored return values)?
+
+## Technical Debt
+- Which areas have the highest maintenance burden?
+- Are there TODO/FIXME comments that should be addressed now?
+- Is there dead code that should be removed?
+
+## Engineering Balance
+- Are there areas that are over-engineered (premature abstraction, unnecessary complexity)?
+- Are there areas that are under-engineered (fragile, hacky, missing validation)?
+- Does the complexity match the actual requirements?

examples/rules/performance-review.md

@@ -0,0 +1,29 @@
+---
+description: "Performance review criteria for plan and code reviews"
+---
+
+# Performance Review Criteria
+
+When reviewing performance, evaluate these dimensions:
+
+## Database Access
+- Are there N+1 query patterns (loop with individual queries)?
+- Are queries using appropriate indexes?
+- Is data fetched at the right granularity (not over-fetching)?
+- Are bulk operations used where possible?
+
+## Memory
+- Are large datasets streamed rather than loaded entirely in memory?
+- Are there potential memory leaks (event listeners, unclosed connections)?
+- Is object allocation minimized in hot paths?
+
+## Caching
+- What data is expensive to compute and stable enough to cache?
+- Are cache invalidation strategies defined?
+- Is caching applied at the right layer (application, database, CDN)?
+
+## Complexity
+- Are there O(n^2) or worse algorithms that could be optimized?
+- Are hot paths identified and optimized?
+- Is unnecessary work being done (redundant computations, unused data transforms)?
+- Are expensive operations deferred or lazy-loaded where possible?

examples/rules/test-review.md

@@ -0,0 +1,29 @@
+---
+description: "Test review criteria for plan and code reviews"
+---
+
+# Test Review Criteria
+
+When reviewing tests, evaluate these dimensions:
+
+## Coverage Gaps
+- Are there untested public functions or API endpoints?
+- Is there unit, integration, AND e2e coverage where appropriate?
+- Are critical paths (auth, payments, data mutations) fully tested?
+
+## Test Quality
+- Do assertions test behavior, not implementation details?
+- Are test descriptions clear about what they verify?
+- Do tests fail for the right reasons (not brittle/flaky)?
+- Is each test independent (no shared mutable state)?
+
+## Edge Cases
+- Are boundary values tested (empty, null, max, negative)?
+- Are error paths tested (network failures, invalid input, timeouts)?
+- Are race conditions and concurrent access scenarios covered?
+
+## Failure Modes
+- What happens when external services are unavailable?
+- Are retry and fallback mechanisms tested?
+- Do tests verify graceful degradation?
+- Are error messages and status codes correct for each failure?