Menu
Verify a code change actually works by running the app and observing behavior. Tests pass ≠ change works.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.