메뉴
Require fresh verification evidence before claiming work is done, fixed, or passing. Use before reporting completion, expressing success, committing, or opening a PR — run the command, read the output, then make the claim.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Optimize React/Next.js runtime performance — eliminate waterfalls, shrink bundles, cut unnecessary re-renders, and speed up rendering. Use when writing, reviewing, or refactoring components for speed, or chasing slow renders, large bundles, janky interactions, or high TTFB/LCP/INP.
Build agent-friendly web apps with the W3C Web Model Context API (WebMCP). Use when exposing frontend features as structured tools for in-browser AI agents, adding document.modelContext tools to React/Next.js apps, designing tool schemas for dashboards or admin UIs, or making existing UI automatable without DOM scraping.
Write clear, fast, deterministic Go tests including mandatory repo integration tests (x/testkit) and app unit tests. Use when adding or fixing Go tests, implementing internal/repo or internal/app, designing table-driven tests, writing benchmarks, using testify, or improving coverage in this workspace.
Design distinctive, production-grade frontend interfaces that don't read as templated AI defaults. Use when bootstrapping a frontend app, building or restyling a landing page, marketing site, hero, brand-forward product surface, or any UI where visual identity matters — choosing palette, typography, layout, motion, and copy. Required before running create-next-app or writing UI.
Review code (your own or others') for correctness, design, and risk before it merges. Use when reviewing a diff or pull request, doing a self-review before opening a PR, or giving structured, prioritized feedback.
Architect a scalable, themeable design-token system — primitive → semantic → component layers, CSS variables, a 4px spacing/type scale, and dark mode. Use when setting up or refactoring a project's tokens, naming color/spacing/radius values, wiring tokens into Tailwind/shadcn, enabling theme switching, or killing hard-coded hex/px scattered through components.
| name | verification-before-completion |
| description | Require fresh verification evidence before claiming work is done, fixed, or passing. Use before reporting completion, expressing success, committing, or opening a PR — run the command, read the output, then make the claim. |
Claiming work is complete without verifying it is guesswork, not efficiency. Evidence before claims, always.
No completion claim without fresh verification evidence.
If you have not run the verifying command for the change in front of you, you cannot say it passes, builds, or is fixed.
| Claim | Sufficient evidence | Not enough |
|---|---|---|
| Tests pass | Test output: 0 failures | "should pass", a previous run |
| Linter clean | Linter output: 0 errors | a partial check |
| Build succeeds | Build exits 0 | linter passing, "logs look fine" |
| Bug fixed | The original symptom no longer reproduces | code changed, assumed fixed |
| Regression test works | Red→green verified (fails without the fix) | test passes once |
| Requirements met | Line-by-line check against the spec | "tests pass, so we're done" |
| Delegated work done | Diff/output inspected directly | the agent reported success |
A regression test that only passes proves nothing. Confirm it fails without the fix:
write test → run (fails) → apply fix → run (passes)
Run the command. Read the output. Then make the claim. No shortcuts.
Adapted from the verification-before-completion skill in
obra/superpowers (MIT).