メニュー
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.