/arn-code-review-implementation

name: arn-code-review-implementation
description: >-
  This skill should be used when the user says "review implementation", "review
  the project", "check implementation", "quality review", "validate
  implementation", "implementation review", or wants a post-execution quality gate to verify that the
  implementation follows the project's stored code and testing patterns and
  matches the plan. Reports issues as ERRORS, WARNINGS, INFO with a verdict.
  Do NOT use this for reviewing PRs (use arn-code-review-pr) or validating plans
  (use arn-code-review-plan).
version: 1.0.0

Arness Review Implementation

Post-execution quality gate that verifies an implementation matches the project plan and follows the stored code patterns, testing patterns, and architecture documentation. Reports issues classified as ERRORS, WARNINGS, and INFO, with a final verdict.

Pipeline position:

arn-code-init -> arn-code-feature-spec / arn-code-bug-spec -> arn-code-plan -> arn-code-save-plan -> arn-code-review-plan -> arn-code-taskify -> arn-code-execute-plan -> **arn-code-review-implementation**

This is a self-contained review -- it does not invoke sub-agents. The review is a structured, checklist-driven process: read code, compare to patterns, classify findings.

**When to Use:**

• After `arn-code-execute-plan` completes
• To verify that implementation matches the plan and follows stored patterns
• Before considering the project done
• **Optional** -- skip for small/straightforward projects; recommended for 3+ phases, multiple modules, or critical features

Prerequisites

If no `## Arness` section exists in the project's CLAUDE.md, inform the user: "Arness is not configured for this project yet. Run `/arn-implementing` to get started — it will set everything up automatically." Do not proceed without it.

Workflow

Step 1: Load the Project

1. Read the project's CLAUDE.md and extract the `## Arness` section to find:

• Plans directory path
• Code patterns directory path

2. Ask for `PROJECT_NAME` if not provided in the trigger message 3. Read all project artifacts:

• `<project-folder>/INTRODUCTION.md` -- codebase patterns that should have been followed
• All reports in `<project-folder>/reports/` -- what was implemented, tested, bugs fixed
• All phase plans in `<project-folder>/plans/` -- acceptance criteria, expected files, expected patterns

4. Read stored pattern documentation:

• `<code-patterns-dir>/code-patterns.md`
• `<code-patterns-dir>/architecture.md`
• `<code-patterns-dir>/testing-patterns.md`
• `<code-patterns-dir>/ui-patterns.md` (if it exists)
• `<code-patterns-dir>/security-patterns.md` (if it exists)

5. Build a review checklist from these sources: files that should exist, patterns that should have been applied, features that were planned, tests that should pass

---

Step 2: Plan Compliance Review

Compare the plan artifacts (phase plans, INTRODUCTION.md) with the execution reports (implementation reports, testing reports). Run these checks:

| Check | Severity | What | |-------|----------|------| | PC01 | ERROR | Every feature listed in phase plans has a matching entry in implementation reports | | PC02 | ERROR | Every test case listed in phase plans has a matching entry in testing reports | | PC03 | WARNING | All acceptance criteria from phase plans are addressed in reports | | PC04 | WARNING | Files listed in `filesCreated`/`filesModified` in reports actually exist on disk | | PC05 | INFO | Features implemented that were NOT in the original plan (scope creep detection) | | PC06 | ERROR | Any `bugsFixed` entries -- read the changed files to verify the fix was correct | | PC07 | WARNING | Testing pass rate below 100% -- investigate remaining failures |

---

Step 3: Pattern Compliance Review (Dynamic)

All checks in this step are generated dynamically from stored pattern documentation. This is NOT a hardcoded checklist -- the checks are derived at runtime from whatever patterns are documented for this project.

**Code Pattern Compliance:**

Read `code-patterns.md`. For each documented pattern: 1. Identify implementation files where this pattern should apply (from reports + pattern context) 2. Read the relevant files 3. Check whether the implementation follows the documented pattern 4. Generate findings with these severity levels:

• `CP-[PatternName]-CONFLICT` (ERROR) -- implementation contradicts the documented pattern
• `CP-[PatternName]-MISSING` (WARNING) -- pattern should apply but wasn't followed
• `CP-[PatternName]-APPLY` (WARNING) -- general deviation from the pattern

**Architecture Compliance:**

Read `architecture.md`. Check that:

• Component boundaries are respected (no cross-boundary violations)
• Integration points match the documented architecture
• Architectural decisions from INTRODUCTION.md are reflected in the implementation

**UI Pattern Compliance (if `ui-patterns.md` exists):**

Read `ui-patterns.md`. For each documented pattern: 1. Identify implementation files where this pattern should apply (frontend components, pages, layouts) 2. Read the relevant files 3. Check whether the implementation follows the documented UI pattern 4. Generate findings:

• `UP-[PatternName]-CONFLICT` (ERROR) -- implementation contradicts the documented UI pattern (e.g., wrong component library)
• `UP-[PatternName]-MISSING` (WARNING) -- UI pattern should apply but wasn't followed
• `UP-[PatternName]-ACCESSIBILITY` (WARNING) -- accessibility requirements documented but not implemented

**Testing Pattern Compliance:**

Read `testing-patterns.md`. For each documented pattern: 1. Identify test files from testing reports 2. Read the test files 3. Check correct usage of the documented test framework, markers, fixtures, and helpers 4. Generate findings:

• `TP-[PatternName]-FRAMEWORK` (ERROR) -- wrong test framework or runner used
• `TP-[PatternName]-FIXTURES` (WARNING) -- should use documented fixtures but doesn't

-