raisedadead/tdd
plugins/dp-cto/skills/tdd/SKILL.md
Use when you want to write tests first, enforce test-driven development, or add test coverage — 'write tests for this', 'TDD this feature', 'add test coverage'. Strict RED-GREEN-REFACTOR discipline.
$ install --global
skillsauthnpx skillsauth add raisedadead/dotplugins tddInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 18, 2026, 5:13 AM74.4s7 files scanned
SKILL.md
- name:
- tdd
- description:
- Use when you want to write tests first, enforce test-driven development, or add test coverage — 'write tests for this', 'TDD this feature', 'add test coverage'. Strict RED-GREEN-REFACTOR discipline.
- user-invocable:
- true
dp-cto:tdd — TDD Enforcement
Read ${CLAUDE_PLUGIN_ROOT}/shared/cto-boundaries.md
The Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Wrote code before the test? Delete it. Not "set aside." Not "use as reference." Delete. Implement fresh from the failing test.
Protocol
1. Gather Test Target
Collect from the user:
- Feature or behavior to test
- Target file paths (resolve concrete paths — never placeholders)
- Verification command (test runner, specific test file)
- Whether this is a new feature or a bug fix (determines RED-GREEN-REFACTOR vs bug fix protocol)
If the user's description is vague, ask clarifying questions before dispatch. One question per message.
2. Dispatch Tester Agent
Dispatch tester via the Agent tool with subagent_type: "dp-cto:tester".
The agent prompt must include:
- The test target (feature description or bug to reproduce)
- Concrete file paths (source and test files)
- The verification command to run tests
- File scope constraints (what the agent may and may not modify)
The tester agent follows strict RED-GREEN-REFACTOR discipline: write one failing test, verify RED, write minimal code to pass, verify GREEN, refactor. The agent definition enforces this cycle.
3. Validate Receipt
On agent completion, extract the structured receipt from <!-- RECEIPT:START/END --> markers. Validate:
tests_written— list of tests createdtests_watched_fail— every test must have been watched failing (RED verified)tests_passing— all tests green after implementationverification— command, exit code, and output preview
If tests_watched_fail is empty or does not match tests_written, reject the receipt. A test never seen failing is a test you do not trust.
4. Report Results
Present the tester's results to the user: tests written, RED/GREEN verification evidence, and any unresolved issues from the receipt.
Read ${CLAUDE_SKILL_DIR}/references/test-examples.md before proceeding.
Read ${CLAUDE_SKILL_DIR}/references/implementation-examples.md before proceeding.
Read ${CLAUDE_SKILL_DIR}/references/anti-rationalization.md before proceeding.
Read ${CLAUDE_SKILL_DIR}/references/red-flags.md before proceeding.
Read ${CLAUDE_SKILL_DIR}/references/good-tests.md before proceeding.
Read ${CLAUDE_SKILL_DIR}/references/verification-checklist.md before proceeding.
NEVER
- NEVER write tests or production code inline — always dispatch the tester agent
- NEVER accept a receipt where tests_watched_fail is empty
- NEVER skip receipt validation — verify RED-GREEN-REFACTOR evidence
- NEVER auto-invoke follow-up skills — present results and let the user decide
- NEVER rationalize skipping TDD — check the anti-rationalization table
Related Skills
raisedadead/self-develop
development
VerifiedTrustedCommunity
Use when the user shares a URL, names a resource from SOURCES.md, shares operational feedback, says 'adopt', 'learn from', 'what can we steal from', 'compare with', 'self-develop', or 'how do we get better'.
4SKILL.mdUpdated Apr 18, 2026
raisedadead/setup
tools
VerifiedTrustedCommunity
Use when you need to set up or rebuild the dp-lsp Docker image after installing the plugin — 'set up LSP', 'build the image', 'install language servers'.
4SKILL.mdUpdated Apr 18, 2026
raisedadead/spec
testing
VerifiedTrustedCommunity
Use when starting major work that needs formal design review — cross-team changes, architectural decisions, or complex features where requirements need discovery before implementation.
4SKILL.mdUpdated Apr 18, 2026
raisedadead/setup-engine
tools
VerifiedTrustedCommunity
Use when dp-engine binary is missing or needs reinstallation -- called by plan skill on first use, not directly by user.
4SKILL.mdUpdated Apr 18, 2026