Menu
Use before claiming tests pass, a build succeeds, or a bug is fixed
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
Use when changing cogitation project settings (test/build/lint commands, branching conventions, graphify/codex toggles), or the user says "change config", "update settings", or "set test command"
Use when setting up a project for cogitation for the first time, or the user says "set up cogitation", "init", or "configure this project"
Use at the start of any conversation — establishes the cogitation workflow and requires invoking the right skill before responding, including before clarifying questions
Use for MEDIUM-sized work — new but contained behavior (one component, no architecture/data/API change) that deserves rigor without the design-doc + plan-doc ceremony of brainstorming
Use when the user wants to tailor the cogitation workflow — says "customise", "recustomise", "change the workflow", "make TDD less strict", "turn off finishing-branch", or wants a skill looser or disabled
Use when EC memories need cleanup — deduping, pruning stale entries, hygiene — or the user says "audit memories", "clean up EC", or "review what's stored"
| name | verifying |
| description | Use before claiming tests pass, a build succeeds, or a bug is fixed |
Don't claim something works until you've seen the evidence.
Announce: "I'm using the verifying skill to confirm this works."
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION
Before running commands, get the configured commands from EC:
ec_search:
query: project config
type: config
area: project
Extract: test_command, lint_command, build_command
If no config: Use sensible defaults but warn:
"No project config found. Using default commands. Consider running @cog-init."
Search EC for verification issues in this area:
ec_search:
query: verification gotcha
type: learning
Apply any known workarounds or warnings.
Before claiming any success:
Use the project-configured commands:
| Claim | Command | Fallback |
|---|---|---|
| "Tests pass" | {test_command} | npm test |
| "Build succeeds" | {build_command} | npm run build |
| "Types check" | {lint_command} | npx tsc --noEmit |
| "Lints clean" | {lint_command} | npm run lint |
| Claim | Requires | Not Sufficient |
|---|---|---|
| "Tests pass" | Test output showing 0 failures | Previous run, "should pass" |
| "Build succeeds" | Build with exit 0 | Linter passing |
| "Bug fixed" | Test for the bug passes | "I changed the code" |
| "Type-safe" | Type-check with no errors | "Looks right" |
Without fresh evidence, never say:
NO: "Fixed the bug, tests should pass now"
YES: [Run tests]
"Tests pass: 47/47. Bug fix verified."
If verification reveals a non-obvious issue:
ec_add:
type: learning
area: verification
content: [What the gotcha was]
rationale: Discovered during verification
Examples worth storing:
Evidence first. Claims second.