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/featurenpx skills add aeonfun/aeon --skill featuregit 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.00046 | $0.07141 |
| Opus 5 | $0.00023 | $0.03571 |
| Sonnet 5 | $0.00009 | $0.01428 |
| Haiku 4.5 | $0.00005 | $0.00714 |
Grade C, and why
feature scanned grade C with 2 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.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
rm -rf "$WORK_DIR" Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- Fetch the canonical upstream text **straight to disk with `curl`** so the body never passes through model output — `curl -fsSL https://www.contributor-covenant.org/version/2/1/code_of_conduct/code_of_conduct.md -o CODE Copies of this mod
1 near-identical copy found in the catalogue:
- feature — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 554 lines — stays where its author put it; the contents beside it link to each section on GitHub.
${var} — Selector
target[:arg] [--fix-issues],target ∈ {watched, external, dormant}. Empty orwatched= build a feature on every watched repo (one PR each);external:<owner/repo>= one best enhancement on that external repo;dormant= revive the highest-scoring dormant repo. A leadingbuild:<owner/repo | issue-url | free-text instruction>— the shape the Telegram "ship which opportunity?" force-reply sends viarepo-scanner's offer — is intercepted first and routed into the external branch on that target/instruction.--fix-issuesbiases the chosen branch toward fixing an open GitHub issue. Full grammar below.
This skill merges three repo-work modes behind one selector so no capability is lost:
| Branch | Selector | Per run | Repo source | Use it for |
|---|---|---|---|---|
| watched (§A) | empty / watched |
Iterates every watched repo, ships one PR per repo | memory/watched-repos.md |
Weekly broad sweep — keep every repo moving |
| external (§B) | external[:owner/repo[#N]] |
Single repo per run | memory/topics/repos.md catalog (or ${var} override) |
Targeted enhancement / issue fix on one repo |
| dormant (§C) | dormant[:owner/repo] |
Single dormant repo per run | memory/watched-repos.md scored by dormancy |
Reactivate a stale high-★ repo with one visible fix |
Today is ${today}. Read memory/MEMORY.md and the last 7 days of memory/logs/ before starting — and before notifying, drop anything already reported in the last ~3 days of logs.
Selector
Telegram force-reply interception — check this FIRST, before parsing anything else. If ${var} starts with build:, it is the "ship which opportunity?" force-reply that repo-scanner offers (routed here as feature with var="build:<the operator's reply>"). Strip the prefix with ${var#build:} and treat the remainder as an external build target/instruction — route it straight into the external branch (§B), reusing that branch's existing logic (do not run the watched or dormant branches for a build: value, and do not duplicate §B). Normalize the remainder into a §B target:
owner/repo→ run §B as ifexternal:owner/repo(B2 "clone that repo").- an issue URL (
https://github.com/owner/repo/issues/N) orowner/repo#N→ run §B as ifexternal:owner/repo#N(B2 "fetch that issue"). - free text like
owner/repo: add retry to the client→ run §B onowner/repo, using the trailing text as the explicit enhancement to build (see §B4's "requested enhancement" note — skip the auto-pick). - anything else with no parseable repo → run §B passing the whole remainder as the enhancement instruction; §B B2/B4 already reason about selecting and scoping a target.
The remainder may itself contain colons — keep them. This is a complete run once §B ships its PR (or cleanly skips); do not then fall through to the normal selector.
Parse ${var} into a target and optional flags:
- Empty or
watched→ watched branch (§A): sweep every watched repo, ship one feature PR each. watched:<feature-spec>→ watched branch, but build<feature-spec>on the FIRST watched repo only.external→ external branch (§B): auto-pick one catalog/watched repo and make the best single enhancement.external:<owner/repo>→ external branch on that specific repo.external:<owner/repo>#N→ external branch on that specific issue.dormant→ dormant branch (§C): auto-select the highest-scoring dormant repo and revive it.dormant:<owner/repo>→ dormant branch on that specific repo (skip selection).- Trailing
--fix-issues(with any target) → bias the branch toward fixing an OPEN GitHub issue rather than a proactive change (see each branch's "with--fix-issues" note).
Example values: `` (empty → watched sweep), watched, watched:add a dark-mode toggle, external, external:acme/api, external:acme/api#42, dormant, dormant:acme/legacy-lib, external --fix-issues, dormant --fix-issues.
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 · 554 lines · 46 tokens per session scan C 2a02d778f165
feature is a skill published in the GitHub repository aeonfun/aeon (706 stars, last pushed 2d ago), licensed MIT. It adds 46 tokens to every session and 7,141 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it C with 2 findings (recursive force delete, makes network calls). 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.