菜单
Test-Driven Development with strict Red-Green-Refactor cycle. Use when developing with TDD, writing tests before code, adding test coverage, or when user mentions test-first, red-green-refactor, or wants reliable test suites.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Test API endpoints with proper authorization including Basic Auth and session cookies. Use when testing curl requests, checking API responses, getting 401 Unauthorized, session expired errors, or verifying endpoint behavior after changes.
Implement accumulated improvements from improvements-backlog into AI rules and skills. Use when backlog has 5+ items, weekly rule update cycle, 2+ high priority improvements exist, before important releases, when same error repeated 3+ times, when user says implement improvements/process backlog/update rules from errors.
Fix bugs, errors, exceptions, and unexpected behavior. Use when debugging, fixing errors, handling crashes, or when user mentions bug, error, broken, not working, crash, exception, 500 error, Application error, white screen, TypeError, undefined is not a function, or unexpected behavior.
Analyze Claude Code prompt cache efficiency and costs. Use when user asks about cache performance, token usage, session costs, how much a session cost, wants to optimize prompt caching, when costs seem high, when context window is filling up, or mentions cache-analyzer/cache hits/token costs/session metrics/cost analysis.
Review code for quality, security, and maintainability. Use when reviewing pull requests, examining code changes, doing QA checks, architecture review, or CTO review. Also trigger for COMPLEX tasks affecting more than 5 files, API contract changes, or data migrations.
Create new skills, modify and improve existing skills, create or update AI rules. Use when creating rules, building skills, adding coding standards, updating .claude/rules/ or .claude/skills/, converting Cursor rules to Claude Code, measuring skill performance, running evals, or optimizing skill descriptions.
| name | tdd-workflow |
| description | Test-Driven Development with strict Red-Green-Refactor cycle. Use when developing with TDD, writing tests before code, adding test coverage, or when user mentions test-first, red-green-refactor, or wants reliable test suites. |
| allowed-tools | Read, Write, Bash, Grep, Glob |
| model | sonnet |
| user-invocable | true |
Principle: Red -> Green -> Refactor (strict order)
Writing tests first catches design issues early — if the API is awkward to test, it's awkward to use. Tests also serve as living documentation that stays current because it breaks when behavior changes.
Fill the test cases table first because it forces you to think about behavior before implementation. Without this step, tests end up only covering the happy path.
| # | Scenario | Input | Expected Output | Type |
|---|----------|-------|-----------------|------|
| 1 | Happy path | ... | ... | Unit |
| 2 | Edge: empty | [] | ... | Unit |
| 3 | Edge: null | null | Error | Unit |
| 4 | Integration | ... | ... | Integration |
Coverage categories:
Do NOT proceed until the table is filled — skipping this step leads to incomplete test coverage that gives false confidence.
feature.test.ts)npm test -- --grep "feature"
# Expected: FAIL
Tests must fail first because a test that passes without implementation might be testing the wrong thing.
npm test -- --grep "feature"
# Expected: PASS
Refactoring with a green test suite is safe. Refactoring without tests is gambling.
| Category | Written | Passing | Skipped |
|----------|---------|---------|---------|
| Happy path | X | X | 0 |
| Edge cases | X | X | 0 |
| Error cases | X | X | 0 |
| Integration | X | X | 0 |