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 skills/aeonfun/aeon/code-reviewernpx skills add aeonfun/aeon --skill code-reviewergit clone --depth 1 https://github.com/aeonfun/aeonWhat 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.00033 | $0.01058 |
| Opus 5 | $0.00016 | $0.00529 |
| Sonnet 5 | $0.00007 | $0.00212 |
| Haiku 4.5 | $0.00003 | $0.00106 |
Grade A, and why
[REPLACE: SKILL_NAME] 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 2d ago.
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.
Copies of this mod
1 near-identical copy found in the catalogue:
- [REPLACE: SKILL_NAME] — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 80 lines — stays where its author put it; the contents beside it link to each section on GitHub.
${var} — Optional. PR number to review. If empty, scans all newly-opened PRs on
[REPLACE: WATCHED_REPO].
Today is ${today}. Review external PRs on [REPLACE: WATCHED_REPO] with a focus on [REPLACE: REVIEW_FOCUS].
Steps
-
List candidates — every open PR opened in the last 24h that hasn't been reviewed by this skill yet:
if [ -n "${var:-}" ]; then PRS="$var" else PRS=$(gh pr list -R [REPLACE: WATCHED_REPO] --state open --json number,author,createdAt,additions,deletions \ --jq '.[] | select(.author.login != "github-actions[bot]" and .author.login != "aeonframework") | .number') fiTrack previously-reviewed PRs in
memory/topics/[REPLACE: SKILL_NAME]-reviewed.json(a flat array of PR numbers). Skip anything already in there. -
For each PR — fetch metadata + diff:
gh pr view "$PR" -R [REPLACE: WATCHED_REPO] --json title,body,additions,deletions,files,author > .pr-meta.json gh pr diff "$PR" -R [REPLACE: WATCHED_REPO] > .pr-diff.patchSkip if
additions + deletions > [REPLACE: MAX_PR_LINES]— flag it asDEFERRED: too large for first-touch review, leave a note, and move on. -
Apply the rubric — assign one of four verdicts:
Verdict Trigger ACCEPT Touches expected paths, follows repo conventions, focused scope, no obvious bugs in the diff. NEEDS-CHANGES Reasonable intent but specific issues: missing tests, broken format, incorrect assumption, naming. DEFER Out of scope for this skill — needs a human reviewer (large refactor, architectural change). OUT-OF-SCOPE Touches files outside what the repo accepts contributions on (e.g. lock files, generated assets). Focus the rubric on [REPLACE: REVIEW_FOCUS] — that's the lens that matters most for this repo.
-
Post a comment — use a friendly, specific tone. Acknowledge the contributor, name the verdict, give 1-3 concrete bullets:
gh pr comment "$PR" -R [REPLACE: WATCHED_REPO] --body "Thanks for the PR! [verdict text] - [bullet 1] - [bullet 2]" -
Label the PR via
gh pr edit "$PR" -R [REPLACE: WATCHED_REPO] --add-label "<label>"— useaccepted/needs-changes/defer/out-of-scope(create the labels in the target repo first if they don't exist). -
Notify via
./notifyonly onACCEPTorOUT-OF-SCOPE— those are the actionable verdicts for the operator. Silent onNEEDS-CHANGESandDEFER(the comment on the PR is the signal). -
Log — append to
memory/logs/${today}.md:## [REPLACE: SKILL_NAME] - **PRs reviewed**: N (skipped M as previously seen) - **Verdicts**: accept=X, needs-changes=Y, defer=Z, out-of-scope=W - **Status**: REVIEW_OK | REVIEW_QUIET (no new PRs)
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.
- 2d ago First seen · 80 lines · 0 tokens per session scan A 5b9bc341a60c
[REPLACE: SKILL_NAME] is a skill published in the GitHub repository aeonfun/aeon (706 stars, last pushed 2d ago), licensed MIT. It adds 33 tokens to every session and 1,058 once invoked, about $0.0002 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 skills, from other repositories
agent-framework-py-release
Use when cutting a Python release for the microsoft/agent-framework monorepo. Triggers on "bump py versions", "cut a python release", "prepare release PR for python", "release py packages", "bump python to X.Y.Z", or similar requests to bump Python package versions and prepare a release PR. Handles all four lifecycle…
python-package-management
Guide for managing packages in the Agent Framework Python monorepo, including creating new connector packages, versioning, and the lazy-loading pattern. Use this when adding, modifying, or releasing packages.
foundry-hosted-agent-validation
Step-by-step process for validating a Python Foundry hosted agent sample (under python/samples/04-hosting/foundry-hosted-agents/) end to end — running it locally (native runtime and azd ai agent run) and after deploying it to an Azure AI Foundry project with azd. Use this when asked to validate a hosted agent sample.
verify-samples-tool
How to use the verify-samples tool to run, verify, and manage sample definitions in the Agent Framework repository. Use this when adding, updating, or running sample verification.
build-and-test
How to build and test .NET projects in the Agent Framework repository. Use this when verifying or testing changes.
python-feature-lifecycle
Guidance for package and feature lifecycle in the Agent Framework Python codebase, including stage meanings, feature-stage decorators, feature enums, and how to move APIs from one stage to the next.