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/silo-code/silo/silo-docs-syncnpx skills add silo-code/silo --skill silo-docs-syncgit clone --depth 1 https://github.com/silo-code/siloWhat 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.00092 | $0.01095 |
| Opus 5 | $0.00046 | $0.00548 |
| Sonnet 5 | $0.00018 | $0.00219 |
| Haiku 4.5 | $0.00009 | $0.00110 |
Grade A, and why
silo-docs-sync 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 — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Keep docs in sync AS YOU BUILD
The API reference is generated from the source, so documentation is not a separate chore — it's part of changing the code. Whenever you touch the public extension surface, do the documentation in the same change.
The public surface is the @silo-code/sdk barrel packages/sdk/src/index.ts
and everything it re-exports (types.ts + the *-service.ts type contracts +
context-keys.ts, all under packages/sdk/src/).
The docs site has two layers (see apps/docs/):
- Hand-authored, member-centric pages — the navigable narrative organized by
what you do with
ctx:apps/docs/api/index.md(overview + shape diagram), then one subdirectory perctxdomain (apps/docs/api/registration/,apps/docs/api/editors/,apps/docs/api/state/,apps/docs/api/storage/,apps/docs/api/other/, …), one page perctxmember. TheapiSidebarinapps/docs/.vitepress/config.tsis the source of truth for the current set of domains. - Generated type leaves — TypeDoc renders the SDK types into
apps/docs/api/types/(drill-down targets, linked from the member pages).
When you add or change a public symbol (a new ctx method, a new type, a new
field):
- Write TSDoc on it — a summary plus per-member docs. Use
{@link Other}to cross-reference. Mandatory: every exported public symbol must be documented. - Tag it. Add exactly one of
@public/@internal, and a@category(one of:Extension Contract,Registration,Consumer Services,Core Types).@internalkeeps host-only exports out of the reference. - If it's a genuinely public type, re-export it from
packages/sdk/src/index.ts(the barrel is the declared surface; if it's not in the barrel, it's not public). - If you added a
ctxmember, add its hand-authored page underapps/docs/api/<domain>/<name>.md(copy an existing one for the shape: blurb → signature → example → type links → see-also) and add it to theapiSidebarinapps/docs/.vitepress/config.ts. Link it from the overview table inapps/docs/api/index.md. - Regenerate the type reference:
pnpm docs:api(writesapps/docs/api/types/, committed so growth shows in diffs). - Update the guides in
apps/docs/guide/if the change is user-facing. Guides link to member pages (/api/registration/...) and types (/api/types/...). - Flip its status on the Roadmap from
plannedtostable(the<Badge>). The roadmap is the source of truth for what's real.
Docs-driven development: the public Roadmap (apps/docs/roadmap.md) is the
source of truth for what's real; design decisions live as ADRs (docs/decisions/)
and proposals (docs/proposals/). Design a new primitive by adding it to the
roadmap as planned (with its sketched surface) first, then implement it and
flip it to stable. The roadmap going all-green on core = the inflection point
where new features become extensions, not core changes.
When you expand ExtensionContext (ctx) — the main ongoing work — that is
exactly the moment to do all of the above. A documented ctx surface is both
the invariant #4 burn-down and the docs site growing. They are the same act.
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 · 71 lines · 92 tokens per session scan A ebfbcc5546d8
silo-docs-sync is a skill published in the GitHub repository silo-code/silo (53 stars, last pushed 2d ago), licensed MIT. It adds 92 tokens to every session and 1,095 once invoked, about $0.0005 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
aoe
Use when launching, monitoring, or controlling AI coding agents (Claude Code, Codex, OpenCode, etc.) in tmux via Agent of Empires (aoe). Covers creating sessions, capturing agent output, running parallel worktree agents, and organizing work into groups and profiles. Prefer aoe over raw tmux for agent management.
aoe
Manage AI coding agent sessions via Agent of Empires (aoe).
agtx-sweep
Sweep this conversation into agtx tasks and push them to the kanban board. Use when the user wants to capture, decompose, or hand off conversation results to the agtx board.
agtx-plan
Plan a task implementation. Analyze the codebase, create a detailed plan, write it to .agtx/plan.md, then stop and wait for user approval before making any changes.
agtx-research
Explore the codebase to understand a task before planning. Write findings to .agtx/research.md and stop. This is a read-only exploration — do not modify any files.
agtx-execute
Execute an approved implementation plan. Implement the changes, then write a summary to .agtx/execute.md and stop.