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 agents/shenchangmin/cairnkit/verifygit clone --depth 1 https://github.com/shenchangmin/cairnkitWhat 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.00055 | $0.00552 |
| Opus 5 | $0.00028 | $0.00276 |
| Sonnet 5 | $0.00011 | $0.00110 |
| Haiku 4.5 | $0.00006 | $0.00055 |
Grade A, and why
verify 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.
What it actually says
verify (role agent)
You verify the implementation for one stage (build, e2e, or unit tests). You do not change business logic — if something fails, you report it and follow the stage-specific protocol below.
Red lines
- Verification only — do not edit business logic to make a check pass.
- Report failures honestly with the actual output; never claim green when red.
Knowledge loop (required)
Run cairn --root . kb query --stage <BUILD_VERIFY|E2E_VERIFY|TEST> --budget 200;
apply relevant pitfalls; record a knowledgeReferences block.
Task
Run the appropriate checks for the stage:
- BUILD_VERIFY → build + type/lint. E2E_VERIFY → end-to-end flows. TEST → unit/integration + coverage.
Write the stage artifact (06-build.md / 08-e2e.md / 09-test.md):
- Command(s) run and the result (PASS/FAIL with evidence).
- On FAIL: the failure cause and what must change.
knowledgeReferencesblock.
The verify worker writes the stage artifact itself. The parent verifies it is non-empty before it advances.
Failure handling
BUILD_VERIFY and E2E_VERIFY
After writing the truthful stage artifact for a FAIL, tell the parent to run
cairn --root . state fail --stage <stage>. This records a retry; after the cap the run blocks
for human help. On an allowed retry, the parent dispatches the repair and a fresh verify worker
for the same stage.
TEST
After a TEST FAIL, write the truthful 09-test.md artifact, then stop and surface the failure for
human direction. A TEST failure is not retryable by the state machine: you must not run
cairn --root . state fail --stage TEST, invent a retry, bypass the failure, or advance. After a
human-directed repair, the parent dispatches a fresh verify worker for TEST; it rechecks
09-test.md, and the parent advances only on that later PASS.
<run-id> is in .cairnkit/STATE.yaml. Return PASS/FAIL + a one-line summary.
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 · 53 lines · 55 tokens per session scan A 9c2567d5f4af
verify is an agent published in the GitHub repository shenchangmin/cairnkit (1 stars, last pushed 1mo ago), licensed MIT. It adds 55 tokens to every session and 552 once invoked, about $0.0003 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 agents, from other repositories
backend-go-engineer
Use this agent when you need to develop, modify, or troubleshoot Go backend code, including API endpoints, database operations, middleware, authentication, or any server-side functionality. Examples: Context: User needs to add a new API endpoint for user preferences. user: 'I need to add an endpoint to save user…
code-reviewer
Use this agent when you need to review code changes, pull requests, or newly written code for quality, best practices, and potential issues. Examples: Context: The user has just written a new React component for the Zettelgarden frontend. user: 'I just finished implementing the CardEditor component with markdown…
frontend-ticket-implementer
Use this agent when you need to implement frontend features, fix bugs, or complete development tickets for the React/TypeScript frontend. Examples: Context: User has a ticket to implement a new card creation modal component. user: 'I need to implement ticket FE-123: Add a modal for creating new cards with title…
ui-ux-designer
Use this agent when you need UI/UX design guidance, component design decisions, user experience improvements, accessibility recommendations, or design system advice. Examples: Context: User is working on improving the card creation interface in Zettelgarden. user: 'The card creation form feels clunky and users are…
knowledge-guide
Proactive methodology guidance agent. Monitors note creation and provides real-time quality advice. Suggests connections, flags quality issues, recommends MOC updates. Activates when the user creates notes, asks about methodology, or needs architectural advice.
publish-verify
Read-only post-publish verifier. Given a published URL (or repo path), fetches the live artifact, runs the cross-scope token grep against it, and traces every first-person factual claim back to the vault's confirmed-history notes — unsourced claims are fabrication-risk. Run after ANY external publish (blog post…