TimZander / TimZander/claude

Codify 'no test counts in PR descriptions' in team standards + deep-review/craft-pr skills

Open
#197 0 comments 0 reactions 1 assignee View on GitHub

@TimZander is already working on this.

Since Jul 22, 2026.

documentation enhancement shared-standards
Dominant language
Python
Stars
0
Forks
1
Avg merge
1d 3h
Merged PRs (30d)
7

Description

Context

Raised in PreTourSurvey PR #4825 (E41 S18 /api/health/ready) review. Team consensus that PR descriptions should not include unit-test counts (e.g. 343/343 (+10)):

  • They go stale immediately — that PR's description said 343/343 while the branch was actually at 355/355 after the deep-review round.
  • The CI build runs the tests anyway, so the tally adds no signal — it's noise.
  • Chris Smith raised it, Joe Brady agreed ("PR descriptions shouldn't have test counts in them because it's just noise"), Tim Zander confirmed.

The guidance currently lives only in a local memory/config file rather than the shared, synced team standards — so it isn't consistently applied across devs or by the tooling.

Goal

Move the rule into the shared sources so it propagates to everyone and to the PR-authoring/review tooling.

Acceptance criteria

  • Team coding standards (standards/CLAUDE.md, synced into each dev's ~/.claude/CLAUDE.md) state that PR descriptions must not contain unit-test counts / pass tallies.
  • The PR-authoring skill (craft-pr) is updated so generated PR descriptions omit test counts.
  • The deep-review skill is updated so it neither adds nor expects a test-count line in PR descriptions (and does not raise a false "stale count" finding).
  • Sync scripts run / documented so the change reaches all developers and the Antigravity-compiled skill copies (scripts/antigravity-sync.py).

Notes

  • Non-blocking for PR #4825 — filed separately so it doesn't hold up S18.
  • Origin: PR #4825 review thread on the stale-test-count nit.

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.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.