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 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. Depending on the size and complexity of the verification, deploy one or more specialized sub-agents to handle different aspects, split as appropriate for the task. Choose sub-agents appropriate for task complexity (see CLAUDE.md for agent selection guidance—verification tasks typically need Opus, maybe Sonnet for routine verifications, never Haiku).

Establish the actual change scope before reviewing. Treat verification as read-only unless the user explicitly asks for fixes.

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).

Look beyond the immediate task. Explore the surrounding project enough to catch:

• Existing material that overlaps with or is affected by the changes
• Patterns or conventions elsewhere that the changes should respect
• Downstream consequences the author may not have considered

For code specifically, also check:

• Error handling and boundary conditions
• Thread safety or concurrency concerns (if applicable)
• Whether tests cover the new behavior adequately
• API surface changes and their impact on callers
• Whether documentation (READMEs, guides, API docs, inline comments) needs updating or creation to reflect the changes

For plans and design documents, also check:

• Whether the proposed approach accounts for known constraints and prior decisions
• Feasibility of each step and whether dependencies between steps are correctly sequenced
• Whether the plan addresses verification and rollback
• Whether documentation (READMEs, API docs, guides) needs updating or creation to reflect the changes

Focus area (optional; if empty focus on all changes/files):

$ARGUMENTS

Provide a structured report highlighting what's working, any issues or concerns, and what still needs attention. Include the checks run, checks skipped and why, and any residual risk.

Be thorough but concise. Focus on actionable findings rather than minor stylistic preferences.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: lacerbi
• Source: lacerbi/dotclaude
• License: MIT

Install and usage instructions live in the source repository linked above.