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-probegit 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-probe)<a href="https://agentmods.dev/skills/pilotspace/add/add-4-probe"><img src="https://agentmods.dev/badge/skills/pilotspace/add/add-4-probe/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-probe"><img src="https://agentmods.dev/badge/skills/pilotspace/add/add-4-probe.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.03450 |
| Opus 5.5 | $0.00085 | $0.01380 |
| Sonnet 5.5 | $0.00042 | $0.00690 |
| Haiku 4.5 | $0.00021 | $0.00345 |
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 8d 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.
This is a copy
98% identical to add — 29 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 204 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).
Batch the work
Each round-trip re-reads the whole context, so put independent reads and writes in one message:
- Direction: one command reads what the task touches and finds how the tests run, installing what
is missing. Then 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 — as parallel writes. Then 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 message; run the checks once per batch, not per file.
- Verify: one command runs the seal diff,
check:,regression:and the consumers' tests; then write## EVIDENCEand commitverify(<slug>). - Subagents: at most one per beat, in the foreground.
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.
- 8d ago First seen · 204 lines · 212 tokens per session scan A 349c2c64b151
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,450 once invoked, about $0.0008 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 98% identical to add, differing in 29 lines, and is treated as a copy.
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.