菜单
When the user is implementing a new feature or fixing a bug. When the user wants to write tests first before writing code. When the user is refactoring and needs to verify behaviour is preserved.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | test-driven-development |
| description | When the user is implementing a new feature or fixing a bug. When the user wants to write tests first before writing code. When the user is refactoring and needs to verify behaviour is preserved. |
| tools | ["read","exec"] |
Without writing tests first, it is easy to write code that passes in the happy path but misses edge cases — and tests added after the fact often test the implementation rather than the requirement. This skill enforces the RED-GREEN-REFACTOR cycle so tests drive design rather than rubber-stamp it.
Write the test for desired behavior before writing any implementation — verifying it fails confirms the test actually exercises the right thing.
pytest tests/test_feature.py -v # must FAIL here
Commit: git commit -m "RED: test for feature-name"
Write the minimal code needed to pass the test — no more. Over-engineering at this stage hides design feedback.
pytest tests/test_feature.py -v # must PASS here
pytest # all other tests must still pass
Commit: git commit -m "GREEN: implement feature-name"
Improve code quality without changing behavior; the passing tests act as a safety net.
pytest # must still pass after refactor
Commit: git commit -m "REFACTOR: clean up feature-name"
❌ Writing code before writing the test ❌ Not verifying the test fails first (RED phase) ❌ Writing too much implementation code at once ❌ Skipping the REFACTOR phase
When the user wants to add a new feature or capability. When the user says "I want to build" or "I'm thinking about". When requirements are unclear and need to be refined.
When the user says they are ready for review or wants to create a PR. When the user asks to check if code is ready for review. When the task or feature is complete and needs quality validation.
When the user approves a plan and wants to execute it. When the user says "execute the plan" or "let's go" or "start implementation". When a PLAN.md exists and is ready to be executed task-by-task.
When the user wants to create an implementation plan. When the user says "let's implement this" or "create a plan". When a design has been approved and is ready to be broken into tasks.
Systematic code review workflow — evaluate changes for correctness, style, security, and test coverage before merging. When the user asks to review code or a pull request. When the user says "check code quality" or "look over this diff". When the user requests feedback on changes before merging.
Restart containers, prune images, tail logs.