Tidy
Apply simplifications inside the current diff and incorporate actionable review findings. A clean diff may need no edits. For a read-only report use pr-reviewer; wider architectural changes belong to codebase-architecture.
Workflow
- Record the staged and unstaged scope, or the requested branch range, plus existing edits. Use applicable project instructions and check results already available at this revision.
- Inspect the relevant angles below. Reuse prior findings; do not repeat a full review simply because a different command produced it. Work locally by default. Delegation is useful only for substantial independent scopes supported by the host.
- Merge findings by root cause, discard false positives, and apply the smallest complete fixes. Correctness fixes precede simplification; ownership fixes precede polishing code they remove.
- Run checks affected by the changes, plus repository-required gates. Preserve exit codes and distinguish baseline failures. Report applied changes, material deferred decisions, and check results.
Review angles
| Angle | Distinctive question | Evidence for a change |
|---|---|---|
| Reuse | Does this code need to exist, or does a live repository helper, stdlib, platform feature, or installed dependency cover it? | Existing contract and call site, including the boundary cases it handles |
| Quality | Does this introduce a second owner of state, an unused extension point, or unnecessary compatibility? | Actual consumers and state ownership, not line count alone |
| Efficiency | Does this add repeated work on a real hot path? | Call frequency, duplicate reads, unbounded retention, or a defeated no-change signal |
| Ownership | Is a caller patch compensating for a shared mechanism, or placed outside the subsystem that owns this behavior? | Writers, callers, and adjacent implementations; the deeper fix must be smaller than the special case |
| Test value | Can the test fail for a reason someone would act on? | A named regression, reachable branch, or public contract; literal diff mirrors and mock echoes add no assurance |
Constraints that earn their place
- Guard deletion requires system evidence. Before removing a fallback, retry, lock, or validation, identify the writers, reachable states, staleness tolerance, and recovery owner. A guard that looks redundant locally can protect another caller. If its state cannot be ruled out, retain it and report the uncertainty.
- Prior reviews are input, not authority. Apply supported findings. If current evidence refutes a prior finding, explain why it was not applied; do not blindly implement it because the report called it confirmed.
- No whole-file rollback of unrelated edits. Scope formatters. If a formatter causes churn, remove only changes introduced by this run;
git restore <path>can discard the user's earlier edits in the same file. - No abstraction quota. Fewer lines is not a win if it hides different lifecycles or drops behavior. An existing owning subsystem is stronger evidence than a preferred generic pattern.
- Tests follow risk. Add or update a regression check when the edit changes behavior that can independently regress. Do not require tests for copy, a literal config change, or framework behavior already covered elsewhere.
- Stop on evidence, not ceremony. Once affected checks pass, repeat only for new changes, failures, or unresolved concerns. A second pass that keeps adding guards to the same spot calls for revisiting the mechanism.
Output
Summarize what changed and why, checks and their results, and any substantial fix requiring a broader scope. Omit empty sections and "no findings" entries for every angle. Leave commits and PR creation to the user's request or pr-creator.
Maintenance only: evals/evals.json contains regression scenarios for changes to this skill; it does not load during a user task.
