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 commands/wgo-audit/code/onboardgit clone --depth 1 https://github.com/wgo-audit/codeWhat 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.00019 | $0.00527 |
| Opus 5 | $0.00010 | $0.00264 |
| Sonnet 5 | $0.00004 | $0.00105 |
| Haiku 4.5 | $0.00002 | $0.00053 |
Grade A, and why
onboard 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 yesterday.
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.
What it actually says
/onboard
Load and use the WGO skill. Resolve audit roots with its
references/common/audit-root.md, then run its
references/common/onboarding.md.
The audit covers the full current project folder at detailed depth. Quietly perform read-only discovery and confirm company/product context. When a prior audit supplies the configuration, show that complete configuration and ask whether anything needs updating instead of repeating standard intake. When nothing needs updating, proceed directly. First-ever onboarding asks each intake question separately and waits for its answer; do not combine mandate, decision, concerns, and harmful-failure questions. WGO owns shared collection and dependency waves. Discover core and project-local external reviewer packages; external additions or core substitutions require explicit approval. Do not create a dated audit root before configuration approval unless the auditor explicitly asks for a marked provisional draft.
After approval, create the lean administrative files. Clone supplied accessible GitHub supporting-record refs into the audit temporary folder, identify documentation-bearing paths in audited code roots, then delegate exactly one documentation-preparation worker before asking to start the audit. Supply the mandate, selected reviewers, repository mappings, cheap capability signals, active audit platform, and selected same-platform catalog model; never request or use another provider's credentials. It creates only the catalog and its navigation signals; it does not ask intake questions or delegate further workers. If it flags material missing or unresolved content, show the concise list and ask whether the auditor wants to add sources. Ask for the sources only after a yes, then continue the same worker and model against the expanded corpus. Do not create other controls or artifacts merely because a template exists.
For default improve mode, preserve prior artifacts and IDs. For compare, keep
the selected baseline read-only and run only the reviewers needed to reassess
its material items. For blind-compare, keep the baseline hidden through audit
and synthesis, then compare the two completed audits.
For a reused configuration, the auditor's no answer to the configuration-
update question authorizes the audit to proceed without another start question.
First-ever onboarding still asks exactly: Should I proceed with wgo:audit all?
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.
- yesterday First seen · 50 lines · 19 tokens per session scan A c65d7c5dab57
onboard is a command published in the GitHub repository wgo-audit/code (2 stars, last pushed 9d ago), licensed MIT. It adds 19 tokens to every session and 527 once invoked, about $0.0001 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-31.
Other commands, from other repositories
krait
Run a complete multi-phase security audit on the target codebase.
krait-poc
Write and run a valid Foundry proof-of-concept that proves (or disproves) a Solidity exploit by asserting the actual harm on a forked chain or against local source.
init-brief
Initialize a briefloop workspace using conversational onboarding.
layout
Audit pipeline: choose how the manifest is stored — sharded (an index plus one file per phase: fewer tokens per phase run, parallel-safe across worktrees) or single-file (one file, one diff, no index). A layout CHOICE, not a version upgrade: both shapes are current, neither goes out of date, and this command moves in…
usage
Audit pipeline: token spend attributed by phase, task, model, author and time — with cache economics, cost-per-task and a usage trend. Read-only (never mutates the manifest).
krait-review
Re-examine findings killed by the Critic's automatic gates. Catches over-filtering without compromising the main report's zero-FP standard.