CI: migrate Claude workflows to central d-morrison/gha reusable workflows

[d-morrison]

Summary

Continues the CI consolidation started in #29 (which moved check-links and summary to the central d-morrison/gha reusable workflows) by migrating the two remaining workflows that have a gha equivalent: the Claude bot and the Claude code reviewer.

Both files become thin callers of the @v1 reusable workflows instead of carrying their own inline anthropics/claude-code-action@v1 step blocks.

Changes

.github/workflows/claude.yml → d-morrison/gha/.github/workflows/claude.yml@v1

• Runs in agent mode (the only mode the reusable workflow offers): the caller grants contents/pull-requests/issues/actions: write + id-token: write and uses secrets: inherit so Claude can push branches and open/update PRs in response to @claude mentions.
• Quarto-book configuration: setup-r: false (this repo has no R package code — no R/, no executable .qmd chunks) and install-quarto: true so Claude can quarto render to verify changes.
• The caller-side if: @claude mention gate is preserved; the reusable workflow additionally enforces the trusted-author (OWNER/MEMBER/COLLABORATOR) gate.

.github/workflows/claude-code-review.yml → d-morrison/gha/.github/workflows/claude-code-review.yml@v1

• Adds the workflow_dispatch (pr_number) path so claude.yml can re-dispatch a review after an @claude run pushes commits. Permissions bumped to pull-requests/issues: write so the reviewer can post inline review comments.

Both pass a short prompt-addendum tailored to a Quarto book and the SERG lab manual's .qmd conventions.

Behavior change to note for review

The previous claude.yml/claude-code-review.yml ran with read-only tokens. Migrating to the gha reusable workflows grants Claude write access (push branches, open PRs, post review comments) — this is the standard gha consumer pattern and the purpose of the reusable agent workflow. The CLAUDE_CODE_OAUTH_TOKEN secret already exists (the prior workflows used it), and secrets: inherit passes it through.

Left unchanged (intentionally)

• check-links.yml, summary.yml — already migrated in CI: adopt central d-morrison/gha reusable workflows (links + summary) #29.
• check-spelling.yaml, lint-project.yaml, preview.yml, publish.yml, copilot-setup-steps.yml — no gha equivalent exists yet.
• check-bibliography-dois.yml — left disabled as-is (it was commented out because DOI services return 403s to automated access). gha does ship an equivalent (check-bibliography-dois.yml@v1, with no-metadata-check/exclude-keys inputs) if you want to revisit re-enabling it, but I did not re-enable it here without a decision from you.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BvMsJLFGjYAaXa2pacjubC

---

Generated by Claude Code

[d-morrison]

Manual review — clean ✅

The automated @claude reviewer skipped this PR (and structurally will until merge), because PR #31 edits .github/workflows/claude-code-review.yml itself. GitHub's code-review action refuses to run when the review workflow on the PR differs from the default branch — the run log shows:

Skipping action due to workflow validation: Workflow validation failed. The workflow file must … have identical content to the version on the repository's default branch … this is normal and you should ignore this error.

This is expected for a workflow-migration PR; the reviewer runs normally on every PR after this merges. In the meantime, here's a manual review of the diff.

Findings

.github/workflows/claude.yml — thin caller of d-morrison/gha/.github/workflows/claude.yml@v1

• Fully delegates to the reusable workflow; no duplicated inline logic. ✔ modular
• Caller permissions (contents/pull-requests/issues/actions/id-token) match what the reusable agent workflow needs.
• setup-r: false + install-quarto: true are correct for a prose Quarto site with no R package code.
• if: gate is the caller-side @claude-mention check; the reusable workflow enforces the trusted-author gate (documented in the header).
• Carries over main's refinement from the qwt conversion: dropping the issues: assigned trigger (the trusted-author gate keys on the issue author, not the assigner).

.github/workflows/claude-code-review.yml — thin caller of …/claude-code-review.yml@v1

• workflow_dispatch.pr_number typed string to match the reusable pr-number input. ✔
• Reviewer permissions correct (pull-requests/issues: write for inline comments, contents: read, id-token: write).
• Matches the thin-caller house pattern established in CI: adopt central d-morrison/gha reusable workflows (links + summary) #29 (check-links.yml, summary.yml); caller-level concurrency intentionally omitted since the reusable workflow defines its own.

Verdict: zero findings. CI is fully green (8/8 checks). Clean.

_{Manual review by the Claude Code CLI (the in-workflow reviewer can't self-review this PR; runs automatically post-merge).}

---

Generated by Claude Code

[github-actions]

👀 Picked up by workflow run #27863167165. R/Quarto setup runs first; Claude itself responds after that.

[github-actions]

PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-06-20 06:42 UTC

[github-actions]

The PR is already merged. The triggering comment is a manual code review posted by d-morrison (the owner), explaining why the automated @claude reviewer couldn't run on this PR (since the PR itself edits the review workflow). No action items were raised — the comment documents zero findings and a clean CI run.

There are no subsequent non-bot @claude comments to address.

My response:

---

Thanks for the manual review and the clear write-up on why the automated reviewer was skipped. The explanation is exactly right — GitHub prevents the code-review action from running when the PR modifies the very workflow file that drives it, since it must match the default branch version. Now that this is merged, the automated @claude reviewer will run normally on all subsequent PRs.

The rationale you captured (trusted-author gate, setup-r: false/install-quarto: true for a prose Quarto site, caller-side @claude gate vs. reusable-workflow enforcement) is useful context for anyone auditing the CI setup later. Agreed on zero findings.

_{— posted by @claude post-step from workflow run}