/simplify
/simplify → 4 cleanup agents in parallel → apply the fixes
You are improving the quality of the changed code, not hunting for bugs. Review
it for reuse, simplification, efficiency, and altitude issues, then fix what you
find. Do not look for correctness bugs — that is what /code-review is for.
Phase 0 — Gather the diff
Run git diff @{upstream}...HEAD (or git diff main...HEAD / git diff HEAD~1
if there's no upstream) to get the unified diff under review. If there are
uncommitted changes, or the range diff is empty, also run git diff HEAD and
include the working-tree changes in scope — the review often runs before the
commit. If a PR number, branch name, or file path was passed as an argument,
review that target instead. Treat this diff as the review scope.
Phase 1 — Review (4 cleanup agents in parallel)
Launch 4 independent review agents via the Agent tool, all in a
single message so they run concurrently. Pass each agent the diff and one of
the four angles below. Each returns its findings with file, line, a
one-line summary, and the concrete cost (what is duplicated, wasted, or
harder to maintain).
Reuse
Flag new code that re-implements something the codebase already has — Grep shared/utility modules and files adjacent to the change, and name the existing helper to call instead.
Simplification
Flag unnecessary complexity the diff adds: redundant or derivable state, copy-paste with slight variation, deep nesting, dead code left behind. Name the simpler form that does the same job.
Efficiency
Flag wasted work the diff introduces: redundant computation or repeated I/O, independent operations run sequentially, blocking work added to startup or hot paths. Also flag long-lived objects built from closures or captured environments — they keep the entire enclosing scope alive for the object's lifetime (a memory leak when that scope holds large values); prefer a class/struct that copies only the fields it needs. Name the cheaper alternative.
Altitude
Check that each change is implemented at the right depth, not as a fragile bandaid. Special cases layered on shared infrastructure are a sign the fix isn't deep enough — prefer generalizing the underlying mechanism over adding special cases.
Phase 2 — Apply the fixes
Wait for all four agents to complete, dedup findings that point at the same line or mechanism, and fix each remaining one directly. Skip any finding whose fix would change intended behavior, require changes well outside the reviewed diff, or that you judge to be a false positive — note the skip rather than arguing with it. Finish with a brief summary of what was fixed and what was skipped (or confirm the code was already clean).
Tree is back to its committed state and lint is clean (0 issues).
Summary
Four cleanup agents reviewed the checkpoint-policy-command diff (reuse, simplification, efficiency, altitude). The verdict: the code is already clean. No fixes applied.
Efficiency — nothing introduced. Remote work (ls-remote/fetch/push) is gated behind the explicit entire checkpoint policy command, not any hot/startup path; remoteBaseline does a single ls-remote and only fetches on hash mismatch; version guards are in-memory map lookups. Clean.
Findings I evaluated and skipped, with reason:
fmt.Errorf("%w", err)no-op wraps (6 sites) — flagged by two agents as equivalent toreturn err. Butwrapcheckis enabled (onlycoreapiis exempt), and the identical pattern pre-exists atsettings.go:614/649. Returning bare would breakmise run lint. Confirmed false positive.removeFetchRef"pointless" error branch — I tried simplifying to_ = ...;errcheckhascheck-blankon and rejected it. Theif err != nil { return }is this repo's idiom for consuming-and-ignoring. Reverted. False positive given lint config.isAncestorOfduplicatesstrategy.IsAncestorOf— real, but true dedup needs a new lower-level package (strategyalready importscheckpointpolicy, so a direct call is a cycle). The reuse agent also noted the copy lacks theMaxCommitTraversalDepth=1000cap — but adding it changes traversal behavior, out of scope for a quality sweep.ReadReadableCheckpointread-and-verify seam (altitude, ~7 sites) — the strongest finding: theReadCommittedCheckpoint→EnsureCanReadVersionpair is hand-inlined at every committed-read site, so a future read path could silently skip the version gate. A genuine improvement, but it introduces a new cross-package abstraction and rewrites the read path in 4+ files includingstrategy. Too large and correctness-sensitive to bundle into an automated simplify — worth doing as a deliberate, reviewed change.state.Source = SourceRemoteafter push andSync/updateBaselineladder duplication — both correct/low-confidence; skipped.
The one structural recommendation worth tracking separately: fold EnsureCanReadVersion into a single checkpointpolicy read-and-verify helper so the version gate becomes non-skippable for future committed-checkpoint readers. Want me to scope that as its own change?
/simplify → 4 cleanup agents in parallel → apply the fixes
You are improving the quality of the changed code, not hunting for bugs. Review
it for reuse, simplification, efficiency, and altitude issues, then fix what you
find. Do not look for correctness bugs — that is what /code-review is for.
Phase 0 — Gather the diff
Run git diff @{upstream}...HEAD (or git diff main...HEAD / git diff HEAD~1
if there's no upstream) to get the unified diff under review. If there are
uncommitted changes, or the range diff is empty, also run git diff HEAD and
include the working-tree changes in scope — the review often runs before the
commit. If a PR number, branch name, or file path was passed as an argument,
review that target instead. Treat this diff as the review scope.
Phase 1 — Review (4 cleanup agents in parallel)
Launch 4 independent review agents via the Agent tool, all in a
single message so they run concurrently. Pass each agent the diff and one of
the four angles below. Each returns its findings with file, line, a
one-line summary, and the concrete cost (what is duplicated, wasted, or
harder to maintain).
Reuse
Flag new code that re-implements something the codebase already has — Grep shared/utility modules and files adjacent to the change, and name the existing helper to call instead.
Simplification
Flag unnecessary complexity the diff adds: redundant or derivable state, copy-paste with slight variation, deep nesting, dead code left behind. Name the simpler form that does the same job.
Efficiency
Flag wasted work the diff introduces: redundant computation or repeated I/O, independent operations run sequentially, blocking work added to startup or hot paths. Also flag long-lived objects built from closures or captured environments — they keep the entire enclosing scope alive for the object's lifetime (a memory leak when that scope holds large values); prefer a class/struct that copies only the fields it needs. Name the cheaper alternative.
Altitude
Check that each change is implemented at the right depth, not as a fragile bandaid. Special cases layered on shared infrastructure are a sign the fix isn't deep enough — prefer generalizing the underlying mechanism over adding special cases.
Phase 2 — Apply the fixes
Wait for all four agents to complete, dedup findings that point at the same line or mechanism, and fix each remaining one directly. Skip any finding whose fix would change intended behavior, require changes well outside the reviewed diff, or that you judge to be a false positive — note the skip rather than arguing with it. Finish with a brief summary of what was fixed and what was skipped (or confirm the code was already clean).