tdd
Implement features using Test-Driven Development (TDD) with Red-Green-Refactor cycle.
pinned to #d5a3918updated 2 weeks ago
Ask your AI client: “install skills/tdd”.
Requires the metahub MCP server installed in your client. Set up MCP.
mh install skills/tddmetahub onboarded this repo on the author's behalf.
If you own github.com/DeL-TaiseiOzaki/claude-code-orchestra on GitHub, claim the listing to take over publishing. Your claim preserves the existing eval history and badges; only the curator label is replaced with verified-publisher on your next publish.
Stars
184
Last commit
2 weeks ago
Latest release
published
About this skill
Pulled from SKILL.md at publish time.
Implement $ARGUMENTS using Test-Driven Development (TDD).
Evaluation report
WarningsAutomated checks the publisher passed at publish time — structure, docs, safety, and whether the artifact behaves as claimed.d5a3918· 2 weeks ago
Documentation
32Description qualitywarn
9 words · 85 chars — skills use the description as their trigger; aim higher
Aim for 15+ words and include trigger phrases like “use this skill when …”.
README is present and substantial
18,894 chars · 9 sections · 21 code blocks
Tags / topics declaredwarn
No manifest tags and no GitHub repo topics
Add tags to the manifest (or GitHub topics on the repo) so the registry's search and category filters surface this artifact.
README has usage / example sections
found: Quick Start
Homepage / docs URL declared
no homepage declared (registry will use the repo URL) — info-only, not blocking
Release history
1- releasecurrentd5a3918warn2 weeks ago
Contents
Test-Driven Development
Implement $ARGUMENTS using Test-Driven Development (TDD).
TDD Cycle
Repeat: Red → Green → Refactor
1. Red: Write a failing test
2. Green: Write minimal code to pass the test
3. Refactor: Clean up code (tests still pass)
Implementation Steps
Phase 1: Test Design
-
Confirm Requirements
- What is the input
- What is the output
- What are the edge cases
-
List Test Cases
- [ ] Happy path: Basic functionality - [ ] Happy path: Boundary values - [ ] Error case: Invalid input - [ ] Error case: Error handling
Phase 2: Red-Green-Refactor
Step 1: Write First Test (Red)
# tests/test_{module}.py
def test_{function}_basic():
"""Test the most basic case"""
result = function(input)
assert result == expected
Run test and confirm failure:
uv run pytest tests/test_{module}.py -v
Step 2: Implementation (Green)
Write minimal code to pass the test:
- Don't aim for perfection
- Hardcoding is OK
- Just make the test pass
Run test and confirm success:
uv run pytest tests/test_{module}.py -v
Step 3: Refactoring (Refactor)
Improve while tests still pass:
- Remove duplication
- Improve naming
- Clean up structure
uv run pytest tests/test_{module}.py -v # Confirm still passes
Step 4: Next Test
Return to Step 1 with next test case from the list.
Phase 3: Completion Check
Run the quality gates:
bash .claude/skills/_shared/verify.sh
Read the JSON: overall is pass / fail / no_gates. On fail, inspect the log_file. On no_gates (project has no configured gates), fall back to the project's own verification commands and confirm manually.
Then check coverage separately:
uv run pytest --cov={module} --cov-report=term-missing
Report Format
## TDD Complete: {Feature Name}
### Test Cases
- [x] {test1}: {description}
- [x] {test2}: {description}
...
### Coverage
{Coverage report}
### Implementation Files
- `src/{module}.py`: {description}
- `tests/test_{module}.py`: {N} tests
Notes
- Write tests first (not after)
- Keep each cycle small
- Refactor after tests pass
- Prioritize working code over perfection
Reviews
No reviews yet. Be the first.
Related
Verification Before Completion
Evidence before assertions, always
Writing Plans
Turn specs into phased implementation plans
Test-Driven Development
Red → green → refactor discipline for any feature or bugfix
mh install skills/tdd