메뉴
Verify a code change actually works by running the app and observing behavior. Tests pass ≠ change works.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Route a task to the least intrusive executive-function support based on the user's stated current capacity, memory load, activation, and motivation. Use when work feels stuck, overwhelming, hard to hold in mind, or when the user asks for neurodivergent-friendly support without wanting a diagnostic or coaching ritual.
Reduce work to the smallest safe and useful outcome when capacity is low or burnout is present. Use when the user explicitly says they are depleted, overwhelmed, unable to start, or asks for the minimum viable version of a task.
Create a truthful activation bridge for a task that has low urgency, novelty, interest, challenge, or immediate feedback. Use when the user says they are stuck or avoiding a known task despite understanding it.
Reduce language, sensory, and uncertainty load while preserving complete information. Use when the user requests direct or scannable communication, has low capacity, is navigating a new flow, or needs explicit expectations and examples.
Turn a vague, oversized, or initiation-resistant outcome into an executable sequence with a visible first action and definition of done. Use when dependencies are hidden, the task spans multiple systems, or the user cannot identify where to begin.
Externalize time, checkpoints, stopping rules, and context transitions. Use when estimates are uncertain, a task may expand indefinitely, the user is switching topics, or an interruption risks losing the current state.
| name | cc-verify |
| description | Verify a code change actually works by running the app and observing behavior. Tests pass ≠ change works. |
Verify that a code change actually does what it's supposed to do by running the app and observing behavior.
Key principle: A green test suite proves the code compiles and existing tests pass. It does NOT prove the change works. Verification means observing the actual behavior.
Understand what the change claims to do:
git diff HEAD --stat
Run the test suite first:
npm test
If tests fail, stop — the change is broken. Fix before verifying.
Identify the right verification method:
Run the actual verification:
# For Vanta CLI changes:
cd /path/to/repo && ./run.sh run "<instruction that exercises the change>"
# Or for direct tool test:
node -e "import('./src/...').then(m => console.log(m.fn(...)))"
Report: what you ran, what you observed, and whether the change works. Cite the actual output — not the expected output.
If verification is not possible (no runtime, no TTY, external service), state that explicitly. Do NOT claim "done" without evidence.