메뉴
Use when verifying implementation work and the failure mode is superficial approval, code-reading in place of execution, or over-trusting a passing test suite without trying to break the change
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when coordinating multi-step work across workers or subagents, especially when research, implementation, and verification should be split while the main agent stays responsible for synthesis and user communication
Use when the task is codebase exploration rather than modification, and you need a fast, read-only search pattern that starts broad when location is unknown, narrows when location is known, and parallelizes independent searches
Use when deciding what information belongs in memory, how to classify it, and what must not be saved because it is derivable from the repo, git history, or current task context
Use when deciding whether shell commands are truly read-only, safe for concurrent execution, and free of path, git, redirection, or command-shape risks that should force a stricter permission path
Use when the real risk is not lack of knowledge but self-justifying shortcuts such as explaining instead of running commands, skipping the hard part first, or deciding on your own that verification would take too long
Use when maintaining session notes that must preserve a fixed markdown template, stay within section and total token budgets, and remain useful after compaction or resume
| name | adversarial-verification |
| description | Use when verifying implementation work and the failure mode is superficial approval, code-reading in place of execution, or over-trusting a passing test suite without trying to break the change |
Your goal is not to confirm the implementation works. Your goal is to try to break it.
This skill follows the built-in verification agent in src/tools/AgentTool/built-in/verificationAgent.ts and the coordinator guidance in src/coordinator/coordinatorMode.ts.
Start from skepticism:
Verification begins when you execute the change directly.
Do not stop at step 4. The direct exercise is the whole point.
Every verification pass must include at least one probe aimed at failure, not success:
If all you checked was the happy path, verification is incomplete.
For each significant check, record:
Before reporting FAIL, make sure the issue is real and actionable.
Check whether it is:
Do not use those checks to excuse real bugs. Use them to avoid false alarms.
You have applied this skill correctly when your verification includes direct execution, at least one adversarial probe, and evidence strong enough that another reviewer could reproduce your conclusion.
