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/agent-field/agentfield/agentfield-usenpx skills add Agent-Field/agentfield --skill agentfield-usegit clone --depth 1 https://github.com/Agent-Field/agentfieldWhat 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.00259 | $0.09434 |
| Opus 5 | $0.00130 | $0.04717 |
| Sonnet 5 | $0.00052 | $0.01887 |
| Haiku 4.5 | $0.00026 | $0.00943 |
Grade A, and why
agentfield-use scanned grade A with 1 finding 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 3d 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
`-H 'X-API-Key: <key>'` for curl. Do not export `AGENTFIELD_SERVER` yourself to How it starts
The opening of the file, as written. The whole thing — 641 lines — stays where its author put it; the contents beside it link to each section on GitHub.
AgentField subharnesses — offload work instead of doing it inline
If AGENTFIELD_HARNESS_DEPTH is set, you are running inside an AgentField
harness session: do not dispatch to AgentField agents unless explicitly asked.
A machine with AgentField has one or more control planes — a local one
(default http://localhost:8080) and possibly a cloud deployment configured
in AgentField Desktop — plus agent nodes installed under ~/.agentfield.
Each node exposes reasoners: typed functions you call through the control
plane, which routes the call, records the run, and returns the result. You never
talk to an agent's own port.
Those installed agents are subharnesses: workers you offload to. They run on smaller, cheaper models, they run in parallel, they run off your context, and every run is recorded on the control plane and watchable in its web UI. A review that would cost you 40k tokens of reading costs you one dispatch and one result.
Vocabulary rule. Internally — commands, API fields, discovery output —
everything stays agent / reasoner / node, exactly matching the CLI and API.
In what you SAY TO THE USER, call them subharnesses: "your AgentField
subharnesses", "the pr-af subharness". Never let the wording cost clarity: if the
user needs a command or a node name, give the literal one.
Offload by default
Whenever you have a discrete task — one the user delegated, or one that arose inside your own work — the first question is not "how do I do this?" but "does an installed subharness cover this?" When one does, dispatching to it is the default path, not an option to offer.
Coverage is the test, not size. A small job a subharness covers still goes to the subharness; a large job nothing covers stays with you. This skill carries no list of offloadable task types and cannot: users install new subharnesses at any time, so runtime discovery (§1) is the only source of truth about what your fleet does.
The check is cheap — that is the whole design. One af ls -e (or one
capabilities call) answers "does anything cover this?". Discover once per
session, remember the roster, and match later tasks against what you learned;
re-discover only when something suggests the fleet changed — an install, a start,
or a miss you doubt. Consulting this skill on a task nothing covers costs one
cheap lookup. That is the trade, deliberately.
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.
- 3d ago First seen · 641 lines · 259 tokens per session scan A 3724dc056934
agentfield-use is a skill published in the GitHub repository Agent-Field/agentfield (2,545 stars, last pushed yesterday), licensed Apache-2.0. It adds 259 tokens to every session and 9,434 once invoked, about $0.0013 per session on Opus 5. A static security scan graded it A with 1 finding (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
copilotkit-upgrade
Use when migrating a CopilotKit v1 application to v2 -- updating package imports, replacing deprecated hooks and components, switching from GraphQL runtime to AG-UI protocol runtime, and resolving breaking API changes.
babysit
Same-session monitoring loop for PRs, CI runs, tickets, and deployments using the monitorstart / monitorupdate / autonudgestop MCP tools. The loop re-injects your check instructions into THIS session on an idle interval — same context, same tools — and works from dashboard chat, Slack threads, and Discord DMs. Use…
mochi-plan
INTERNAL pet queue — generates the pet's 30-minute behavior schedule (moves, moods, notifications). NOT for user task or calendar planning.
explain-for
Explain a topic, a piece of code, an error, or a design decision calibrated to one named audience — a 5-year-old, a 5th grader, a manager, a designer, a graduate student, a parent. Resolves who the explanation is for (from the request, or from what memory already records about that person), establishes the ground…
goal-loop
Bootstrap a goal-driven self-improving AutoNudge loop. Give it a goal + anchor directory; it generates LOOP.md + GOAL.md + kanban board, then you write the Definition of Done and arm the loop. The running agent manages the board autonomously: finds issues, adds cards, resolves them, handoffs to Review, repeats until…
spec-workflow
Drive the Kiro CLI v3 spec workflow (Requirements → Design → Tasks → Execution) for the Spec Builder app. Load when authoring a spec inside a spec-builder worker slot, or when the seed prompt references a spec directory and a spec type.