TimZander / TimZander/claude

Standard: sync (git fetch) before reviewing recent work; re-verify ground truth on user contradiction

Open Beginner friendly
#171 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

Add a rule to standards/CLAUDE.md that prevents reviews (and any "reason about recent work" task) from being performed against a stale or wrong-branch checkout, and that stops the agent from rationalizing contradictions instead of re-checking its inputs.

Background

In a live session, a full deep-review was run against a local main that was 15 commits behind origin/main. The agent never fetched. It then reviewed the tail two commits of a feature as if they were the whole feature, and produced confidently wrong conclusions:

  • Claimed a feature was "flagged off / no UI wiring" — the wiring existed in unfetched commits.
  • Filed two GitHub issues, one escalated to a "🔴 LIVE license violation" with a fabricated "config not in git" governance root cause — invented specifically to reconcile the user's pushback, rather than questioning whether the checkout was current.
  • Only after the user asked "did you not pull from origin before the review?" did a git fetch reveal the 15-commit gap.

Both failure modes are generic (language/project-agnostic) and belong in team standards.

Proposed rule (for standards/CLAUDE.md)

Sync before reviewing; re-verify ground truth on contradiction.

  • Before reviewing "recent work," a branch, a PR, or "the last N hours/days," always git fetch and compare local HEAD to origin/<base> before scoping the work. State the base and HEAD short-SHAs (and the ahead/behind count) up front. Never review a local checkout without first confirming it reflects the remote — for auto-deployed apps, origin/<default-branch> is what users are actually running.
  • When a user contradicts your conclusion more than once, treat it as a signal that a foundational input is wrong (stale tree, wrong branch, wrong environment, wrong file) — stop and re-verify the inputs. Do not construct a new theory to explain away the contradiction on top of unverified ground truth.

Acceptance criteria

  • standards/CLAUDE.md contains a rule requiring git fetch + HEAD-vs-origin reconciliation before any review/"recent work" task, with the base/HEAD SHAs reported.
  • The rule includes the "re-verify ground truth when repeatedly contradicted; don't rationalize" guidance.
  • Wording is project- and language-agnostic (applies in every repo a developer opens).

Notes

Complements the existing /deep-review skill (which already instructs fetching first but does not enforce it — see the companion skill-hardening issue).

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

Read standards/CLAUDE.md and compare its existing guidance with the proposed rule. Add language-agnostic guidance requiring git fetch and HEAD-versus-origin reconciliation, including reported SHAs and ahead/behind status, plus re-verification when contradictions recur. Done means all three acceptance criteria are satisfied in that file.

Written by the indexing model from the issue text.

Assessment

Tech stack
git
Domain
documentation
Issue type
Documentation
Difficulty
1/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
85/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.