From 50d38322b293122a90ba8b7d8b576406ed4c37f0 Mon Sep 17 00:00:00 2001 From: jnasbyupgrade Date: Fri, 7 Aug 2026 17:15:22 -0500 Subject: [PATCH 1/2] Add CLAUDE.md with CI-monitoring instructions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The repo had no agent-facing instructions file. Add one that requires monitoring GitHub CI to completion after every push, and specifically calls out checking the claude-code-review job's actual comment content rather than just its pass/fail status — a green conclusion only means the review ran, not that its findings were addressed, and findings that repeat across pushes without a fix commit were otherwise easy to miss. It also instructs treating review findings as claims to verify against the code rather than applying them blindly. --- CLAUDE.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 CLAUDE.md diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 0000000..7f90888 --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,21 @@ +# Claude Code Instructions for pg_count_nulls + +## GitHub CI + +After **every** push, monitor GitHub CI to completion (`gh pr checks --watch` when the +branch has an open PR, `gh run watch` for a branch with no PR yet) — do not consider a push +complete until its CI run is green (or a failure is understood and explicitly accepted by +the user). + +This includes the `claude-code-review` job specifically: a green job conclusion only means +the review *ran*, not that its findings were addressed. After the job completes, fetch and +read its actual PR comment (`gh api repos///issues/comments/` from the +comment URL, or `gh pr view --json comments`) for open findings. A finding repeating across +several pushes with no corresponding fix commit is a signal being missed, not something to +let ride because the check itself is green. + +Do not blindly implement review findings. They're generally good, but treat each one as a +claim to verify against the actual code before acting on it — the review re-reads the diff +each run without the code's full history or design intent in mind, and can be wrong or miss +context. When a finding's validity is unclear, or fixing it would touch design intent rather +than a mechanical mistake, ask before implementing rather than guessing. From 1a98eeb417a63d82ec3721a78480bc87a8e0e306 Mon Sep 17 00:00:00 2001 From: jnasbyupgrade Date: Fri, 7 Aug 2026 17:23:08 -0500 Subject: [PATCH 2/2] CLAUDE.md: require immediate act-or-ask on findings, hard stop on recurrence Strengthens the review-findings guidance added in the previous commit: a finding must be acted on or explicitly escalated to the user as soon as it's seen, not merely tracked as 'not something to let ride' (language loose enough to imply deferring is fine). Also adds a hard-stop rule: a finding that recurs, or is remotely similar to an earlier one on the same PR, means the reviewer and the agent are misaligned, and must halt for user input instead of continuing to iterate and burn tokens. --- CLAUDE.md | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 7f90888..b3375fc 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -10,12 +10,19 @@ the user). This includes the `claude-code-review` job specifically: a green job conclusion only means the review *ran*, not that its findings were addressed. After the job completes, fetch and read its actual PR comment (`gh api repos///issues/comments/` from the -comment URL, or `gh pr view --json comments`) for open findings. A finding repeating across -several pushes with no corresponding fix commit is a signal being missed, not something to -let ride because the check itself is green. +comment URL, or `gh pr view --json comments`) for open findings. -Do not blindly implement review findings. They're generally good, but treat each one as a -claim to verify against the actual code before acting on it — the review re-reads the diff -each run without the code's full history or design intent in mind, and can be wrong or miss -context. When a finding's validity is unclear, or fixing it would touch design intent rather -than a mechanical mistake, ask before implementing rather than guessing. +For every finding, as soon as you see it: either act on it (fix it, or explicitly state why +it doesn't need fixing) or ask the user for direction. Never leave a finding unaddressed and +unacknowledged just because the check itself is green. + +If a finding — or one remotely similar to a finding from an earlier push on the same PR — +shows up again, STOP immediately and ask the user for help before doing anything else. A +recurrence means you and the review bot are not in alignment (either the earlier fix didn't +actually address it, or you and the reviewer disagree about it), and continuing to guess at +it burns tokens without resolving the actual disagreement. + +Do not blindly implement review findings, either. They're generally good, but treat each one +as a claim to verify against the actual code before acting on it — the review re-reads the +diff each run without the code's full history or design intent in mind, and can be wrong or +miss context.