菜单
Use when about to claim work is complete, fixed, passing, or done — before committing, creating PRs, or moving to the next task. Also use when you're about to say 'Done!', 'All tests pass', 'Ready for review', 'Fixed', or ANY positive statement about work state. If you haven't run the verification command in this message, you cannot claim it passes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Turn the TDD enforcement hooks on or off, or check which they currently are. Use when the user says anything like 'turn off the tests', 'disable the TDD hooks', 'stop checking my tests', 'I don't want this enforced right now', 'turn testing back on', 're-enable the TDD stuff', or asks whether the hooks are currently on or off. Also covers /toggle-tdd.
Battle-tested Playwright E2E testing patterns for Next.js/React apps. Use when writing, running, debugging, or fixing Playwright tests. Also triggers on 'e2e', 'end-to-end', 'playwright', 'browser test', 'UI test', 'integration test with browser', 'flaky test', 'test keeps failing'. Covers locators, assertions, fixtures, auth, network mocking, flaky test diagnosis, Next.js-specific patterns, and debugging workflows.
Master orchestrator skill that kicks off the full development pipeline. Routes tasks through the correct skill chain (brainstorm, debug, tdd, e2e, verify) based on task type. Guarantees testing.md exists, Playwright E2E tests are written, and nothing is claimed done without verification. Use when starting any new task, feature, bugfix, or refactor.
Enforces strict test-driven development. Use when implementing ANY feature, bugfix, or refactor — before writing implementation code. Also use when someone says 'add tests', 'write tests', 'test this', 'TDD', or when you're about to write production code of any kind. If you're about to write code and there isn't a failing test for it yet, STOP and use this skill.
Use when you need to autonomously iterate through test-fix cycles without human intervention. Use when someone says 'make it work', 'run tests and fix', 'iterate until green', 'take yourself out of the loop', 'fix until tests pass', or when the agent is going in circles on the same problem. Also use when setting up a new integration, adding a new agent, or doing any work where automated tests can drive the development instead of manual prompting.
Use when a major project step has been completed and needs review against the plan and coding standards. Also use when someone says 'review this', 'check my code', 'is this ready', or when a significant chunk of implementation is done. Use after completing tasks from an implementation plan, before creating PRs, or when asked to assess code quality.
| name | verify-done |
| description | Use when about to claim work is complete, fixed, passing, or done — before committing, creating PRs, or moving to the next task. Also use when you're about to say 'Done!', 'All tests pass', 'Ready for review', 'Fixed', or ANY positive statement about work state. If you haven't run the verification command in this message, you cannot claim it passes. |
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
If you haven't run the verification command in this message, you cannot claim it passes.
BEFORE claiming any status or expressing satisfaction:
1. IDENTIFY: What command proves this claim?
2. RUN: Execute the FULL command (fresh, complete)
3. READ: Full output, check exit code, count failures
4. VERIFY: Does output confirm the claim?
- If NO: State actual status with evidence
- If YES: State claim WITH evidence
5. ONLY THEN: Make the claim
Skip any step = lying, not verifying
| Claim | Requires | Not Sufficient |
|---|---|---|
| "Tests pass" | Test command output: 0 failures AND 0 unexplained skips | Previous run, "should pass", "0 failures" with skips unmentioned |
| "Linter clean" | Linter output: 0 errors | Partial check, extrapolation |
| "Build succeeds" | Build command: exit 0 | Linter passing, "looks good" |
| "Bug fixed" | Test original symptom: passes | Code changed, assumed fixed |
| "Regression test works" | Red-green cycle verified | Test passes once |
| "Requirements met" | Line-by-line checklist | Tests passing |
| "E2E coverage" | npx playwright test output: 0 failures, 0 skipped | "Playwright not installed", unit tests only |
7 passed, 18 skipped is a failing suite wearing green. (Real audit result: 18 of 25 E2E tests in one project were skip-guarded on auth and had NEVER executed — the suite reported green for months.)
Before claiming tests pass:
grep -rnE "test\.skip\(|describe\.skip|\.skip\(true|xit\(|it\.skip" tests/ src/
test.skip(true, "Not authenticated")) means the test may have never run — prove it has actually executed (its name appears as passed in output) or treat it as red..or(signInHeading)) is a skip in disguise — a test that cannot fail verifies nothing.If this verification was triggered by the /start pipeline, you MUST verify that Playwright E2E tests exist and pass:
npx playwright test
If this command fails because Playwright is not installed or no E2E tests exist, verification FAILS. Go back to Step 5 of /start and do the work. Do not rationalize skipping E2E.
Before claiming completion, assess whether tests are proportional to the code you shipped.
For each piece of production code, identify its test:
| Production code you wrote | Required test (AT MINIMUM) |
|---|---|
| API route handler (GET/POST/PUT/DELETE) | Integration test or E2E that calls the route, checks status + body |
| UI component with interactions (>50 lines) | E2E that clicks/types/drags and verifies outcomes |
| Bug fix (any) | Regression test that reproduces the original symptom |
| Navigation change (sidebar, mobile nav, routes) | E2E that clicks nav item and verifies destination |
| Extracted helper/utility | Unit test — BUT the feature using it also needs its own test |
| State management / data flow change | Test through the UI or API that triggers the flow |
Proportionality failures (verification MUST fail if any apply):
The check: Look at git diff --stat for the work being verified. For every production file changed, point to the test that covers it. If you can't → verification FAILS.
When proportionality fails, route back explicitly:
| What's missing | Go to | Then |
|---|---|---|
| Integration test for API route | /start Step 4 — write it with /tdd (red→green) | Re-run /verification from the top |
| E2E test for UI/nav/workflow | /start Step 5 — write it with /e2e-playwright | Re-run /verification from the top |
| Regression test for bug fix | /start Step 4 — write it with /tdd (red→green) | Re-run /verification from the top |
After ANY loop-back: Re-run the FULL gate function (identify → run → read → verify). Do not skip re-verification. Do not assume the new test fixed everything — run ALL tests and re-check ALL proportionality. Partial re-checks prove nothing.
Tests:
✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"
Regression tests (TDD Red-Green):
✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
❌ "I've written a regression test" (without red-green verification)
Build:
✅ [Run build] [See: exit 0] "Build passes"
❌ "Linter passed" (linter doesn't check compilation)
Requirements:
✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
❌ "Tests pass, phase complete"
| Excuse | Reality |
|---|---|
| "Should work now" | RUN the verification |
| "I'm confident" | Confidence ≠ evidence |
| "Just this once" | No exceptions |
| "Linter passed" | Linter ≠ tests ≠ build |
| "Agent said success" | Verify independently |
| "Partial check is enough" | Partial proves nothing |
Run the command. Read the output. THEN claim the result.
This is non-negotiable.