TimZander / TimZander/claude

Harden deep-review: enforce git fetch as a verified precondition, surface base/HEAD SHAs

Open
#172 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
0
Forks
1
Avg merge
1d 3h
Merged PRs (30d)
7

Description

Goal

Make the deep-review skill's "fetch the base branch first" step a verified gate rather than a skippable instruction, so a review can never silently run against a stale local checkout.

Background

deep-review already documents fetching the base branch as Step 1 ("First, fetch the base branch... If this fails, stop and report"). In a live session the agent nonetheless skipped it and reviewed a local main that was 15 commits behind origin/main, producing confidently wrong findings and two mis-filed GitHub issues. The instruction existed; the enforcement did not. The user caught it only by asking "did you not pull from origin before the review?"

A prose instruction that can be silently skipped is the exact failure mode. The fix is to make the fetch + divergence check produce visible output at the top of every review so a stale base is impossible to miss.

Proposed change

  • After the mandatory git fetch origin <base>, compute and print at the very top of the review output: base=<short-sha> HEAD=<short-sha> and the ahead/behind count (git rev-list --left-right --count HEAD...origin/<base>).
  • If local HEAD is behind origin/<base> (or the review target is a local ref that trails its remote), surface an explicit warning and confirm the intended review range before proceeding — do not silently review the stale tree.
  • Make the "🎯 Context" / verdict header echo the exact commit range reviewed (e.g. Reviewing <base-sha>..<head-sha>, N commits) so the scope is auditable after the fact.

Acceptance criteria

  • Running deep-review on a checkout behind its remote produces a clearly visible base/HEAD/behind report and does not proceed as if current.
  • The reviewed commit range appears in the review output.
  • Existing behavior is unchanged when the checkout is already up to date.

Why a skill change over documentation

The documentation already says to fetch. The gap is enforcement and visibility — only a concrete step in the skill (compute SHAs, print them, gate on divergence) closes it. Static docs would just restate the instruction that was already skipped.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the deep-review skill's existing Step 1 fetch instruction and trace where review output and the “🎯 Context” or verdict header are assembled. Run deep-review against a checkout behind its remote to verify the base/HEAD SHAs, ahead/behind count, warning, and reviewed range appear before proceeding; also confirm up-to-date checkouts retain existing behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
tooling
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.