菜单
Use when completing any task, fixing bugs, implementing features, or whenever about to claim work is done. Also use when the agent says "fixed", "done", "implemented", "all set", or "should work now" without showing evidence. Auto-triggers before any completion claim.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | prove-it |
| description | Use when completing any task, fixing bugs, implementing features, or whenever about to claim work is done. Also use when the agent says "fixed", "done", "implemented", "all set", or "should work now" without showing evidence. Auto-triggers before any completion claim. |
The #1 agent failure: claiming "done" without proof. This skill forces evidence-before-assertion on every completion claim.
Never say "done" without proof. Never say "fixed" without running it. Never say "implemented" without showing it works.
ACTIVE on EVERY completion claim. Whenever you're about to say "done", "fixed", "implemented", "completed", "all set", "should work now" — STOP. Prove it first.
Before ANY statement claiming work is complete:
1. WHAT CLAIM am I about to make? (state it explicitly)
2. WHAT EVIDENCE proves this claim? (name the specific command/test/verification)
3. RUN the evidence NOW (not "I could run..." — actually run it)
4. READ the output (full output, not just exit code)
5. DOES the output CONFIRM the claim?
YES → show the evidence, THEN make the claim
NO → fix the issue, then re-run from step 3
BAD: "Fixed the authentication bug." ← Where's the proof?
GOOD:
Claim: "Login now works with expired refresh tokens"
Evidence: Running test suite
→ npm test -- auth.test.ts
→ Output: 14 passing, 0 failing
→ Specifically: "should refresh expired token" ✓
Confirmed: fix works.
BAD: "Implemented the search feature." ← Did you try it?
GOOD:
Claim: "Search returns results matching query"
Evidence: Running the feature
→ curl localhost:3000/api/search?q=test
→ Output: {"results": [{"title": "Test Item", ...}], "total": 3}
Confirmed: feature works.
| Claim Type | Minimum Evidence |
|---|---|
| Bug fix | Test that WAS failing now passes |
| New feature | Demo showing it works (command + output) |
| Refactor | All existing tests still pass |
| Performance fix | Before/after metrics |
| Config change | Proof the config is loaded correctly |
| "Everything works" | Full test suite output, exit code 0 |
The #1 agent failure pattern (2026): "says done but isn't." Users report spending MORE time verifying false completions than if they'd done it themselves. This single discipline — prove before claiming — eliminates the entire category of wasted cycles.
"Claiming work is complete without verification is dishonesty, not efficiency."
All of these mean: you're about to claim without evidence. Run the verification FIRST.
| Excuse | Reality |
|---|---|
| "It's a one-line change" | One-line changes break production. Run the test. |
| "I already verified mentally" | Mental verification = no verification. Execute it. |
| "The test suite takes too long" | Run the RELEVANT test, not all of them. No excuse. |
| "It's just a config change" | Config errors are the hardest to debug. Prove it loaded. |
| "I'll run tests after I finish everything" | By then you won't know which change broke what. Prove EACH. |
| "The user can verify" | YOU verify. Don't outsource your responsibility. |
Use after generating code, after accepting AI suggestions, or when reviewing AI-written modules. Also use when code "works" but feels brittle, when error handling seems thin, when you notice orphaned resources or missing cleanup, or when the agent says "done" but you suspect hidden debt. Catches the specific failure patterns AI agents produce that humans wouldn't.
Generate architecture diagrams, dependency maps, and system documentation directly from your codebase. Reads source files, traces dependencies, identifies boundaries, and outputs Mermaid/PlantUML/C4 diagrams. Use when asked to document architecture, visualize dependencies, generate system diagrams, create C4 models, map service boundaries, understand a codebase structure, or produce technical documentation from existing code.
Generate a CONTEXT.md shared vocabulary for any project. Reduces agent verbosity by 50-75%, improves variable naming, makes conversations more precise. Interviews the user about domain terms, then produces a structured glossary the agent references every session. Use when starting a new project, onboarding to unfamiliar code, the agent is being too verbose, or conversations have too much jargon confusion. Also use when user says "build context", "shared language", "define terms", or "the agent doesn't understand my project vocabulary".
Enforce schema discipline: queries-first design, index-every-filter, safe migrations, verify-at-scale thinking. Prevents the common failure of designing schemas for demos that break in production. Use when creating tables, planning migrations, designing data models, or when user mentions database, schema, migration, indexing, multi-tenant.
Use when making UI/frontend changes in Cursor's Design Mode, when the user selects elements visually, draws annotations, or uses voice commands to describe changes. Also use when editing components from the integrated browser, when multi-selecting elements to match styles, when making iterative visual refinements, or when the agent receives visual context (screenshots, element selections, DOM references) alongside a change request.
Build resilient systems with proper error handling, retry patterns, circuit breakers, graceful degradation, and timeout management. Use when implementing API calls, database connections, external service integrations, background jobs, or any code that can fail. Also use when the user mentions retry logic, circuit breaker, graceful degradation, error boundary, timeout handling, dead letter queue, or asks how to make code more resilient.