Menü
Verify a code change actually works by running the app and observing behavior. Tests pass ≠ change works.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
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.