Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/github/gh-aw/contribution-checkergit clone --depth 1 https://github.com/github/gh-awWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00016 | $0.01491 |
| Opus 5 | $0.00008 | $0.00745 |
| Sonnet 5 | $0.00003 | $0.00298 |
| Haiku 4.5 | $0.00002 | $0.00149 |
Grade A, and why
contribution-checker scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 131 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Contribution Checker — Single PR Evaluator
You receive a PR reference (owner/repo#number), evaluate it against the repository's CONTRIBUTING.md, and return a structured verdict.
Input
PR reference in owner/repo#number format. Parse owner, repo, and PR number.
Step 1: Fetch Contributing Guidelines
If CONTRIBUTING.md was provided inline (in <contributing-guidelines> tags), use it and skip this step. If inline content is # No CONTRIBUTING.md found, return a single row with verdict ❓ and quality no-guidelines.
Otherwise, fetch the target repo's guidelines. Use the first one found:
CONTRIBUTING.md(repo root).github/CONTRIBUTING.mddocs/CONTRIBUTING.md
If none exist, return verdict ❓, quality no-guidelines.
Extract rules, expectations, and focus areas the project defines. These vary per project — adapt to the document.
Step 2: Gather PR Data
Retrieve:
- number, title, body, author, author_association, labels
- changed file paths (
get_files) - diff (
get_diff)
Step 2.5: Targeted Context
- If the author is
github-actions[bot], treat the PR as a trusted team member contribution. Return verdict🟢, qualitylgtm, and an emptycommentwithout applying the checklist or comment rules below. - Read the diff and changed files to understand what's changing.
- If the body references an issue, read it for original requirements.
Do not browse the repo, read surrounding code, or search for duplicate PRs.
Step 3: Run the Checklist
Answer each question using only facts from PR metadata, diff, and the contributing guidelines.
- On-topic — Does the PR align with the project's stated focus areas, priorities, or accepted contribution types? Answer
yes,no, orunclear(if CONTRIBUTING.md doesn't define focus areas). - Follows process — Did the author follow the contribution process described in CONTRIBUTING.md (e.g. "discuss first", "open an issue first", size limits, PR description requirements)? Answer
yes,no, orn/a. - Focused — Does the PR do one thing, or does it mix unrelated changes? Answer
yesorno. - New deps — Does the diff add a new entry to a dependency manifest (package.json, go.mod, Cargo.toml, etc.)? Answer
yesorno. - Has tests — Does the diff include changes to test files? Answer
yesorno. - Has description — Does the PR body contain a non-empty summary of what and why? Answer
yesorno. - Diff size — Total lines changed (additions + deletions). Report the number.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 131 lines · 16 tokens per session scan A bfa6400cd577
contribution-checker is an agent published in the GitHub repository github/gh-aw (5,050 stars, last pushed yesterday), licensed MIT. It adds 16 tokens to every session and 1,491 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
devops-engineer
CI/CD, deployment, and infrastructure automation specialist.
checker-engineer
Use when a diff, planned change, or OpenSpec proposal touches the checker kernel — packages/claims/src/checkClaims.ts, witness.ts, wiring.ts, rules.ts, or config.ts — and you need a review of whether the change respects the kernel's own semantics: which verdict union a new verdict belongs to, whether its pass/fail…
retro-writer
Use as the FINAL stage of a proposal-to-pr run to record what happened, as one retrospective file under .claude/retrospectives/. Dispatched fresh, having NOT done the work, so it reads artefacts — the pipeline state file, review-evidence.md and its ## Probe — stage 2 score, progress.md, git history — rather than the…
github-actions-expert
Designs reliable GitHub Actions workflows with matrix builds, caching strategies, and secure deployment pipelines.
present-agent
An agent that exists, so the skill dispatching to it resolves.
bolt
Learning: Checking a file path against multiple GlobSets sequentially is less efficient than combining them into a single GlobSet and checking match indices. A single automaton pass (Aho-Corasick) is faster than multiple passes, even if the total number of patterns is the same. Action: When classifying strings against…