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/eai-org/agent-toolkit/handovernpx skills add eai-org/agent-toolkit --skill handovergit clone --depth 1 https://github.com/eai-org/agent-toolkitWhat 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.01101 |
| Opus 5 | $0.00016 | $0.00550 |
| Sonnet 5 | $0.00007 | $0.00220 |
| Haiku 4.5 | $0.00003 | $0.00110 |
Grade A, and why
handover 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.
How it starts
The opening of the file, as written. The whole thing — 90 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Handover
Package a finished change so its reviewers never reconstruct intent from the diff. Write for a reviewer holding the diff and nothing else — no planning docs, no session, no knowledge that either exists.
Resolve the task
The input is any partial reference — ticket id, slug, a planning artifact's path — or nothing,
meaning the session's task; in a fresh session, infer it from branch name and recent commits.
Resolve it to the task's planning home: its <id>-<slug>/ directory in the project's planning
directory, or its flat <id>-<slug>.* files in a shared family directory. One clear match →
proceed, stating the home and artifacts found. Inferred, or several candidates (-vN, …) →
confirm first. An explicit reference matching nothing local → stop and ask; never guess.
Gather
Read these, skipping what doesn't exist:
- Task artifacts — every
<id>-<slug>*.mdin the planning home: ticket, requirements, plan, decisions log, prior review and handover rounds, whatever else matches. - Related tickets — one hop only: parent (climbing higher only past thin containers), direct
predecessors/successors, explicit relations, family-directory siblings; never expand their own
relations. Local
.TICKET.mds first; fetch from the tracker only when a relation has no local file and looks load-bearing for a why — in doubt whether to fetch, ask. - The session, when it produced the change: decisions, pivots, constraints.
- The diff against the target, plus commit subjects.
An earlier artifact — a ticket review, a prior round — counts only where nothing later settled the point.
Each source once, no deeper than the artifact needs: skim the diff whole, deep-read only the files you will name in the Review guide, and never rebuild history commit by commit — which commit changed what is the diff's job, not yours.
Then match the plan's steps and acceptance criteria against the diff both ways — planned but absent, present but unplanned. Done when every source is read or confirmed absent and every planned item is matched.
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 · 90 lines · 33 tokens per session scan A 67a4cc07f1f2
handover is a skill published in the GitHub repository eai-org/agent-toolkit (43 stars, last pushed 12d ago), licensed MIT. It adds 33 tokens to every session and 1,101 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
gsd-audit-milestone
Audit milestone completion against original intent before archiving.
spec-kitty-charter-doctrine
Run charter interview, generation, context, and sync workflows for project governance in Spec Kitty 3.x. Access doctrine artifacts programmatically via DoctrineService. Resolve agent profiles. Load action-scoped governance context iteratively, not all at once. Triggers: "interview for charter", "generate charter"…
conductor-implement
Executes the tasks defined in the specified track's plan. Use this to start or continue working on a feature, bug fix, or chore.
api-design
Design or review an HTTP/REST/GraphQL API for versioning, pagination, error shapes, idempotency, auth, status codes, cache headers, and breaking-change management. Use when asked to "design an API", "shape the endpoints", "design the schema", "add a new endpoint", "review this API", or when building/modifying a public…
create-mcp-server
Build, iterate, and evaluate Model Context Protocol (MCP) servers that expose external services as tools an LLM can call. Covers schema/tool design, error handling, pagination, MCP Inspector testing, and an eval set. Use when asked to "build an MCP server", "create an MCP tool", "wrap this API as MCP", "expose X to…
dependency-upgrade
Plan, batch, and verify dependency upgrades safely. Triages outdated packages into risk tiers, upgrades in order (dev/minor/patch first, runtime majors last), verifies each batch, and produces an auditable commit sequence. Use when asked to "upgrade deps", "bump packages", "update nodemodules", "fix vulnerabilities"…