Skip to main content

tdd

Test-driven development: write tests first, implement until they pass. Use when implementing features with complex logic that benefits from test-first approach. Triggers: "TDDใง", "ใƒ†ใ‚นใƒˆ้ง†ๅ‹•", "ใƒ†ใ‚นใƒˆใƒ•ใ‚กใƒผใ‚นใƒˆใงๅฎŸ่ฃ…", "tdd", "ใƒใ‚ฐใ‚’้˜ฒใŽใŸใ„", "ใƒ†ใ‚นใƒˆใ‹ใ‚‰ๆ›ธใ„ใฆ".

Source facts

Repository
t2hnd/skills
Last source activity
February 7, 2026 at 11:36
Detected SKILL.md language
English
Stars
0
Forks
0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions ยท Read-only preview
name
tdd
description
Test-driven development: write tests first, implement until they pass. Use when implementing features with complex logic that benefits from test-first approach. Triggers: "TDDใง", "ใƒ†ใ‚นใƒˆ้ง†ๅ‹•", "ใƒ†ใ‚นใƒˆใƒ•ใ‚กใƒผใ‚นใƒˆใงๅฎŸ่ฃ…", "tdd", "ใƒใ‚ฐใ‚’้˜ฒใŽใŸใ„", "ใƒ†ใ‚นใƒˆใ‹ใ‚‰ๆ›ธใ„ใฆ".
# TDD Skill Autonomous test-driven development. Write comprehensive tests FIRST, then implement until all tests pass. Prevents "Buggy First-Pass Implementations". ## Workflow: Red โ†’ Green โ†’ Refactor ### Phase 1: Understanding (READ) 1. **Read existing codebase** to understand: - Current architecture and patterns - Existing types and interfaces - Testing patterns already in use 2. **Identify edge cases** that commonly cause bugs: - Empty data / null values - Boundary conditions (0, negative, max values) - Sorting bias (alphabetical, temporal) - Normalization edge cases (division by zero, all same values) - Missing configuration (.env variables) - Type mismatches (string vs number, undefined fields) ### Phase 2: Test Design (RED) **BEFORE writing ANY implementation code:** 3. **Write comprehensive tests** covering: - Happy path (expected usage) - Edge cases (empty, null, boundary) - Error conditions (invalid input, missing config) - Integration points (API calls, data flow) 4. **Run tests** โ€” they should ALL FAIL: ```bash npx vitest run <test-file> # or pytest <test-file> -v ``` 5. **Verify tests fail for the right reasons:** - โœ“ Function not implemented yet โ†’ correct - โœ— Test itself is broken โ†’ fix the test ### Phase 3: Implementation (GREEN) 6. **Implement the feature** โ€” minimal code to make tests pass 7. **Run tests iteratively** after each change until ALL pass 8. **Verify no regressions** โ€” run full test suite: ```bash npx vitest run ``` ### Phase 4: Verify 9. **Build verification:** ```bash npm run build npm run typecheck ``` ### Phase 5: Report 10. **Provide summary:** ``` โœ“ RED: Wrote 8 tests (edge cases, normalization, sorting bias) โœ“ GREEN: All 8 tests passing โœ“ Build passed, no regressions Files: src/utils/score.ts (+45), test/score.test.ts (+85, new) ``` ## Common Edge Cases to Always Test **Scoring/Ranking:** empty dataset, all same values, single item, division by zero **Field References:** wrong field name, undefined/null, type mismatches **Sorting:** alphabetical bias, temporal bias, tie-breaking **Configuration:** missing .env, dotenv not loaded, API keys unset ## Important Rules - **NEVER write implementation before tests** โ€” core TDD principle - **NEVER skip edge case tests** โ€” these catch the most common bugs - **NEVER ask clarifying questions** โ€” make assumptions and document them - **DO iterate until 100% pass** โ€” partial success is not done - **DO run full test suite** โ€” catch regressions
View on GitHub