rigor: Skill for Claude Code

Rigor Release Prep

Follow this workflow when preparing a new rigor gem release.

All commands MUST run through the Flake per AGENTS.md. The examples below include the full nix develop --command prefix so each line is directly runnable from outside the Flake shell. Inside the Flake shell, drop the prefix.

First: ratify the approval queue

Before any other step, report the approval queue and let the user decide each entry. Agents make every decision that list does not call serious on their own and record it in approval-queue.d/ (docs/agents/contribution-flow.md § "Decisions and the approval queue", ADR-123); a release ships only decisions the user ratified.

git fetch origin
git ls-tree --name-only origin/master approval-queue.d/   # README.md alone means empty

1. Empty (only README.md): say so in one line and go on to the branch. Entries the user ratified earlier in a long window are already gone: a Ratify approval queue entries PR deleted them on master (approval-queue.d/README.md), so only what remains is reported here.
2. Otherwise, report every entry in the user's language — the language they write to you in, not the repository's English. Read each file from origin/master and, per entry, give its decision, PR, class and precedent, then its background, the options with their trade-offs, the decision's reasoning and how to undo it. Translate faithfully and keep every link; do not shorten the trade-offs away, they are what the user is judging.
3. Ask for each entry with options Ratify, Revise and Revert, in the user's language: under Claude Code with AskUserQuestion (up to four entries per call, free text always allowed), elsewhere as a numbered question in chat. Do not recommend an option.
4. Ratified entries are deleted on the release branch once it is cut (below), in one commit Ratify approval queue entries whose body lists each entry's title and PR link: that commit is the record of the ratification.
5. Revise or Revert: the change lands as an ordinary PR (contribution-flow § "Landing a pull request") that changes or reverts the decision and deletes its entry. File an issue for it when the user does not want it done now. Either way the release waits: tell the user so, and continue the other steps only if they want the release prepared while the PR lands.
6. The release ships with the queue empty. Before opening the release PR, and again before publishing, list approval-queue.d/ on the release branch and on origin/master: an entry that landed on master after step 3 goes through steps 2–5 too; rebase the release branch onto origin/master to pick it up before deleting it there. spec/docs/approval_queue_spec.rb fails the release PR's CI while its branch holds an entry, but it cannot see an entry that reaches master afterwards.