Menü
Use before claiming tests pass, a build succeeds, or a bug is fixed
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.
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"
Basierend auf der SOC-Berufsklassifikation
| 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.