Continuous-Claude-v3 is a Claude Code development environment that preserves working context between sessions, coordinates specialized agents, and stores project knowledge through ledgers, handoffs, and analysis tools. It is for people using Claude Code on ongoing or complex software work. Its catalogue entries are the skills, agents, hooks, plugin, and setting that provide its workflows and orchestration.
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 parcadei/Continuous-Claude-v3 --skill tddgit clone --depth 1 https://github.com/parcadei/Continuous-Claude-v3Wrote 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/parcadei/continuous-claude-v3/tdd)<a href="https://agentmods.dev/skills/parcadei/continuous-claude-v3/tdd"><img src="https://agentmods.dev/badge/skills/parcadei/continuous-claude-v3/tdd.svg" alt="Measured on agentmods" height="20"></a>- Socket pass
- Snyk pass
- 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.02335 |
| Opus 5 | $0.00010 | $0.01167 |
| Sonnet 5 | $0.00004 | $0.00467 |
| Haiku 4.5 | $0.00002 | $0.00233 |
Grade A, and why
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 5d 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 — 390 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/tdd - Test-Driven Development Workflow
Strict TDD workflow: tests first, then implementation.
When to Use
- "Implement X using TDD"
- "Build this feature test-first"
- "Write tests for X then implement"
- Any feature where test coverage is critical
- Bug fixes that need regression tests
TDD Philosophy
Overview
Write the test first. Watch it fail. Write minimal code to pass.
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
Violating the letter of the rules is violating the spirit of the rules.
The Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Write code before the test? Delete it. Start over.
No exceptions:
- Don't keep it as "reference"
- Don't "adapt" it while writing tests
- Don't look at it
- Delete means delete
Implement fresh from tests. Period.
Red-Green-Refactor
RED - Write Failing Test
Write one minimal test showing what should happen.
Good:
test('retries failed operations 3 times', async () => {
let attempts = 0;
const operation = () => {
attempts++;
if (attempts < 3) throw new Error('fail');
return 'success';
};
const result = await retryOperation(operation);
expect(result).toBe('success');
expect(attempts).toBe(3);
});
Clear name, tests real behavior, one thing.
Bad:
test('retry works', async () => {
const mock = jest.fn()
.mockRejectedValueOnce(new Error())
.mockResolvedValueOnce('success');
await retryOperation(mock);
expect(mock).toHaveBeenCalledTimes(3);
});
Vague name, tests mock not code.
Requirements:
- One behavior
- Clear name
- Real code (no mocks unless unavoidable)
Verify RED - Watch It Fail
MANDATORY. Never skip.
npm test path/to/test.test.ts
# or
pytest path/to/test_file.py
Confirm:
- Test fails (not errors)
- Failure message is expected
- Fails because feature missing (not typos)
Test passes? You're testing existing behavior. Fix test. Test errors? Fix error, re-run until it fails correctly.
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.
- 5d ago First seen · 390 lines · 19 tokens per session scan A d3f05b40b80b
tdd is a skill published in the GitHub repository parcadei/Continuous-Claude-v3 (3,936 stars, last pushed 7mo ago), licensed MIT. It adds 19 tokens to every session and 2,335 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
test-driven-development
Use when writing production code. Enforces RED-GREEN-REFACTOR cycle: write failing test, make it pass, improve design. Prevents test-after development and ensures verified behavior.
software-test-creation
Write failing tests for a TDD slice based on acceptance criteria and codebase conventions. Use when the "red" phase of red-green-refactor requires tests that define expected behavior before implementation exists. Discovers codebase test conventions first, writes test files that compile or parse but fail because the…
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…
test-driven-development
TDD workflow — Red, Green, Refactor cycle with practical examples.
tdd
Use when implementing features or bug fixes test-first.
test-driven-development
Write the test first, watch it fail, write minimal code to pass.