platonic-code-review

Use this skill when you need to:

• Verify code implementation matches RFC specifications
• Validate feature completeness against requirements
• Check consistency between specs and actual code
• Identify gaps where specs exist but implementation is missing
• Find discrepancies where code behavior differs from specs
• Audit compliance with documented design decisions

Keywords: spec compliance, implementation validation, requirement verification, consistency check, gap analysis

This is NOT a general code quality reviewer. It specifically focuses on:

✅ Spec-to-Code Consistency: Does the code implement what the specs describe?

✅ Completeness: Are all specified features implemented?

✅ Correctness: Does the implementation match spec requirements?

✅ Gap Identification: What's specified but not implemented?

✅ Discrepancy Detection: Where does code differ from specs?

By Default: Generates review report without modifying code

• Creates detailed report of findings
• Highlights inconsistencies and gaps
• Provides actionable recommendations
• Does NOT make code changes automatically

To Modify Code: User must explicitly request code modifications

The standard review process follows these steps:

Step 1: Understand Specifications

• Locate and read relevant specification documents

- RFC documents (rfc-*.md)

- Requirements documents

- Design documents

- API specifications

• Extract key requirements and expected behaviors
• Identify testable criteria

Step 2: Generate Functionality Checklist

Create a comprehensive checklist from specs:

• List all specified features
• List all specified behaviors
• List all API endpoints/interfaces
• List all data structures
• List all business rules
• List all constraints and validations

Step 3: Map Specs to Code

Identify code locations implementing each spec:

• Find relevant files and modules
• Map features to implementation
• Identify entry points and key functions
• Understand code structure

Step 4: Review Implementation Against Specs

For each checklist item:

• Status: ✅ Implemented / ⚠️ Partial / ❌ Missing / 🔍 Unclear
• Consistency: Does implementation match spec?
• Completeness: Are all aspects implemented?
• Correctness: Does it work as specified?
• Evidence: Specific code references

Step 5: Identify Discrepancies

Document inconsistencies:

• Implementation differs from spec
• Missing features specified but not implemented
• Extra features implemented but not specified
• Incorrect behavior doesn't match spec requirements
• Incomplete implementation partially done

Step 6: Generate Review Report

Create structured report with:

• Executive summary
• Functionality checklist with status
• Detailed findings (consistent, inconsistent, missing)
• Code references for each finding
• Prioritized recommendations
• Suggested actions (ask user before implementing)

Beyond the basic procedure, this skill can:

Validation Levels

Level 1: Basic Compliance

• Check if major features are implemented
• Verify core functionality exists

Level 2: Detailed Verification

• Validate all specified behaviors
• Check edge cases and error handling
• Verify data structures and interfaces

Level 3: Comprehensive Audit

• Deep dive into implementation details
• Compare algorithms and approaches
• Validate performance requirements
• Check all specified constraints

Cross-Reference Analysis

• Bi-directional Check:

- Specs → Code (what's missing in code?)

- Code → Specs (what's not documented?)

• Dependency Validation:

- Check if dependencies match specs

- Verify integration points

• Version Alignment:

- Ensure code version matches spec version

- Track changes across versions

Test Coverage Integration

• Compare test cases with spec requirements
• Identify untested specified behaviors
• Suggest test scenarios based on specs
• Validate test coverage completeness

Reviews generate structured reports:

```markdown

# Spec-to-Code Review Report

• Specifications Reviewed: X
• Code Modules Reviewed: Y
• Consistency Rate: Z%

• ✅ Fully Implemented: A items
• ⚠️ Partially Implemented: B items
• ❌ Not Implemented: C items
• 🔍 Unclear/Needs Investigation: D items

[Items where code contradicts specs]

[Specified features not found in code]

[Code features not in specs]

[Prioritized actions - ASK USER before modifying code]

```

Example 1: Basic Spec Review

```

Use platonic-code-review to review the implementation of

rfc-001-user-authentication.md in the src/auth/ directory.

Generate a report showing what's implemented and what's missing.

```

Example 2: Comprehensive Module Review

```

Use platonic-code-review to conduct a comprehensive review

of the entire API implementation against all RFCs in ./specs/.

Focus on API endpoints, data structures, and error handling.

```

Example 3: Feature Completeness Check

```

Use platonic-code-review to verify that all features

specified in rfc-005-payment-processing.md are fully

implemented in src/payments/. Generate a detailed checklist.

```

Example 4: Gap Analysis

```

Use platonic-code-review to perform a gap analysis between

./specs/ and ./src/, identifying specifications without

implementations and implementations without specifications.

```

Default: Report Only

⚠️ This skill generates reports by default and does NOT modify code

When inconsistencies are found:

1. Document the issue in the report
2. Provide specific code references
3. Explain the discrepancy
4. Recommend actions
5. ASK USER if they want code modifications

When to Modify Code

Only modify code when user explicitly requests:

• "Fix the inconsistencies you found"
• "Update the code to match the specs"
• "Implement the missing features"

Otherwise, default to report generation only.

Works well with:

• platonic-code-specs: Review code against RFCs managed by this skill
• Documentation skills: Generate docs from review findings
• Testing skills: Create tests for missing coverage

• Read access to specification documents (RFCs, requirements, design docs)
• Read access to source code
• Understanding of project structure
• Write access only if user requests code modifications

1. Start with specs: Always read and understand specs first
2. Be thorough: Check all specified requirements systematically
3. Be specific: Provide exact file names, line numbers, and code references
4. Be objective: Report facts, not opinions
5. Prioritize findings: Critical issues first, minor ones later
6. Ask before modifying: Never change code without user consent

See [references/REFERENCE.md](references/REFERENCE.md) for detailed review procedures and examples.