review-and-refactor-code

Review and Refactor Code

Find defects that matter, distinguish them from optional design improvements, and change structure only after an approved proposal.

Trigger boundary

Use this skill for:

• reviewing a branch, commit, pull request, working-tree diff, or bounded code area;
• identifying defects introduced by a change and tracing affected consumers;
• assessing whether a structural refactor is justified and feasible;
• planning or performing behavior-preserving decomposition, deduplication, or boundary cleanup.

Do not trigger for:

• broad architecture, ownership, or blast-radius mapping without a defined review/refactor decision - use repository-intelligence;
• a concrete failure whose cause is unknown - use debugging-investigator;
• dependency, framework, runtime, schema, or public API transitions - use codebase-evolution-controller;
• security as the primary review decision - use the applicable security review workflow;
• a platform-wide web or mobile production audit - use the relevant builder;
• deciding whether an integrated candidate can ship - use verification-and-release.

Required inputs

Obtain or state:

1. repository root and current working-tree state;
2. review or refactor scope, including base/head refs when diff-driven;
3. intended behavior, contracts, and acceptance criteria;
4. generated, vendored, migration, or lockfile boundaries;
5. relevant tests, build commands, and known baseline failures;
6. compatibility, performance, security, and operational constraints;
7. whether the user has approved a previously proposed edit batch.

If scope is too broad to support file-level evidence, select a bounded slice and explain the coverage limit.

Safety baseline

• Inspect repository state before analysis. Preserve uncommitted and unrelated user work.
• Do not checkout, reset, clean, stash, regenerate, reformat broadly, or install dependencies during review.
• Treat review, refactor, cleanup, and improvement requests as analysis authorization only at first.
• Do not edit repository files until the user separately approves a concrete proposal produced by this skill.
• Limit approval to the named files, invariants, slices, and verification plan. Re-propose materially different work.
• Never label style preference, hypothetical risk, or missing proof as a defect.
• Do not remove pre-existing dead code unless it is inside the approved scope and its replacement is verified.