review-implementation

name

review-implementation

description

Post-implementation review. Spins up three read-only critics on a completed task's diff — cleaner-architecture, slop-defender, reusability-inspector — that push back ONLY on real issues. Autonomous runs apply safe fixes (tests-green-gated) and write everything to review.md next to progress-tracker.md; interactive runs present findings to pick. Use after a task's missions are done (from start-task / start-roadmap / create-task) or standalone on a diff.

Review Implementation (post-implementation)

Review a completed task's diff through three lenses, each a read-only critic subagent. The counterpart to ../critique-plan/SKILL.md: that guards the plan before coding; this guards the result after.

Silence is the default output. A clean diff produces no findings — that is the normal case. A finding survives only if a senior engineer, looking at this diff, would actually make the change. State each as a concrete cost, not a preference. Never invent refactors to look thorough.

ALWAYS check .ab-method/structure/index.yaml FIRST for paths (task location, domain model, review.md). Review only what this task changed — the cohesive diff across its missions (git diff for the commit range). This is not a whole-codebase audit; that's /improve-codebase-architecture.

Process

1. Gather diff + context

The changed files and their git diff, plus (read only what exists): UBIQUITOUS_LANGUAGE.md / CONTEXT.md (canonical terms, spotting reinvented concepts), docs/architecture/* (the documented way things are built here), docs/adr/ (don't propose what an ADR settled), and the task's if it has one.