一键导入
tdd
Use when implementing any feature or bugfix where correctness matters - before writing implementation code.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when implementing any feature or bugfix where correctness matters - before writing implementation code.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when you need a comprehensive code audit covering security, performance, architecture, and dependencies before a release, major refactor, or compliance review.
Use when you want to iteratively build a feature using a PRD as source of truth, with progress tracking and fresh-context iterations - the Autopilot technique for autonomous development.
Use when starting a complex feature, exploring unclear requirements, or needing to challenge assumptions before committing to a design - before /plan.
Use when you need a comprehensive code review combining architecture, security, and test perspectives - especially before merging, releasing, or after major changes.
Use when creating marketing copy for landing pages, email campaigns, product descriptions, or social media - with A/B variants and conversion-focused frameworks.
Use when optimizing landing pages, signup flows, checkout processes, or any user-facing page for higher conversion rates - before A/B testing.
| name | tdd |
| description | Use when implementing any feature or bugfix where correctness matters - before writing implementation code. |
| user-invocable | true |
| argument-hint | [feature or function to implement] |
| allowed-tools | Read, Write, Edit, Bash, Glob, Grep |
Implement the feature using strict TDD methodology.
Target: $ARGUMENTS
╔══════════════════════════════════════════════════════════════╗
║ NO IMPLEMENTATION CODE WITHOUT A FAILING TEST FIRST ║
╚══════════════════════════════════════════════════════════════╝
For each behavior to implement:
┌───────┐ ┌───────┐ ┌──────────┐
│ RED │ ───► │ GREEN │ ───► │ REFACTOR │
└───────┘ └───────┘ └──────────┘
Auto-detect the project's test runner before starting:
# Detect test runner from package.json or config files
if [ -f "vitest.config.ts" ] || [ -f "vitest.config.js" ] || grep -q '"vitest"' package.json 2>/dev/null; then
TEST_CMD="npx vitest run"
TEST_FILTER="--testNamePattern"
elif [ -f "jest.config.ts" ] || [ -f "jest.config.js" ] || grep -q '"jest"' package.json 2>/dev/null; then
TEST_CMD="npx jest"
TEST_FILTER="--testNamePattern"
elif [ -f "playwright.config.ts" ] || [ -f "playwright.config.js" ]; then
TEST_CMD="npx playwright test"
TEST_FILTER="--grep"
elif grep -q '"mocha"' package.json 2>/dev/null; then
TEST_CMD="npx mocha"
TEST_FILTER="--grep"
else
TEST_CMD="npm test --"
TEST_FILTER="--testNamePattern"
fi
echo "Test runner: $TEST_CMD"
Use the detected $TEST_CMD and $TEST_FILTER throughout all cycles.
it('should [expected behavior] when [condition]', () => {
// Arrange
const input = ...;
// Act
const result = functionUnderTest(input);
// Assert
expect(result).toBe(expected);
});
$TEST_CMD $TEST_FILTER="[test name]"
Write minimum code to pass:
Run test:
$TEST_CMD $TEST_FILTER="[test name]"
Verify PASSES - Capture output showing success
BLOCKED if test fails (fix before continuing)
Improve code quality:
Run ALL tests:
$TEST_CMD
Verify ALL PASS
Check coverage change (if coverage tool is available):
$TEST_CMD --coverage 2>/dev/null | grep -A 5 "Stmts\|Lines\|%" || true
Commit cycle:
git add -A && git commit -m "feat: [behavior] (TDD cycle N)"
Continue cycles until feature is complete.
Every test run must be captured:
──── RED Phase ────
Test: should calculate discount for valid coupon
Running: npm test -- --testNamePattern="calculate discount"
Output:
FAIL src/discount.test.ts
✕ should calculate discount for valid coupon
Expected: 90
Received: undefined
Status: FAIL ✓ - Proceeding to GREEN
──── GREEN Phase ────
Running: npm test -- --testNamePattern="calculate discount"
Output:
PASS src/discount.test.ts
✓ should calculate discount for valid coupon
Status: PASS ✓ - Proceeding to REFACTOR
──── /tdd ────
Feature: [name]
Cycle #1: [behavior]
RED: Test written, FAIL ✓
GREEN: Implemented, PASS ✓
REFACTOR: Cleaned, PASS ✓
Cycle #2: [behavior]
RED: Test written, FAIL ✓
GREEN: Implemented, PASS ✓
REFACTOR: Cleaned, PASS ✓
──── TDD Summary ────
Cycles completed: 2
Tests added: 2
All tests passing: ✓
Coverage: [if available]
| Excuse | Reality |
|---|---|
| "I know it works, no need to test first" | Write the test. If it works, RED phase takes 30 seconds. |
| "This is too simple for TDD" | Simple code has simple tests. No excuse to skip. |
| "I'll write tests after" | Tests written after implementation verify your bias, not correctness. |
| "The test framework isn't set up" | Set it up. That's part of the task. |
| "Just this once I'll skip RED" | "Just this once" is how every shortcut becomes a habit. |
| "The existing tests are enough" | Enough for what? New behavior needs new tests. Existing tests verify old assumptions. |
| "I'll test the integration, not the unit" | Integration tests verify wiring. Unit tests verify logic. You need both. Start with unit. |