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 skills add pilotspace/ADD --skill add-4-leangit clone --depth 1 https://github.com/pilotspace/ADDWrote 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/pilotspace/add/add-4-lean)<a href="https://agentmods.dev/skills/pilotspace/add/add-4-lean"><img src="https://agentmods.dev/badge/skills/pilotspace/add/add-4-lean/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/pilotspace/add/add-4-lean"><img src="https://agentmods.dev/badge/skills/pilotspace/add/add-4-lean.svg" alt="Reviewed on agentmods" width="80" 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.00212 | $0.03417 |
| Opus 5.5 | $0.00085 | $0.01367 |
| Sonnet 5.5 | $0.00042 | $0.00683 |
| Haiku 4.5 | $0.00021 | $0.00342 |
Grade A, and why
add 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 15d 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.
How it starts
The opening of the file, as written. The whole thing — 201 lines — stays where its author put it; the contents beside it link to each section on GitHub.
ADD — direction · evidence · a durable bundle
You are the planner and the hands: fix direction before the build, trust only evidence you produced,
leave a bundle (.add/) the next session and the reviewer can read. Your tools: files, git, tests.
Orient — every session, first, in one command
cat .add/PROJECT.md; grep -lE '^status: (direction|build|active)' .add/tasks/*.md .add/milestones/*.md; git log --oneline -15
— goal:, invariants: (they bind every change), test_cmd:, and the open work. Resume an open
task at its status:; otherwise size the request. Read what the task touches, never the whole repo.
No .add/ yet → create PROJECT.md and empty specs/ milestones/ tasks/ (references/format.md).
Turns — the real cost
Every turn re-reads the whole context: cost grows with turns, not words. Keep every step; cut round-trips:
- Direction = three turns. (1) One command reads what the task touches and finds how the tests run,
installing what is missing in that same command. (2) The task file and its tests; stub only what the
checks import (usually one module), raising
NotImplementedErrorso the first run fails on behavior, not imports — Build writes the rest. All as parallel writes in one message. (3) one command runs the checks and seals:<check> ; git add .add/tasks/<slug>.md <tests> && git commit -qm "freeze(<slug>): <goal>". Green, or red on an import error: fix it,refreeze. - Build: write several files per turn; run the checks once per batch, not per file.
- Verify = two turns. One command runs the seal diff,
check:,regression:and the consumers' tests; then write## EVIDENCEand commitverify(<slug>)in one more. - Subagents: at most one per beat, in the foreground — never pause the session to wait for one.
Size the work — you route and go
| the request | lane | what persists |
|---|---|---|
| mechanical, or a small behavior: ≤3 adjacent files, one sitting, no unknowns | Quick | a red→green test + one commit |
| one behavior worth a written contract | Task | .add/tasks/<slug>.md + its commits |
| the answer IS the deliverable — investigate · evaluate · research | Explore (references/explore.md) |
the task's ## FINDINGS |
| a theme, or more than one task | Milestone | .add/milestones/<slug>.md + its tasks |
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.
- 15d ago First seen · 201 lines · 212 tokens per session scan A 3073cab00cd6
add is a skill published in the GitHub repository pilotspace/ADD (19 stars, last pushed 4d ago), licensed MIT. It adds 212 tokens to every session and 3,417 once invoked, about $0.0008 per session on Opus 5.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-10-01.
Other skills, from other repositories
contract
Outcome-driven Cortex function development — declares a behavioral contract before generation begins, enforces evidence-tiered proof before $ship, and defends against the self-oracle evaluation failure mode.
08-debug
Reproduce and fix a known bug, or find an unknown root cause by hypothesis validation. Use when the user wants to fix a bug, find why something breaks, or reopen a stuck investigation. Not for building a feature or reviewing a diff.
tdd-workflow
Drive implementation through a test-first loop: write a failing test, make it pass with the simplest change, then refactor under a green suite. Use when the user asks for TDD or test-driven development, wants tests written before the code, is adding behaviour to code that has tests, is fixing a bug and wants a…
spec-driven-task-decomposer
Use this skill when approved requirements and design need to be decomposed into tasks.md for Phase 3 of a Spec-Driven change. It creates atomic, traceable implementation and testing tasks, validates the plan, and should not be used to design architecture or write implementation code.
evidence-ledger
An evidence record for completion claims such as “fixed” or “tests passed.” TDD, or test-driven development, is a practice of first seeing a test fail, then making it pass, and checking it again after cleanup.
PlanGate TDD Evidence Review
A checker for TDD evidence. TDD, or test-driven development, means writing a failing test before the implementation, making it pass, and then improving the code; this checker verifies records of those stages.