Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add crenshawdev/cadence/plugin install cadenceWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/crenshawdev/cadence/cad-verifier-contract)<a href="https://agentmods.dev/skills/crenshawdev/cadence/cad-verifier-contract"><img src="https://agentmods.dev/badge/skills/crenshawdev/cadence/cad-verifier-contract.svg" alt="Measured on agentmods" height="20"></a>What 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.1 | $0.00024 | $0.02714 |
| Opus 5 | $0.00012 | $0.01357 |
| Sonnet 5 | $0.00005 | $0.00543 |
| Haiku 4.5 | $0.00002 | $0.00271 |
Grade A, and why
cad-verifier-contract 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.
How it starts
The opening of the file, as written. The whole thing — 240 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are dispatched by cad-verify (spawn-agent seam) with the phase number,
goal, the current UAT items, and artifact paths. You write exactly ONE
file - .planning/phases/<N>/verifier-findings.json, in a single Write
call - and your final message is a digest plus that path. The orchestrator
pipes that file straight into uat merge; nothing is transcribed by hand.
How verifiers go soft - do none of these:
- Trusting SUMMARY bullets without reading the files they describe.
- Accepting "file exists" as "works" - a stub satisfies existence.
- Marking UNCERTAIN when absence is observable - that is FAILED.
- Letting early passes buy later truths less scrutiny.
<core_principle> Task completion != goal achievement. "Create login handler" is complete the moment the file exists; the goal "users can log in" needs the handler to be real, reachable, and working. Work backward from the goal:
- What must be TRUE for the goal to hold? (3-7 observable truths)
- What must EXIST for each truth?
- What must be WIRED for each artifact to matter?
- Does it BEHAVE when exercised? </core_principle>
1. Load context
- Phase goal + success criteria:
.planning/ROADMAP.md. - Acceptance criteria:
.planning/phases/<N>/CONTEXT.mdif present. PLAN.md: tasks and their verification lines.SUMMARY.md: claims to falsify, files touched. Treat its "Goal check" paragraph as assertions, not evidence - lift each concrete claim it makes (a setting is X, a mode is enabled, a value is Y) into a candidate truth and verify it against reality. A SUMMARY that states an outcome it never actually confirmed is exactly what this pass exists to catch.REQUIREMENTS.mdrows mapped to this phase, if the file exists.- The UAT items passed in the prompt - map findings onto them by item number wherever possible.
If the prompt includes previous findings (a re-check after fixes), verify the previously failed items in full; regression-check previously passed ones with a quick existence + wiring look only.
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 Changed · +1 lines 69c692f2d5bd
- 6d ago First seen · 239 lines · 24 tokens per session scan A e497777e2336
cad-verifier-contract is a skill published in the GitHub repository crenshawdev/cadence (4 stars, last pushed yesterday), licensed MIT. It adds 24 tokens to every session and 2,714 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 skills, from other repositories
branch-and-worktree-workflow
Isolates feature work in its own branch or worktree and integrates it cleanly when done. Use this when starting work that should not disturb the current workspace, when several efforts must proceed in parallel on one repository, or when implementation is finished and the change needs merging, rebasing, or splitting…
loop-on-ci
Monitor PR checks and fix failures until green. Uses gh pr checks as the source of truth for PR-attached checks.
git-operations
Git command patterns, branching strategy, and safety protocols. TRIGGER when: managing branches, resolving merge conflicts, or running commit/merge/push operations. SKIP: worktree lifecycle and isolation recovery (use worktree-management); CI automation (use github-actions-template).
dockerized-service-release-deployment-workflow
Create a Dockerized-service release contract with clean GitHub Actions builds, main-anchored tags, immutable digest manifests, published-release deployments, production approval, health checks, and exact-digest rollback.
coordinate-worktrees-and-threads
Assign worktree, branch, write, validation, integration, and cleanup ownership before parallel repository work. Use when a worker will inspect or modify repository state outside the coordinator's worktree.
agile-ledger-workspace
Optional multi-repo orchestrator for Agile-Ledger. Install once at a workspace root to manage many repositories at once: discover new repositories on a GitHub org (including ones nobody told you about), clone and bootstrap them, run a single cross-repo "what changed while I was away" sync, and reconstruct undocumented…