Review agent setup
Skill FridrichMethod/awesome-skills/skills/review-agent-setup
Curated, auto-synced collection of 2,000+ Claude Code & Codex skills for AI4Protein, bioinformatics, AI development, and academic paper writing. One curl command installs them all.
npx -y skills add FridrichMethod/awesome-skills --skill review-agent-setupAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 11 stars11 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Configure human-in-the-loop gating for AI agent review actions in Claude Code. Use when setting up a project where an agent may post PR reviews, comments, merges, or edit CI configuration, and you want a cryptographically auditable approval trail with Cedar-enforced gates.
SKILL.md
5.4 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it
review-agent-governance — Setup
Gate AI agent review actions (PR reviews, comments, merges, CI edits) behind explicit human approval. Every attempt, approved or denied, produces an Ed25519-signed receipt.
When to use this plugin
Install it in projects where a Claude Code agent:
- Reviews, comments on, or merges pull requests (
gh pr review,gh pr merge) - Triages issues (
gh issue comment,gh issue close) - Publishes releases (
gh release create) - Modifies CI configuration (
.github/workflows/,.gitlab-ci.yml) - Pushes to protected branches (
main,master,release,production) - Posts to external notification surfaces (Slack webhooks, Discord)
If the agent is only doing local file edits and running tests, this plugin is
overkill. Use protect-mcp for general tool-call policy enforcement and skip
this one.
One-time setup
1. Install the plugin
claude plugin install wshobson/agents/review-agent-governance
2. Copy the default policy to your project
cp .claude/plugins/review-agent-governance/policies/review-agent-governance.cedar \
./review-governance.cedar
You can edit this file to match your project's specific rules. See
../agents/review-policy-author.md for guidance on authoring review
policies.
3. Create a receipts directory and sign key
mkdir -p ./review-receipts
echo "./review-receipts/" >> .gitignore
echo "./review-governance.key" >> .gitignore
echo "./.review-approved" >> .gitignore
The first invocation of protect-mcp sign will create the key. Commit the
public key from the first receipt so auditors can verify later.
Per-session workflow
The Cedar policy denies review-surface actions unconditionally. To approve a specific action, open an approval window before it and close it after.
Flag file (simplest)
# Before the action you want to approve
touch ./.review-approved
# Let Claude Code run the review / comment / merge
# Immediately after
rm ./.review-approved
Slash command (from within Claude Code)
/approve-review "Reviewing PR #123 authored by contributor X"
This creates ./.review-approved with the given reason embedded as a note,
and writes a human-approved receipt to the chain. A follow-up rm is still
needed to close the window.
Dry-run everything (force full policy evaluation)
If you want every tool call to go through Cedar with no approval bypass:
export REVIEW_APPROVAL_FLAG=./.never-approve
Any tool call matching a forbid rule will be denied; approved windows have no effect. Useful for CI or for a locked-down audit run.
Verifying the chain
List all receipts:
ls -la ./review-receipts/
Verify the entire chain offline:
npx @veritasacta/verify ./review-receipts/*.json
Exit 0 means every receipt is authentic and the chain is intact. Exit 1 means one receipt has been tampered with. Exit 2 means a receipt is malformed.
Look at recent denials:
/list-pending
Within Claude Code this slash command walks the receipt chain and prints
any recent decision: deny entries with the tool name, command pattern,
and timestamp.
Example: approving a PR review
# 1. Human reviews the agent's proposed comment
$ /list-pending
Recent denials:
- 2026-04-17T14:23:01Z Bash "gh pr review 42 --approve --body 'LGTM'"
- 2026-04-17T14:23:02Z Bash "gh pr comment 42 --body 'Looking good'"
# 2. Human decides the first one is appropriate, approves it
$ /approve-review "Approving LGTM on PR 42 after visual inspection"
./.review-approved created
# 3. Agent retries the action; this time it succeeds
$ agent: gh pr review 42 --approve --body "LGTM"
[receipt: rec_XXX, decision=allow, reason=human_approved]
# 4. Human closes the window
$ rm ./.review-approved
Every step is in the receipt chain. The chain is offline-verifiable for regulators, counterparties, or downstream auditors who want to confirm that no review action bypassed the human gate.
Composing with protect-mcp
If both plugins are installed, run them side by side:
{
"hooks": {
"PreToolUse": [
{
"matcher": ".*",
"hooks": [
{
"type": "command",
"command": "npx [email protected] evaluate --policy ./protect.cedar --tool \"$TOOL_NAME\" --input \"$TOOL_INPUT\" --fail-on-missing-policy false"
}
]
},
{
"matcher": ".*",
"hooks": [
{
"type": "command",
"command": "if [ -f ./.review-approved ]; then exit 0; fi; npx [email protected] evaluate --policy ./review-governance.cedar --tool \"$TOOL_NAME\" --input \"$TOOL_INPUT\" --fail-on-missing-policy false"
}
]
}
]
}
}
Both hooks must pass for the tool call to proceed. Cedar deny in either policy blocks it.
Standards
- Ed25519 — RFC 8032 (digital signatures)
- JCS — RFC 8785 (deterministic JSON canonicalization)
- Cedar — AWS's open authorization policy language
- IETF draft — draft-farley-acta-signed-receipts
Gives 0 of the 12 instructions most context ai engineering skills give in ~1.3k tokens
Counted across 1,193 of the 1,976 authors here whose files we hold, read 2026-08-07
- dispatch a fresh implementer subagent per taskin 48 of 1193, across 19 files
- dispatch a final code reviewer after all tasksin 33 of 1193, across 8 files
- provide full task text to the subagentin 30 of 1193, across 9 files
- review spec compliance before code qualityin 27 of 1193, across 10 files
- make the hook script executablein 26 of 1193, across 8 files
- re-snapshot after navigation or DOM changesin 25 of 1193, across 19 files
- read files before editing themin 22 of 1193, across 11 files
- answer subagent questions before proceedingin 22 of 1193, across 7 files
- mark task complete in TodoWrite after approvalin 22 of 1193, across 6 files
- merge hook into existing settingsin 21 of 1193, across 3 files
- ask if installation is global or projectin 20 of 1193, across 2 files
- copy the hook script to target locationin 20 of 1193, across 2 files
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.