Claude Octopus is an orchestration project that sends research, design, and coding tasks to Claude Code and other AI model providers so their results can be compared. Developers use it for multi-model work, disagreement detection, reviews, persistent context, and an optional workflow that moves from discovery through delivery. The catalogue entries are its commands, skills, agents, instructions, hooks, plugins, and settings.
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 nyldn/claude-octopus --skill skill-tddgit clone --depth 1 https://github.com/nyldn/claude-octopusWrote 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/nyldn/claude-octopus/skill-tdd)<a href="https://agentmods.dev/skills/nyldn/claude-octopus/skill-tdd"><img src="https://agentmods.dev/badge/skills/nyldn/claude-octopus/skill-tdd/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/nyldn/claude-octopus/skill-tdd"><img src="https://agentmods.dev/badge/skills/nyldn/claude-octopus/skill-tdd.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00019 | $0.00709 |
| Opus 5 | $0.00010 | $0.00354 |
| Sonnet 5 | $0.00004 | $0.00142 |
| Haiku 4.5 | $0.00002 | $0.00071 |
Grade A, and why
skill-tdd 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 2d 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 — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test-driven development
Read skills/blocks/engineering-method-selection.md from the installed plugin
for review admission. Natural-language requests and --peer-review share that
policy. Honor host-only requests; risk alone does not authorize paid usage.
Run the red, green, and refactor cycle on the current host. Routine TDD makes
zero additional provider dispatches. Use one external reviewer only when the
user passes --peer-review, explicitly requests independent review, or an
existing risk policy requires it. Explicit debate, council, and multi-model
commands retain their own execution contracts.
The rule
Do not change production behavior until a focused test fails for the expected reason. Existing implementation outside the requested change remains intact.
- Name the observable behavior and the smallest public boundary that proves it.
- Write one focused test. Directly test an internal invariant only when the public boundary cannot isolate its failure mode.
- Run it and record the expected failure, command, and exit status.
- Implement the smallest change that passes.
- Run the focused test, then the affected suite.
- Refactor only while the tests remain green.
If a test passes before implementation, it is not red evidence. If it errors due to fixture or syntax problems, repair the test until it fails on the missing behavior.
Consolidating tests
Do not equate similar assertions with duplicate guarantees. Keep separate OS,
security, cancellation, and integration boundaries. For every removed test,
record old_test, behavior, replacement, mutant, red_observed,
baseline_ms, candidate_ms, and reason. The retained test must kill the
named mutant at the intended caller boundary.
After one warm-up, measure five isolated runs and report every sample and the median. Review a slowdown only when it exceeds both 20 percent and 100 ms.
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.
- 2d ago Changed · -238 lines fb6141e03082
- 6d ago First seen · 319 lines · 19 tokens per session scan A 7aeacac2f922
skill-tdd is a skill published in the GitHub repository nyldn/claude-octopus (4,056 stars, last pushed yesterday), licensed MIT. It adds 19 tokens to every session and 709 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-09-03.
Other skills, from other repositories
legacy-code-expert
Use this agent when you need to safely modify legacy code that lacks tests. It applies Michael Feathers' dependency-breaking techniques from "Working Effectively with Legacy Code" to identify seams, plan characterization tests, and recommend safe transformation paths.
atdd-developer
This skill should be used when implementing features using Acceptance Test Driven Development. It guides through the RED/GREEN/REFACTOR cycle with explicit permission gates between phases.
auto-loop
TDD-based autonomous development loop with checkpoint recovery and observability changelog.
workflow
Run the complete 5-step development workflow: focus problem → prevent over-development → test-first (TDD) → document → smart commit. Use when starting a new feature, or when the user runs /workflow or asks for the full development flow.
test-first
Drive one feature through a strict TDD Red-Green-Refactor cycle with checklists for each phase. Use when implementing new functionality test-first, or when the user runs /test-first.
specify-incremental
Decompose a single-feature specification into a linear, phase-by-phase implementation plan. Use this for medium-complexity work — single feature, one or two components — where transparent human-in-the-loop phase review is preferred over factory automation.