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/outlinedriven/odin-claude-plugin/contract-drivennpx skills add OutlineDriven/odin-claude-plugin --skill contract-drivengit clone --depth 1 https://github.com/OutlineDriven/odin-claude-pluginWrote 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/outlinedriven/odin-claude-plugin/contract-driven)<a href="https://agentmods.dev/skills/outlinedriven/odin-claude-plugin/contract-driven"><img src="https://agentmods.dev/badge/skills/outlinedriven/odin-claude-plugin/contract-driven.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.00052 | $0.00814 |
| Opus 5 | $0.00026 | $0.00407 |
| Sonnet 5 | $0.00010 | $0.00163 |
| Haiku 4.5 | $0.00005 | $0.00081 |
Grade A, and why
contract-driven 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.
Copies of this mod
2 near-identical copies found in the catalogue:
- design-by-contract — 92% identical, 153 lines differ
- design-by-contract — 92% identical, 153 lines differ
How it starts
The opening of the file, as written. The whole thing — 51 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Contract-driven
Contract
| Field | Bound contract |
|---|---|
| Trigger | Crossing a public API boundary, guarding complex invariants, or hardening untrusted input or integration seams. |
| Authority | Write only named local types, assertions, validators, and tests at contract boundaries; rollback is deleting the added local code or reverting the boundary change. |
| Side effect | Adds or refines local types, assertions, validators, and tests at contract boundaries. |
| Done | Every planned contract is implemented at the appropriate static/test/debug/runtime layer and violations fail explicitly at the boundary. |
Inputs
Required:
- The requirements or specification for the operation whose contract is being designed.
- The target source file or module containing the public API boundary, invariant, or untrusted seam.
Optional:
- Existing tests that must continue to pass.
Procedure
- Plan: extract PRE/POST/INV from the requirements. Give each contract an ID and a one-line description (e.g. PRE-1: amount > 0; POST-1: balance == old(balance) - amount; INV-1: balance >= 0). Do not begin implementation until every planned contract has an ID. Done when: every planned contract has an ID and a one-line description.
- Select verification level: choose the strongest layer that can enforce each contract, preferring static over runtime:
- Static type system or static_assert for type size, alignment, null/type safety, and exhaustiveness.
- Test assertions for expensive O(n)+ properties.
- Debug-only invariants for internal invariants.
- Runtime guards for public API input, and always for external or untrusted input. If a property can be verified statically, do not add a runtime contract. Done when: every contract has a selected verification level, static preferred over runtime.
- Create: implement every PRE, POST, INV at its chosen level in the target local code. Runtime contracts, where used, must be active and not compiled out or disabled. Done when: every contract is implemented at its chosen level and runtime contracts are active.
- Verify: run the type checker, static analysis, and build. Contracts must compile and lint. Done when: the type checker, static analysis, and build pass with all contracts.
- Test: write one violation test per PRE/POST/INV proving the contract catches bad input or bad state. Static contracts are verified by the type checker; runtime contracts by violation tests that assert the boundary fails explicitly. Done when: one violation test per contract passes, proving the boundary fails on bad input or state.
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · -77 lines · +18 tokens per session 1d1fb117abd0
- 5d ago First seen · 128 lines · 34 tokens per session scan A 0d71ed2b9bec
contract-driven is a skill published in the GitHub repository OutlineDriven/odin-claude-plugin (35 stars, last pushed today), licensed Apache-2.0. It adds 52 tokens to every session and 814 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-30.
Other skills, from other repositories
java-clean-arch
Reviews or implements Clean Architecture / Hexagonal Architecture (Ports & Adapters) and DDD tactical patterns for Java projects. Use when user asks to "apply clean architecture", "implement hexagonal architecture", "add ports and adapters", "apply DDD", "refactor to clean arch", "review architecture", or "add value…
java-adr
Creates, lists, and manages Architecture Decision Records for Java projects. Use when user asks to "create an ADR", "document this decision", "write an architecture decision", "add ADR", "list decisions", "show ADRs", or "record this architectural choice".
java-jpa
Reviews Spring Data JPA for N+1 queries, fetch strategies, projections, and Specifications. Use when user asks to "review JPA", "check for N+1", "JPA performance", "review my entities", "check fetch strategy", or "review my repositories".
java-logging
Reviews Java logging for SLF4J best practices, MDC context, structured logging, and PII safety. Use when user asks to "review logging", "check my logs", "logging review", "is my logging correct", "MDC setup", or "check for PII in logs".
java-security
Reviews or implements Spring Security configuration — JWT authentication, OAuth2, method-level security, CORS, and CSRF. Use when user asks to "add authentication", "secure this API", "implement JWT", "configure Spring Security", "add OAuth2 login", "protect endpoints", or "review security config".
java-health
Runs a holistic code health check scoring Security, Tests, Performance and Quality with A-F grades. Use when user asks to "check health", "score this project", "health check", "how good is this code", "overall assessment", or "code quality score".