一键导入
verification-loop
Use when verifying implementation correctness - provides a systematic loop for checking tests, lint, build, and runtime behavior
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when verifying implementation correctness - provides a systematic loop for checking tests, lint, build, and runtime behavior
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Extract learned patterns from session - invoked automatically by finishing-a-development-branch or manually anytime
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for review, delivery, or cleanup
Use when executing implementation plans with independent tasks in the current session
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
| name | verification-loop |
| description | Use when verifying implementation correctness - provides a systematic loop for checking tests, lint, build, and runtime behavior |
A comprehensive verification system for Claude Code sessions.
Invoke this skill:
# Check if project builds
npm run build 2>&1 | tail -20
# OR
pnpm build 2>&1 | tail -20
If build fails, STOP and fix before continuing.
# TypeScript projects
npx tsc --noEmit 2>&1 | head -30
# Python projects
pyright . 2>&1 | head -30
Report all type errors. Fix critical ones before continuing.
# JavaScript/TypeScript
npm run lint 2>&1 | head -30
# Python
ruff check . 2>&1 | head -30
# Run tests with coverage
npm run test -- --coverage 2>&1 | tail -50
# Check coverage threshold
# Target: 80% minimum
Report:
# Check for secrets
grep -rn "sk-" --include="*.ts" --include="*.js" . 2>/dev/null | head -10
grep -rn "api_key" --include="*.ts" --include="*.js" . 2>/dev/null | head -10
# Check for console.log
grep -rn "console.log" --include="*.ts" --include="*.tsx" src/ 2>/dev/null | head -10
# Show what changed
git diff --stat
git diff HEAD~1 --name-only
Review each changed file for:
After running all phases, produce a verification report:
VERIFICATION REPORT
==================
Build: [PASS/FAIL]
Types: [PASS/FAIL] (X errors)
Lint: [PASS/FAIL] (X warnings)
Tests: [PASS/FAIL] (X/Y passed, Z% coverage)
Security: [PASS/FAIL] (X issues)
Diff: [X files changed]
Overall: [READY/NOT READY] for PR
Issues to Fix:
1. ...
2. ...
For long sessions, run verification every 15 minutes or after major changes:
Set a mental checkpoint:
- After completing each function
- After finishing a component
- Before moving to next task
Run: /verify
When invoked from sp-ecc:subagent-driven-development, follow this retry protocol:
IF any phase fails:
1. Dispatch fix subagent with specific failure details
2. Fix subagent addresses ONLY the failures (no other changes)
3. Re-run the full verification loop
4. If fail again: repeat (max 3 attempts total)
5. After 3 failures: STOP and report to user:
"Verification failed 3 times. Remaining failures:
- [list each failure with phase and details]
Manual intervention needed."
6. Write failure details to pipeline-state.md
Important: Each retry re-runs ALL phases, not just the failed one. A fix for one phase may break another.
This skill complements PostToolUse hooks but provides deeper verification. Hooks catch issues immediately; this skill provides comprehensive review.