diff --git a/.github/copilot/skills/pr-review-responder.yml b/.github/copilot/skills/pr-review-responder.yml index b80f4404..0aeb72a9 100644 --- a/.github/copilot/skills/pr-review-responder.yml +++ b/.github/copilot/skills/pr-review-responder.yml @@ -1,69 +1,40 @@ name: pr-review-responder description: | - Automate the full PR lifecycle for GitHub Copilot CLI: create a branch, commit, - push, open a PR via gh CLI, monitor CI, read review comments, evaluate and fix - issues, re-push, respond to reviewers, and verify CI passes again. + Handle an Axis pull request for GitHub Copilot CLI. Commit named files, push + without force, open a pull request, fix a review finding before resolving + its thread, and merge only when the operator names that pull request. prompt: | - You are a PR lifecycle automation expert. When the user asks you to create a - PR, open a PR, or handle review comments, follow this exact workflow: - - ## 1. Prepare and Commit - - Ensure all changes are staged: `git add -A` - - Create a descriptive branch: `git checkout -b ` - - Commit with a clear message. Always include the Co-authored-by trailer: - ``` - Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> - ``` - - ## 2. Push and Open PR - - Push: `git push -u origin ` - - Open PR via `gh pr create` with a detailed title, summary of changes, - verification checklist, and files-changed count. - - If the base branch is protected, enable auto-merge after the push: - `gh pr merge --squash --delete-branch --auto` - - ## 3. Monitor CI - - Poll CI completion with `gh pr view --json statusCheckRollup` - - Wait for all checks to complete. Do NOT proceed until CI is done. - - If checks fail, read the failure logs via `gh run view --log-failed` - and fix the root cause before re-pushing. - - ## 4. Read and Evaluate Review Comments - - Fetch all feedback (reviews, general comments, and line-level threads): - ``` - gh pr view --json reviews,comments,reviewThreads - ``` - - Evaluate every comment for: - - **Correctness**: Is the suggestion technically accurate? - - **Scope**: Does it relate to the PR changes or is it pre-existing? - - **Severity**: Is it blocking or a nice-to-have? - - Group related comments. Do NOT apply suggestions blindly. - - ## 5. Fix Issues - - For each valid comment, make the minimal, surgical fix. - - Run local quality gates after every significant change (fail-fast order): - ``` - make lint && make test-race && make coverage && make build - ``` - - Update golden files, test helpers, or documentation if the fix changes - serialized output. - - Stage fixes and amend the PR commit: `git commit --amend --no-edit` - - Force-push the updated branch: `git push --force-with-lease` - - ## 6. Respond to Reviewers - - Post a PR comment (or reply to each thread) explaining what was fixed and why. - - Reference the specific lines or functions changed. - - Keep responses concise but complete. - - ## 7. Final Verification - - Re-poll CI until all checks show `conclusion: SUCCESS`. - - Confirm `mergeable: MERGEABLE` and auto-merge is still active. - - Clean up local temporary branches. - - ## Key Principles - - **Never merge without review** on protected branches; use auto-merge. - - **Always verify before claiming success**: run tests, check CI, reproduce - and confirm the original issue is gone. - - **Fix pre-existing issues only when directly coupled** to the changed code. - - **Co-authored-by trailer** is mandatory on every commit. - - **Prefer ecosystem tools** (gh CLI, go mod, npm) over manual edits. + GitHub `CLEAN` means branch protection is satisfied. It does not mean the + change is fit to land. + + 1. Read the diff and the tests. A correctness finding is fixed only when the + patch and a test that fails on the old behavior are on the branch. + 2. Run `make ci-preflight` with `GOTOOLCHAIN=go1.26.6` when `go.mod` says + `go 1.26.6`. The value is the word `go` plus the version. The pinned + staticcheck release cannot decode a newer toolchain. + 3. Query the live pull request. Required checks are whatever branch + protection lists now. `mergeStateStatus` must be `CLEAN`, the head must + contain the patch, and the branch must not be behind the base when + protection is strict. + 4. Resolve a review thread only after step 1 is true for that thread, or the + operator has explicitly declined that finding. Reply with the commit, + then resolve the thread. + 5. Merge only when the operator names that pull request: + `gh pr merge --squash`. Do not pass `--admin` unless the + operator gives a separate command that says to. Do not enable auto-merge + on any pull request. + 6. Leave `internal/buildinfo/version.go` unchanged. Do not install the + binary and do not restart daemons in the merge step. + + When one pull request merges, update another open branch by merging the new + base into it. Do not force-push. Reset, cherry-pick, and force-push only + when the operator asks to recover a branch that still contains commits + already squash-merged. + + Stage named files. Do not `git add -A`. Do not amend a commit that is + already on the remote. Do not add a Co-authored-by trailer unless the + operator asked for that trailer. + + `.github/workflows/dependabot-auto-merge.yml` stays limited to Dependabot + patch and minor updates. `pr-truth-audit` is advisory. Do not hand-edit + `.github/workflows/pr-truth-audit.lock.yml`.