From 41e98962d814f557ce52734410d6a64135003250 Mon Sep 17 00:00:00 2001 From: Markus Neusinger <2921697+MarkusNeusinger@users.noreply.github.com> Date: Wed, 29 Apr 2026 21:51:57 +0200 Subject: [PATCH 1/2] chore(claude): codify mandatory PR follow-through rule MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit After opening a PR, Claude must watch the pipeline through to green and respond to Copilot review feedback before declaring the work done. This rule emerged from a sequence of PRs (#5524, #5525, #5551, #5552) where deploy failures and Copilot-flagged issues were caught only because the user prompted me to look — without that prompt, "PR opened" was treated as the finish line and CI red / unread review feedback slipped through. The rule: 1. Poll `gh pr checks` until done; on failure, push fix to same branch 2. Wait for Copilot bot review (typically ~2 min after open) 3. Apply sensible Copilot suggestions, state which skipped and why 4. Push review-driven fixes to the SAME branch (no follow-up PRs) 5. Only then announce the PR is ready Co-Authored-By: Claude Opus 4.7 (1M context) --- CLAUDE.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index 521a8c2686..0f36e035d6 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -14,6 +14,19 @@ For detailed project documentation (architecture, commands, workflows, etc.), se - **Always write in English** - All output text (code comments, commit messages, PR descriptions, issue comments, documentation) must be in English, even if the user writes in another language. - **Update documentation when making changes** - When adding new features, events, or modifying behavior, always check if related documentation needs updating (e.g., `docs/reference/plausible.md` for analytics events, `docs/workflows/` for workflow changes, `docs/contributing.md` for user-facing changes). +## PR Follow-Through (mandatory after every `gh pr create`) + +After opening a PR, the work is **not** complete. Stay with the PR until both the pipeline is green AND review feedback has been addressed. "PR opened" is a checkpoint, not the finish line. + +1. **Watch the pipeline.** Poll `gh pr checks ` (and Cloud Build for triggered deploys) until every required check has finished. Use a background bash poll so other work can continue. Default: poll every 20 s, up to ~10 min per check. +2. **Fix CI failures.** If any check fails, read the relevant log (`gh run view --log-failed`, `gcloud builds log `), push a fix commit to the same branch, then keep watching. Repeat until green. +3. **Wait for the Copilot PR Reviewer bot** (and any other auto-review bots active on this repo). Typically lands within ~2 min of PR open. Fetch with `gh pr view --comments`, `gh api repos/MarkusNeusinger/anyplot/pulls//reviews`, and `gh api .../comments`. +4. **Triage Copilot suggestions and apply only the sensible ones.** Apply when the comment flags a real bug, a deploy-order risk, a security/correctness issue, or a missed edge case. Skip pure style noise or anything that contradicts an explicit decision in the PR body. State briefly in chat which were applied vs skipped, so the user can override. +5. **Push review-driven fixes to the SAME branch.** Don't open a follow-up PR for review feedback — it belongs on the original PR. +6. **Only then announce the PR is ready / ask the user to merge.** Premature "done" leaves CI red or feedback unaddressed. + +This rule applies to every PR Claude opens, including small fixes and follow-ups. + ## MCP Tools (Serena & Context7) **Serena** - Prefer for Python/TypeScript code navigation and editing: From 1117becc2f60c939a2706dad20e31fd15824d7eb Mon Sep 17 00:00:00 2001 From: Markus Neusinger <2921697+MarkusNeusinger@users.noreply.github.com> Date: Wed, 29 Apr 2026 22:00:37 +0200 Subject: [PATCH 2/2] review(claude): split step 3 into the three GitHub comment APIs Per Copilot review on PR #5553, the placeholder `gh api .../comments` was ambiguous (three different comment APIs surface PR feedback) and the hardcoded `repos/MarkusNeusinger/anyplot/...` wasn't portable to forks. Replace with concrete endpoints using `{owner}/{repo}` so gh-cli auto-resolves from the current remote, plus a one-line description per endpoint so the reader knows which one returns what. Co-Authored-By: Claude Opus 4.7 (1M context) --- CLAUDE.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/CLAUDE.md b/CLAUDE.md index 0f36e035d6..45ec9c028e 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -20,7 +20,10 @@ After opening a PR, the work is **not** complete. Stay with the PR until both th 1. **Watch the pipeline.** Poll `gh pr checks ` (and Cloud Build for triggered deploys) until every required check has finished. Use a background bash poll so other work can continue. Default: poll every 20 s, up to ~10 min per check. 2. **Fix CI failures.** If any check fails, read the relevant log (`gh run view --log-failed`, `gcloud builds log `), push a fix commit to the same branch, then keep watching. Repeat until green. -3. **Wait for the Copilot PR Reviewer bot** (and any other auto-review bots active on this repo). Typically lands within ~2 min of PR open. Fetch with `gh pr view --comments`, `gh api repos/MarkusNeusinger/anyplot/pulls//reviews`, and `gh api .../comments`. +3. **Wait for the Copilot PR Reviewer bot** (and any other auto-review bots active on this repo). Typically lands within ~2 min of PR open. Fetch with `gh pr view --comments`, plus the three GitHub APIs that surface different comment types — `gh api` resolves `{owner}/{repo}` from the current git remote so these are copy/paste-portable: + - `gh api repos/{owner}/{repo}/pulls//reviews` — top-level review summaries (Copilot's overall comment lives here) + - `gh api repos/{owner}/{repo}/pulls//comments` — inline review comments tied to file/line + - `gh api repos/{owner}/{repo}/issues//comments` — generic PR conversation comments (codecov, deployment bots, humans) 4. **Triage Copilot suggestions and apply only the sensible ones.** Apply when the comment flags a real bug, a deploy-order risk, a security/correctness issue, or a missed edge case. Skip pure style noise or anything that contradicts an explicit decision in the PR body. State briefly in chat which were applied vs skipped, so the user can override. 5. **Push review-driven fixes to the SAME branch.** Don't open a follow-up PR for review feedback — it belongs on the original PR. 6. **Only then announce the PR is ready / ask the user to merge.** Premature "done" leaves CI red or feedback unaddressed.