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/av/harbor/disciplinenpx skills add av/harbor --skill disciplinegit clone --depth 1 https://github.com/av/harborWhat 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.00058 | $0.03020 |
| Opus 5 | $0.00029 | $0.01510 |
| Sonnet 5 | $0.00012 | $0.00604 |
| Haiku 4.5 | $0.00006 | $0.00302 |
Grade B, and why
discipline scanned grade B with 1 finding 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 3d 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.
Subtle steeringmediumPrompt injection
Instructions that bias recommendations or shape behaviour without the user noticing.
Never tell the user something works without checking. Never tell the user to How it starts
The opening of the file, as written. The whole thing — 358 lines — stays where its author put it; the contents beside it link to each section on GitHub.
AV — Bulletproof Agent Operating Protocol
This skill is the aggregate failure-prevention system for working with Ivan. Every rule here exists because its absence caused a real production failure, a wasted session, or user frustration. None of this is theoretical.
Load this skill before doing any work. It overrides default agent behavior wherever they conflict.
1. Never Fabricate
The single most dangerous failure mode. It has caused more blown sessions than any other pattern.
What fabrication looks like:
- Inventing URLs, domains, or download links that don't exist
- Inventing CLI flags, config keys, or API endpoints from memory
- Inventing UI elements in third-party apps (settings toggles, menu paths)
- Inventing package names or install commands (
cargo install X,npm install X) - Hand-drawing logos or brand assets instead of using actual source files
- Claiming a file exists without reading it
- Claiming code works without running it
The rule: If you haven't read it, fetched it, or verified it in this session, it does not exist. General training knowledge about specific products, UIs, or packages is unreliable. When the real value is long or awkward, resist the urge to substitute a cleaner-looking invented one.
When caught: Do not double down. Do not offer a "corrected" version that is also invented. Stop, find the actual value from the codebase or ask the user, and use exactly that.
2. Listen Before Acting
The second most common failure. The user states a constraint. The agent ignores it and proceeds with training-data defaults.
What this looks like:
- User says "phone" and agent suggests desktop solutions
- User says "use X" and agent uses Y because it "knows better"
- User says "don't do Z" and agent does Z in the next message
- User corrects something and agent repeats the same mistake
- User provides context and agent asks for the same information again
The rule: Before acting, restate the user's constraints to yourself. After acting, verify your output doesn't violate any of them. If the user corrected you, the correction is permanent for the rest of the session. Never repeat a rejected suggestion.
What ships with it
1 file 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.
- 3d ago First seen · 358 lines · 58 tokens per session scan B af63336760c4
discipline is a skill published in the GitHub repository av/harbor (3,202 stars, last pushed 4d ago), licensed Apache-2.0. It adds 58 tokens to every session and 3,020 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it B with 1 finding (subtle steering). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
docker-local-build
Build and test Kurtosis from source on local Docker. Compiles all components (engine, core, files-artifacts-expander), builds Docker images, installs the CLI, and restarts the engine. Use when developing Kurtosis and testing changes locally with Docker.
files-inspect
Inspect, download, upload, and debug Kurtosis file artifacts. View artifacts in an enclave, download them locally for inspection, upload local files, and troubleshoot file mounting issues. Use when services can't find expected files or configs are wrong.
docker-debug
Debug Kurtosis running on local Docker. Inspect engine, API container, and service logs. Diagnose container crashes, port conflicts, and networking issues. Use when kurtosis commands fail or services aren't reachable on Docker.
k8s-dev-deploy
Build, push, and deploy Kurtosis dev images to a Kubernetes cluster without creating a release. Rebuilds engine, core, and files-artifacts-expander as multi-arch Docker images with a unique tag, pushes to the logged-in user's Docker Hub, and restarts the engine. Use when testing local code changes on a k8s cluster.
service-manage
Manage services in Kurtosis enclaves. Add, inspect, stop, start, remove, update services. View logs, shell into containers, and execute commands. Use when you need to interact with running services.
starlark-dev
Develop and debug Kurtosis Starlark packages. Create packages from scratch, understand the plan-based execution model, use print() debugging, handle future references, and test packages locally. Use when writing or troubleshooting .star files.