doublecheck

Context

• Branch and files: !git status --short --branch
• Unstaged changes: !git diff
• Staged changes: !git diff --cached

The injected diffs cover working-tree changes. If a diff was too large to inline and arrived as a file path with a preview, read that file (or have reviewers run git diff themselves). If relevant work was committed during this conversation, inspect the corresponding commit or branch diff too. Focus on work from this conversation unless otherwise specified; unrelated changes may belong to the user or another agent.

Your Task

Perform a meticulous verification and comprehensive review of all work done. Establish the actual change scope before reviewing. Treat verification as read-only unless the user explicitly asks for fixes.

Deploy one or more fresh-context Opus reviewers (see Agent Selection in the global CLAUDE.md, including the one-heavy-compute-agent rule), split by aspect as the size and complexity of the change warrant. Review directly yourself only when the change is so small that a reviewer would add nothing: the point of this skill is a review by agents that did not do the work and don't share its assumptions. A fresh-context reviewer knows nothing of this conversation, so brief each one with: the original goals and requirements, its exact scope (files, commits, or the plan file), what counts as a finding (below), and the report format (below).

Verify that:

• All changes align with the original goals and requirements
• Modifications preserve file integrity and correctness
• Nothing is missing or requires additional updates
• Changes work coherently together

Deeper Review

Go beyond surface-level correctness. Evaluate the work for:

• Completeness: Are all requirements addressed? Are there gaps, missing scenarios, or implicit expectations left unhandled?
• Correctness: Does the logic hold? Are there subtle errors, flawed assumptions, or reasoning gaps?
• Consistency: Do the changes match the provided or discussed specs? Do they follow the conventions and patterns already established in the project?
• Structural integrity: Is the work well-organized? Watch for unclear boundaries, redundancy, or unnecessary entanglement between parts that will make future changes harder.
• Consolidation: Flag spaghettification—duplicated logic, parallel structures doing similar things, components that could be merged or reused. In code: identify candidates for shared functions, similar modules that could be unified, redundant abstractions. In plans/docs: overlapping sections, repeated concepts, restated prerequisites or duplicated steps. Report what you find; do not refactor.
• Hazard avoidance: Identify footguns—things that look correct now but will mislead or break later (e.g., ambiguous naming, brittle assumptions, implicit dependencies, information that will drift out of sync).