메뉴
Evidence-based verification with 2 quality gates (pre-check and post-check), anti-rationalization enforcement, and 3-step retry escalation. Used when completing tasks, verifying implementations, or before claiming work is done.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | verification |
| description | Evidence-based verification with 2 quality gates (pre-check and post-check), anti-rationalization enforcement, and 3-step retry escalation. Used when completing tasks, verifying implementations, or before claiming work is done. |
No completion claim is valid without fresh verification evidence produced in THIS session. Evidence from a prior session, a prior attempt, or reasoning about what "should" be true does not count. If the evidence was not collected by running a tool call in the current session, it does not exist.
Every claim about task completion, test status, build status, or spec compliance requires an Evidence Block. Produce one per claim.
**CLAIM**: [The specific assertion being made]
**EVIDENCE**: [Tool name and exact command or action taken]
**OUTPUT**: [Actual output, quoted verbatim — not paraphrased]
**VERDICT**: PASS | FAIL | SKIPPED
SKIPPED is only allowed when the claim is explicitly out of scope and the reason is documented. A skipped gate must be acknowledged by the caller.
Gates run in order. A failure at any gate stops forward progress until resolved.
Run before execution begins.
Failure action: Resolve the blocking state first. If the spec is unclear, return to requester with a clarifying question. Do not guess at requirements. Document what was found and what was done to fix it.
Run after implementation, before declaring done.
Failure action: Fix failures. Do not skip a failing test. Do not suppress a lint error. Each fix resets the gate — re-run from the top of Gate 2.
Three profiles control which gates and checks are required:
Use for: critical path work, breaking changes, security-sensitive code.
Use for: normal feature and fix work. This is the default profile.
Use for: trivial changes, documentation updates, config tweaks.
| Claim | Required Evidence | NOT Sufficient |
|---|---|---|
| Tests pass | npm test output showing pass count and zero failures | "I ran the tests" |
| Build succeeds | npm run build (or equivalent) with exit code 0 shown | "Build should work" |
| Lint is clean | npm run lint output with zero errors and zero warnings | "No obvious lint issues" |
| File was created | ls -la <path> or Read tool output showing the file | "I wrote the file" |
| Function behaves correctly | Test output or REPL output showing actual return value | "The logic looks right" |
| API responds correctly | Actual HTTP response body and status code | "The endpoint exists" |
| Dependency is installed | package.json or lockfile entry shown verbatim | "I installed it earlier" |
| Spec is met | Quoted spec requirement next to quoted output proving it | "This matches the spec" |
| No regressions | GUARD command output from this session | "Nothing was broken" |
| Migration ran | Migration log or schema diff output | "I ran the migration" |
Every task execution uses two paired commands.
VERIFY — "Did this task accomplish its stated goal?"
Run after implementation. Produces an Evidence Block for each acceptance criterion. If any criterion fails, the task is not done.
GUARD — "Did this change break what was already working?"
Run after VERIFY passes. Executes the full test suite and any smoke checks that existed before the task started. If GUARD fails after VERIFY passes, the implementation introduced a regression.
These phrases indicate a verification failure. They are never acceptable as evidence.
| Forbidden Phrase | Why It Fails |
|---|---|
| "should work" | Describes expectation, not observed outcome |
| "I already checked" | Not verifiable in this session |
| "tests were passing before" | Stale evidence; fresh run required |
| "this is obviously correct" | Correctness is measured, not assessed by inspection |
| "I think it's fine" | No tool output, no claim |
| "the logic is sound" | Logic can be sound and still produce wrong output |
| "nothing changed in that area" | Changes in dependencies, configs, and imports are invisible to this claim |
| "it worked in my local run" | Local run is not this session's evidence unless tool output is shown |
| "we can verify later" | Verification deferred is verification skipped |
| "this is low risk" | Risk level does not substitute for evidence |
If you catch yourself using any phrase from this table, STOP immediately and gather real evidence via a tool call.
When a gate fails, follow this 3-step escalation. Each step uses a fresh approach to avoid repeating the same mistake.
Standard fix attempt. Read the error output, fix inline, re-run gates.
Fresh agent context. Re-read the spec from scratch. Diagnose root cause before touching code.
If multi-model is available (config.execution.model_overrides has entries), spawn a Codex or alternate model agent for a fresh perspective. Otherwise, use a fresh Claude agent with the full diagnostic context from Steps 1 and 2.
Do not attempt a 4th run without user acknowledgment and revised instructions.
Auto-reopen the GitHub Issue and post a diagnostic comment (see "Gate Failure: Auto Issue Reopen" below). The escalation must include:
| Pitfall | Symptom | Correct Behavior |
|---|---|---|
| Caching test results | Reporting pass without re-running | Always run tests fresh; use --no-cache or equivalent |
| Partial lint scope | Running lint on one file, claiming lint is clean | Run lint on the entire affected module or project |
| Missing Pre-Check | Starting work before spec is confirmed | Always confirm acceptance criteria exist before writing code |
| Evidence copied from prior session | Referencing output not produced in this session | All evidence must come from tool calls in the current session |
| Verifying only the happy path | Tests pass but edge cases are untested | GUARD must include regression tests, not only new tests |
| Skipping Post-Check | Declaring done without regression check | Both Pre-Check and Post-Check are required (unless using fast profile) |
| Conflating "no errors" with "correct output" | Exit code 0 but wrong behavior | Evidence must show correct output, not just absence of error |
| Writing evidence after the fact | Constructing output from memory | Run the command, capture the output, paste it verbatim |
When verification fails, follow this structured process:
When a task fails verification after all 3 retry attempts, automatically reopen the associated GitHub Issue and post a diagnostic comment:
# Reopen the issue
gh issue reopen #{issue_number}
# Post diagnostic comment with all 3 attempt summaries
gh issue comment #{issue_number} --body "..."
The comment body should include:
Label the issue with type:bug, maxsim:auto, and verification:failed.
Each retry attempt MUST use a fresh executor agent:
Treat each fresh executor as a cold start. Do NOT reference or build upon any previous attempt's reasoning or partial work.
Routes work through MaxsimCLI commands based on project state and user intent. Provides command reference and decision routing table. Used when determining which MaxsimCLI command to use or when starting a new session.
Coordinates Tier 2 Agent Teams with TeamCreate, SendMessage, competitive implementation, multi-reviewer code review, and collaborative debugging patterns. Used when workflows require inter-agent communication, adversarial debate, or shared task lists.
Autonomous optimization loop with reference workflows. Powers /maxsim:improve, /maxsim:fix-loop, /maxsim:debug-loop, /maxsim:security. Used when running autonomous optimization, error repair, bug hunting, or security audit loops.
GitHub-native persistence for project learnings, decisions, and patterns using issue labels and structured comments. Used when recording what worked, what failed, or architectural decisions that should persist across sessions.
Orchestrates parallel agent execution using worktree isolation following Anthropic's batch pattern. Used when multiple independent tasks can be executed simultaneously.
Explores multiple implementation approaches before committing to one. Produces a structured comparison table with effort/risk assessment. Used when starting features, facing design decisions, or multiple valid approaches exist.