菜单
Test-Driven Development Iron Law. Write the test first. Watch it fail. Write minimal code to pass. No exceptions.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/xenitV1/claude-code-maestro --skill tdd-mastery命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
Use when you need to act as an Elite Software Architect (Maestro) to manage complex repositories. It enforces a "Why over How" philosophy, maintains a persistent project memory (Brain), and orchestrates specialized sub-skills through a Plan-Act-Verify lifecycle.
Elite Tier Backend standards, including Vertical Slice Architecture, Zero Trust Security, and High-Performance API protocols.
Design-first methodology. Explore user intent, requirements and design before implementation. Turn ideas into fully formed specs through collaborative dialogue.
基于 SOC 职业分类
| name | tdd-mastery |
| description | Test-Driven Development Iron Law. Write the test first. Watch it fail. Write minimal code to pass. No exceptions. |
<domain_overview>
Philosophy: If you didn't watch the test fail, you don't know if it tests the right thing. TDD is not optional—it's the foundation of trustworthy code. TEST-FIRST INTEGRITY MANDATE (CRITICAL): Never write production code before a test exists and has been seen failing. AI-generated code often attempts to write implementation and tests simultaneously or implementation first. You MUST strictly adhere to the Red-Green-Refactor cycle. Any code submitted without a preceding failing test or that generates tests after the implementation must be rejected as "Legacy Code on Arrival".
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Write code before the test? Delete it. Start over.
No exceptions:
Implement fresh from tests. Period. </domain_overview> <core_workflow>
Write one minimal test showing what should happen.
Good Example:
test('retries failed operations 3 times', async () => {
let attempts = 0;
const operation = () => {
attempts++;
(attempts < ) ();
;
};
result = (operation);
(result).();
(attempts).();
});
Clear name, tests real behavior, one thing
Bad Example:
test('retry works', async () => {
const mock = jest.fn()
.mockRejectedValueOnce(new Error())
.mockResolvedValueOnce('success');
await retryOperation(mock);
expect(mock).toHaveBeenCalledTimes(2);
});
Vague name, tests mock not code
Requirements:
MANDATORY. Never skip.
npm test path/to/test.test.ts
# or
pytest tests/path/test.py::test_name -v
Confirm:
Test passes? You're testing existing behavior. Fix test.
Test errors? Fix error, re-run until it fails correctly.
Write simplest code to pass the test.
Good:
async function retryOperation<T>(fn: () => Promise<T>): Promise<T> {
for (let i = 0; i < 3; i++) {
try {
return await fn();
} catch (e) {
if (i === 2) throw e;
}
}
throw new Error('unreachable');
}
Just enough to pass
Bad:
async function retryOperation<T>(
fn: () => Promise<T>,
options?: {
maxRetries?: number;
backoff?: 'linear' | 'exponential';
onRetry?: (attempt: number) => void;
}
): Promise<T> {
// YAGNI - You Aren't Gonna Need It
}
Over-engineered
Don't add features, refactor other code, or "improve" beyond the test.
MANDATORY.
npm test path/to/test.test.ts
Confirm:
Test fails? Fix code, not test.
Other tests fail? Fix now.
After green only:
Keep tests green. Don't add behavior.
git add tests/path/test.ts src/path/file.ts
git commit -m "feat: add specific feature with tests"
Repeat for next behavior.
</core_workflow>
<quality_standards>
| Quality | Good | Bad |
|---|---|---|
| Minimal | One thing. "and" in name? Split it. | test('validates email and domain and whitespace') |
| Clear | Name describes behavior | test('test1') |
| Shows intent | Demonstrates desired API | Obscures what code should do |
| Real behavior | Tests actual code | Tests mock behavior |
| Excuse | Reality |
|---|---|
| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
| "I'll test after" | Tests passing immediately prove nothing. |
| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is debt. |
| "Keep as reference" | You'll adapt it. That's testing after. Delete means delete. |
| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
| "Test hard = skip test" | Hard to test = hard to use. Simplify design. |
| "TDD will slow me down" | TDD faster than debugging. Pragmatic = test-first. |
| "Existing code has no tests" | You're improving it. Add tests for existing code. |
If you catch yourself:
ALL of these mean: Delete code. Start over with TDD.
</quality_standards>
<bug_fix_protocol>
Bug found? Write failing test reproducing it. Follow TDD cycle.
Example:
Bug: Empty email accepted
RED:
test('rejects empty email', async () => {
const result = await submitForm({ email: '' });
expect(result.error).toBe('Email required');
});
VERIFY RED:
$ npm test
FAIL: expected 'Email required', got undefined
GREEN:
function submitForm(data: FormData) {
if (!data.email?.trim()) {
return { error: 'Email required' };
}
// ...
}
VERIFY GREEN:
$ npm test
PASS
Never fix bugs without a test.
</bug_fix_protocol>
<integration_and_tooling>
When Ralph Wiggum is active:
Ralph Wiggum will REJECT:
Before marking work complete:
Can't check all boxes? You skipped TDD. Start over.
Auto-detect project type and setup appropriate tools:
| Project Type | Required Tools |
|---|---|
| Frontend (Vite/React) | vitest + playwright |
| Fullstack (Next.js) | vitest + playwright |
| Backend (Node) | vitest or jest |
| Python | pytest + pytest-cov |
| Microservices | MSW (Mock Service Worker) |
For every new function/component, generate:
Rule: Every frontend-backend interaction MUST have an MSW handler.
// Example MSW handler
import { http, HttpResponse } from 'msw'
export const handlers = [
http.get('/api/users/:id', ({ params }) => {
return HttpResponse.json({
id: params.id,
name: 'Test User'
})
})
]
Benefit: Decouples frontend development from backend availability.
AI must scan for "Untested Logic Slabs" (>20 lines without coverage) and flag them:
# Check coverage gaps
npm run test -- --coverage
# Look for files with <80% coverage
</integration_and_tooling>
<reference_and_audit>
Production code → test exists and failed first
Otherwise → not TDD
No exceptions without explicit user permission. </reference_and_audit>