Capstone: CI review your team can share

01The setup

Work in a fresh private copy of the practice template — gh repo create claude-capstone --template wesammustafa/claude-code-practice --private --clone — because this capstone ends by tearing down a workflow, a secret and a key. Start claude in it once and accept the trust dialog (worktree sessions need it), and bring a credential for CI: an API key made for this capstone is ideal, because the teardown deletes it.

02The brief

The team wants Claude to review every pull request in CI, the same way on everyone’s machine, with nothing it runs left unbounded. Five parts, each built the way its lesson taught:

1. 01Two sessions at once (lesson 1). Ignore .claude/worktrees/ in the committed .gitignore and push main — new worktrees branch from the remote’s default branch. Then, in two terminals simultaneously, claude --worktree with a different name each time: one session builds the review script (part 2), the other the team plugin (part 3), each committing on its own branch. While both worktrees exist, save git worktree list --porcelain from the main checkout. Merge both branches with git merge — not --squash — and remove both worktrees.
2. 02A review script (lesson 4). scripts/review-staged.sh to its lesson’s contract: the staged diff piped into one claude -p call, JSON output, dontAsk mode, only Read, Grep and Glob pre-approved, turns capped at ten or fewer, non-zero exit on failure, nothing staged means no run. After the merges, stage a one-line change, run it once, read the review — the JSON’s total_cost_usd estimates what one review spends.
3. 03The team’s plugin (lesson 6). A marketplace at team-marketplace/ listing one plugin by relative path, registered and enabled in the committed .claude/settings.json, both validations passing. Test it after the merges: a relative path resolves against the main checkout, so the worktree session could not load it yet.
4. 04A saved dynamic workflow (lessons 2 and 3). From the main checkout, ask for a workflow that reviews each file under src/ with a second agent checking each finding; watch its per-agent token usage in /workflows; save it to the project and commit it.
5. 05CI review with limits (lessons 5 and 7). .github/workflows/claude-review.yml on pull_request, running anthropics/claude-code-action pinned to a release tag or SHA, with a review prompt, the credential from a repository secret (gh secret set ANTHROPIC_API_KEY), a read-only job token plus github_token set to the job’s own, claude_args carrying --max-turns of ten or fewer and an --allowedTools list with no unrestricted Bash, a timeout-minutes of thirty or fewer, and display_report: true. Check out the full history and allow exactly Bash(git diff *) so Claude can see the change — and nothing else.

Commit the workflow to main and push. Then push a one-line change on a new branch, open a pull request, and read Claude’s review on the run’s summary page before you merge it yourself. Finish on main, everything committed, tests passing.

Then the teardown, in order: delete the workflow, commit and push; delete the secret; with an API key, delete the key on the Console’s API keys page. Deleting the secret does not retire the credential — the key deletion is the step that does. What remains after teardown is everything committed: the script, the plugin, the workflow script and the memory of how the pieces bound each other.

That is the course. The Beginner level made one change safe; the Intermediate toolkit shaped Claude Code to your project; this level made it parallel, unattended and shared — always inside limits someone wrote down. Where next is a short list: your own agents on the Agent SDK, your own MCP servers, and the organization-scale rollout pages — linked below, all Anthropic’s. If the automated per-lesson checks appeal, Wesam’s practice template ships this exact capstone with a checker.