no-mistakes: Skill for Claude Code

Shared PR-Enforcement Action (.github/actions/require-no-mistakes)

• The shared implementation of the PR must be raised via no-mistakes gate is a composite action that lets enforcing repositories replace copied, drift-prone scripts. It verifies the signature line, parses the v1 pipeline-step attestation, binds head_sha to the PR head, and requires review, test, and document to be completed. Callers pin a release tag or commit SHA, never @main, which the judged PR can edit. Per-repo configuration is exemptions only (exempt-authors, exempt-bot-authors, exempt-head-branches); which steps are required is deliberately not an input, so no caller can weaken the gate while still reporting the same check name. The action README owns usage; CONTRIBUTING.md owns the contributor-facing contract.
• This repository's own gate (.github/workflows/no-mistakes-required.yml) is a thin caller of the action, pinned at an already-published commit SHA. GitHub downloads uses: at job setup, so the pin must always name a ref that already carries the action. That pin IS the self-certification guard: a PR editing the action is fully tested on its own head (the Go tests execute the working-tree verify.py) while the required check judging it runs the published pinned copy, so the change cannot rewrite its own judge. Bumping the pin is a separate deliberate PR.
• This repo's automation exemptions stay in the job-level if:, not in exempt-authors. An in-job exemption still needs the run to start, and a GITHUB_TOKEN PR's run is created in action_required and never starts; the paths-ignore entries exist for the same reason. Repos without that constraint should prefer the action's inputs.
• Duplicate step records are LAST-WINS by design (check_required_steps in verify.py), and a skip-shaped sibling field on a completed record is deliberately not inspected. Some pre-migration inline gates were stricter (requiring every record of a name to be completed); that strictness is explicitly NOT the standard, and relaxing to last-wins on migration is the intended outcome, not a regression. Do not "harden" this without an owner decision.
• All callers use the T2 trigger set (opened, edited, synchronize, reopened). Since the pre-push attestation change (#994), synchronize is the event that judges a pipeline-pushed head, so it is restored rather than dropped after head_sha binding.
• Migrating a repository is rarely a one-file swap. Repos whose tests extract and execute the inline run: block (an extractGateScript() helper and its gate test) break at import once the block is gone, and repo-level AGENTS.md notes that tell agents to hand-copy the gate from a sibling repository must be rewritten - that copying is the drift the shared action exists to remove.
• Regressions: require_no_mistakes_action_test.go executes verify.py the way a runner does (verdicts, exemption surface, event-payload binding); workflow_no_mistakes_required_test.go owns the CALLER - immutable-SHA pin, single delegating step, exemptions, triggers, concurrency identity, fork boundary - and drives the real action through the event payload.

Stale Actions Event Replay Can Resurrect a Superseded Check (require-no-mistakes)

• .github/actions/require-no-mistakes/verify.py reads the PR body/head SHA it verifies from a live GitHub REST API lookup first (via live_pr_facts, a direct urllib.request GET to {GITHUB_API_URL}/repos/{repo}/pulls/{number} with the forwarded github-token as a Bearer token, no gh CLI), not from GITHUB_EVENT_PATH, whenever a caller forwards no explicit pr-body/pr-head-sha (the documented zero-input integration every caller actually uses). A GitHub Actions job rerun replays the event payload archived at the run's original trigger rather than delivering a fresh one; re-running an old, already-superseded failed run therefore used to reproduce its stale verdict with a brand-new check-run timestamp, which both GitHub's own required-check view and collapseLatestByName (internal/scm/github/github.go) treat as current - pinning a stale FAILURE next to an already-green commit with no clean recovery short of a new SHA. When a required live lookup is unavailable (no pull-requests: read, no token, or the API call fails), the gate fails closed rather than certifying compliance from the possibly-stale event payload; explicit pr-body/pr-head-sha inputs always skip the live lookup and win, unchanged.
• Tests: require_no_mistakes_action_test.go (TestRequireActionLiveLookupOverridesStaleArchivedEvent and siblings).