メニュー
WHEN to auto-invoke: Finishing tasks, claiming "done" or "complete", before marking work finished, when asserting code works, wrapping up implementations. WHEN NOT to invoke: During active development, exploration phases, planning discussions, research tasks.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | verification-first |
| description | WHEN to auto-invoke: Finishing tasks, claiming "done" or "complete", before marking work finished, when asserting code works, wrapping up implementations. WHEN NOT to invoke: During active development, exploration phases, planning discussions, research tasks. |
| priority | 90 |
Never claim completion without evidence. Verify before asserting.
"Trust, but verify" - Don't assume code works; prove it works.
Before making ANY claim about code working, you MUST complete all 5 steps:
Question: What command proves this claim?
npm test path/to/file.test.tsAction: Execute the FULL command fresh
Action: Read FULL output and check exit code
Question: Does output ACTUALLY confirm the claim?
Action: Make the claim with evidence
If you notice yourself doing ANY of these, STOP immediately:
Run the Code
Check the Output
Test Edge Cases
Verify in Context
Before marking complete:
- [ ] Code compiles/transpiles without errors
- [ ] Tests pass (existing + new)
- [ ] Manual verification performed
- [ ] Edge cases checked
- [ ] Error handling works
- [ ] Integration verified
# Type check
npx tsc --noEmit
# Run tests
npm test
# Build verification
npm run build
When claiming completion, provide evidence:
## Verification Evidence
**What was verified:**
- Feature X works correctly
**How it was verified:**
- Ran `npm test` - 45/45 tests passing
- Manually tested in browser at /feature-x
- Checked error handling with invalid input
**Results observed:**
- Success case: Shows expected output
- Error case: Displays user-friendly message
- Edge case: Handles empty state gracefully
| Level | Meaning | Evidence Required |
|---|---|---|
| Certain | Verified with tests + manual | Tests + screenshots/logs |
| High | Verified with tests | Passing test output |
| Medium | Manually verified | Description of manual test |
| Low | Code review only | Should verify more |
| None | Assumption only | Must verify before claiming |
Write code
↓
Run verification
↓
Evidence collected? ─No→ Verify more
↓ Yes
Claim completion with evidence
WHEN to auto-invoke: Creating API routes, building endpoints, adding route.ts files, implementing REST/GraphQL APIs, adding authentication to APIs, rate limiting, API validation with Zod, handling HTTP methods (GET/POST/PUT/DELETE). WHEN NOT to invoke: Pure frontend work, styling, React components without API calls, documentation-only tasks, database migrations without API changes.
WHEN to auto-invoke: Code review requests, refactoring code, cleaning up code, performance optimization, security audits, linting issues, reducing technical debt. WHEN NOT to invoke: Building new features (use domain-specific skills), initial implementation, documentation-only work.
WHEN to auto-invoke: End of productive sessions, after solving difficult problems, after user corrections, after discovering effective workarounds, after establishing project conventions. WHEN NOT to invoke: Trivial sessions, sessions with only exploration, when explicitly told not to learn.
WHEN to auto-invoke: Database schema design, creating migrations, writing SQL queries, query optimization, Supabase operations, Prisma/Drizzle schema changes, PostgreSQL tasks, RLS policies, indexes. WHEN NOT to invoke: Pure frontend work, API logic without database, styling, React components, deployment tasks.
WHEN to auto-invoke: Creating CI/CD pipelines, GitHub Actions workflows, Docker/containerization, Vercel/Netlify deployment, infrastructure as code, environment variables, deployment configurations. WHEN NOT to invoke: Application code changes, UI development, database schema design, testing application logic.
WHEN to auto-invoke: Measuring code quality, testing AI outputs, establishing success criteria, defining acceptance tests, checking implementation correctness. WHEN NOT to invoke: Simple implementations, prototyping, exploration phases, when speed matters more than measurement.