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/sharpninja/mcpserver/byrd-tdd-processnpx skills add sharpninja/McpServer --skill byrd-tdd-processgit clone --depth 1 https://github.com/sharpninja/McpServerWhat 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.00105 | $0.02015 |
| Opus 5 | $0.00053 | $0.01007 |
| Sonnet 5 | $0.00021 | $0.00403 |
| Haiku 4.5 | $0.00011 | $0.00201 |
Grade A, and why
byrd-tdd-process 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 — 86 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Byrd Development Process v4 (TDD)
The canonical reference is docs/Development-Process-draft-v4.md. This process aligns with Martin Fowler's Red -> Green -> Refactor TDD cycle, augmented with Byrd-specific AI-safety gates (mocks-first validation, full-suite regression gates, and requirement traceability).
When to Use
- Implementing any new functional or technical requirement in this repo.
- Fixing a bug, changing behavior, or adding to a public surface (types, methods, controllers, services).
- Writing or updating any implementation plan. Per the global rule, no plan is exempt regardless of size, urgency, or scope.
When Not to Use
- Pure documentation edits, requirements wording, or session-log housekeeping that touch no code and no test.
- Mechanical, behavior-preserving renames or formatting where existing tests already fully cover the surface.
- Read-only investigation, diagnosis, or research where you produce no source change.
Inputs
- The Functional Requirement(s) being satisfied:
FR-MCP-*fromdocs/Project/Functional-Requirements.md. - The Technical Requirement(s):
TR-MCP-*fromdocs/Project/Technical-Requirements.md. - The Testing Requirement(s):
TEST-MCP-*fromdocs/Project/Testing-Requirements.md. - The active iteration / slice scope (which tests must be green to exit) from MCP TODO state.
- The target test project (for example
tests/McpServer.Support.Mcp.Tests) and the production project under change.
Critical Rules
- Requirements drive tests. Tests are derived from functional and technical requirements and their acceptance criteria, never from implementation details. If a requirement is missing, capture it first (see Requirements step) before writing the test.
- Tests come first (Red). Write acceptance unit tests covering the full acceptance criteria BEFORE writing implementation code. The test must fail for the right reason before you implement.
- Validate with mocks (Byrd augmentation). Make the new tests pass against mocks/stubs first, proving the test and the contract are correct, before wiring real logic.
- Then implement (Green). Only after the mock-backed tests are correct do you write the real production code that makes them pass without mocks. Refactor tests and production code as part of the cycle to keep the design clean.
- All tests green to exit a phase. The entire unit-test suite for the current increment AND all prior work must pass before leaving an Implementation slice. Per
AGENTS.md(Byrd Test Gate), skipped tests are not passing tests: the gate requires zero failures and zero skips in the executed scope. Deferred work belongs in MCP TODO/requirements state, never in a skipped-test placeholder. - Integration tests come after units. Implement integration tests only after all unit tests pass across the codebase. The Nuke
Testtarget excludes*.IntegrationTests; run those separately. - Traceability is mandatory. Every new public type and member needs XML doc comments (
TreatWarningsAsErrors+ CS1591 fail the build), and every newFR/TR/TESTid must be referenced in source/test doc-comments and validated by./build.ps1 ValidateTraceability. - Do not ship code you have not verified compiles and passes. Correctness over speed.
- Use
pwsh.exe(PowerShell 7+) for all scripts. No em-dashes in any output, code comment, or commit message. - Defective requirements are expected. If writing the test surfaces a paradox, ambiguity, or wrong rule, refine the requirement (and its FR/TR/TEST docs) rather than weakening the test.
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 First seen · 86 lines · 105 tokens per session scan A 34b61700a3df
byrd-tdd-process is a skill published in the GitHub repository sharpninja/McpServer (2 stars, last pushed 12d ago), licensed Apache-2.0. It adds 105 tokens to every session and 2,015 once invoked, about $0.0005 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-08-31.
Other skills, from other repositories
implement
TDD implementation (RED→GREEN→REFACTOR) → verify → review.
implement
Write the production code that makes a pre-decided set of failing tests pass, within an explicit writeset, following an explicit behavior contract. Used by /tdd Step 3 and by /swarm-dispatch workers. The caller has already decided architecture, naming, file layout, and abstraction boundaries — this skill executes that…
scenario
Write executable failing tests from a recipe handed to you by the main context. Used by /tdd Step 2 and ad-hoc when a phase needs tests-first to drive implementation. Decisions about which scenarios to cover, which categories matter, and which fixtures to use are made by the caller — this skill executes that recipe…
test-first
Use when implementing any feature, bugfix, or refactor that has a testable outcome. Activate for keywords like "TDD", "test-first", "red-green", "write the test first", "implement ", "fix ". Enforces the red-green-refactor discipline -- write a failing test, make it pass with the smallest change, refactor with tests…
tdd-with-memory
과거 결정·컨벤션을 회상해 테스트 우선으로 구현하고 새 컨벤션을 기억에 남길 때 사용한다.
testkit
Retrofit an automated test suite onto a working codebase that has none: rank the untested surface, crown a slice, stand up a runner, and write tests that were each watched to fail before they were kept. Use when the user says "this project has no tests", "add test coverage", or "what should I test first". It never…