菜单
Use when about to claim work is complete, fixed, or passing — before committing, opening a PR, or telling the user it works. Requires running verification commands and confirming output first; evidence before assertions, always.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Scan the codebase for architectural friction and propose deepening opportunities as candidate cards, then interrogate the chosen one into a decision. Two entry points — proactive, when the user asks "improve the architecture" or "why is this codebase painful to work in"; reactive, when the debug skill's "3+ failed fixes = architectural problem" rule hands off here. Inherently T2/T3; the outcome is a decision plus a plan.
Use when starting any new feature or product request, before writing a plan or code — turns an idea into a short approved spec by surfacing the decisions that will hurt later. Depth scales with risk tier.
Use when encountering any bug, test failure, unexpected behavior, or performance regression — before proposing any fix. Root-cause discipline plus a feedback-loop method; applies at every tier.
Use when designing or improving a module's interface, deciding where a seam goes, making code more testable or navigable, or pinning down domain terminology. Provides the deep-module vocabulary other skills lean on.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Use at the end of T3 work, after an incident/rollback, or when the user asks for a retro — turns what happened into recorded learnings that live in the repo (CHANGELOG entry, typed LEARNINGS.md entries, follow-up tasks, and — only with explicit user approval — new RULES).
| name | verify-done |
| description | Use when about to claim work is complete, fixed, or passing — before committing, opening a PR, or telling the user it works. Requires running verification commands and confirming output first; evidence before assertions, always. |
Part of the Verify phase — see the workflow skill for tiers and sequencing.
Claiming work is complete without verification is dishonesty, not efficiency.
The Iron Law: NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
If you haven't run the verification command in this message, you cannot claim it passes.
The user reviews outcomes, not code. Evidence — command output, test summaries, screenshots, preview URLs — is the only thing they can judge. An unverified "done" that turns out broken doesn't just cost rework; it breaks the trust the whole PM ↔ engineer division of labor depends on. One false "it works" costs more than ten honest "it's not working yet"s.
BEFORE claiming any status or expressing satisfaction:
1. IDENTIFY: what command proves this claim?
2. RUN: the FULL command (fresh, complete)
3. READ: full output, exit code, failure count
4. VERIFY: does the output confirm the claim?
- NO → state the actual status, with the evidence
- YES → state the claim WITH the evidence
5. ONLY THEN: make the claim
Skip any step = lying, not verifying.
| Claim | Requires | Not sufficient |
|---|---|---|
| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
| Typecheck clean | tsc --noEmit: exit 0 | Editor showed no squiggles |
| Linter clean | Linter output: 0 errors | Partial check |
| Build succeeds | Build command: exit 0 | Linter passing, logs look fine |
| Bug fixed | Original symptom re-tested: passes | Code changed, assumed fixed |
| Regression test works | Red-green verified (fails without fix, passes with) | Test passes once |
| Subagent completed | Diff inspected, changes verified | Agent reports "success" |
| Requirement match | Diff vs brief, line by line | Tests passing |
"It works" and "it's what was asked" are different claims. Verify both, on separate axes:
brief output (or the plan file from plan). Walk the diff against it line
by line and report: (a) requirements missing or partial, (b) behavior nobody
asked for (scope creep), (c) requirements that look implemented but wrong.Report the axes separately and never rerank across them: passing tests cannot excuse a missed requirement, and a faithful diff cannot excuse a convention break. A change can pass one axis and fail the other — merging the reports lets one axis mask the other. If there is no brief or plan, say "no spec available" in the report; don't invent one.
At T3, the two axes MAY run as parallel subagents (see delegate) so neither
pollutes the other's context; aggregate their findings without merging.
QA depth scales with the tier (see workflow). Evidence = the checks run and
their results, not "the page looked fine".
| Tier | Depth | Check |
|---|---|---|
| T1 | Minimal | Typecheck + lint + affected test; browser QA only if the change is user-visible (see browser-qa — it skips T1 by default) |
| T2 | Standard, ~10 min | Smoke + meta description and og/twitter tags; sane heading hierarchy; lang attribute and favicon; target="_blank" links have noopener; responsive at 375/768/1440px; primary user flow exercised end to end |
| T3 | Full, 30+ min | Standard + every form submits and validates; cross-browser (at least Chrome + Safari); internal and external links resolve; security headers (HSTS, X-Frame-Options, X-Content-Type-Options); HTTPS only, no mixed content; 404s return HTTP 404; analytics events fire; cache headers sane |
A failed check is fixed before "done" or reported as a known issue — never silently shipped. For the recurring production failure modes (caching, env vars, images, third-party integrations), check references/web-bug-patterns.md.
Every completion claim ships with evidence the user can judge directly:
"The code looks correct" is not evidence. Show the thing working.
| Excuse | Reality |
|---|---|
| "Should work now" | RUN the verification |
| "I'm confident" | Confidence ≠ evidence |
| "Just this once" | No exceptions |
| "Linter passed" | Linter ≠ compiler ≠ tests |
| "Agent said success" | Verify independently |
| "Partial check is enough" | Partial proves nothing |
| "Different words, so the rule doesn't apply" | Spirit over letter |
✅ [run test command] [see: 34/34 pass] → "All tests pass."
❌ "Should pass now" / "Looks correct"
Regression test (red-green):
✅ Write → run (pass) → revert fix → run (MUST FAIL) → restore → run (pass)
❌ "I've written a regression test" (never seen red)
Requirements:
✅ Re-read brief/plan → diff vs each line → report gaps or completion
❌ "Tests pass, phase complete"
Before ANY success/completion claim or expression of satisfaction; before committing, PR creation, or moving to the next task; before reporting a subagent's work as done. Applies to paraphrases and implications, not just the exact words.
Run the command. Read the output. THEN claim the result. Non-negotiable.
Adapted from superpowers (MIT, © 2025 Jesse Vincent), mattpocock-skills (MIT, © 2026 Matt Pocock), and rampstack-skills (MIT, © 2026 RampStack Co.); see ATTRIBUTION.md.