verify
Skill6 starsChanged 14 days agoApache-2.0View on GitHub
Check correctness against tests, specs, or invariants; produce pass/fail evidence. Use when validating changes, testing hypotheses, checking invariants, or confirming behavior matches expectations.
188 other projects use a version of this.
Adopted by
Most recently taken up by
- Doist/todoist-aitheir own version, first seen Nov 9, 2026
- udecode/better-convextheir own version, first seen Nov 9, 2026
- pytorch/heliontheir own version, first seen Nov 8, 2026
- amir20/dozzletheir own version, first seen Nov 8, 2026
- Doist/todoist-clitheir own version, first seen Nov 8, 2026
- codewithmukesh/dotnet-claude-kittheir own version, first seen Nov 8, 2026
Used with
Projects with it also use instinct-export, instinct-import and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
TheKREATORSSkillinstinct-export
Export instincts from project/global scope to a file
Also in 3 projects that use this
TheKREATORSSkillinstinct-import
Import instincts from file or URL into project/global scope
Also in 3 projects that use this
AviadPSkillrisk-assess
Assess the risk and blast radius of a proposed code change before implementing it. Evaluates CI impact, framework-wide vs localized scope, rollback path, and identifies blindspots. Use when user says "what's the risk", "is this safe", "assess the impact", "risk assess", "blast radius", or before applying framework-wide or CI-affecting changes. Do NOT use for code quality review (use code-quality) or plan validation (use design-validator).
Also in 3 projects that use this
diego-tobalinaSkillbuild-fix
Fix build and compilation errors systematically. Run when build fails.
Also in 6 projects that use this
AaravChadhaSkillsecure
Security review with a confidence gate - a finding exists only with a concrete exploit scenario and a high/medium/low confidence rating; everything else goes to a worth-hardening list, never inflated. Sweeps five surfaces: auth gates, secrets hygiene, injection and unsafe sinks, unsafe deserialization/crypto/transport, and LLM tool-use trust boundaries. Reports only, never fixes. Use when the user asks for a security review or to check vulnerabilities, secrets, or auth.
Also in 3 projects that use this
ArvorCoSkillspecify
Create feature specification from natural language description. Use when starting a new feature or creating a spec. Triggers on: create spec, specify feature, new feature spec.
Also in 10 projects that use this
- +1 more from TheKREATORS
Other versions188 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 188
- react/react★ 252ksame name
- facebook/react★ 252ksame name
- garrytan/gstack★ 141ksame name
- oven-sh/bun★ 97ksame name
- anthropics/financial-services★ 41ksame name
- anthropics/financial-services-plugins★ 41ksame name
- Yeachan-Heo/oh-my-claude-sisyphus★ 41ksame name
- Yeachan-Heo/oh-my-claudecode★ 41ksame name
- anthropics/claude-quickstarts★ 19ksame name
- NVIDIA-NeMo/Speech★ 19ksame name
178 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository42 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- attributeSkill
- auditSkill
- gap-analysis-workflowSkill
- checkpointSkill
- classifySkill
- compareSkill
- constrainSkill
- critiqueSkill
- debug-workflowSkill
- decomposeSkill
- delegateSkill
- detectSkill
- digital-twin-bootstrapSkill
- digital-twin-sync-workflowSkill
- discover-capabilitiesSkill
- discoverSkill
- executeSkill
- explainSkill
- generateSkill
- groundSkill
- inquireSkill
- integrateSkill
- invokeSkill
- measureSkill
- mutateSkill
- observeSkill
- persistSkill
- perspective-validationSkill
- planSkill
- predictSkill
- recallSkill
- receiveSkill
- retrieveSkill
- rollbackSkill
- searchSkill
- sendSkill
- simulateSkill
- stateSkill
- synchronizeSkill
- transformSkill
- transitionSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. 0 are common, 12 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 167 edited versions we read keep these.
12
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Before verification, gather current state:
- Distinctive: line 27
Every check is grounded to observable output or file content
- Distinctive: line 29
All assumptions about expected behavior are explicit
- Very specific: line 46
Load conditions: Read the test/invariant definitions in conditions
- Distinctive: line 52
Read relevant code, config, or state
- Distinctive: line 54
Check preconditions are met before running tests
- Distinctive: line 56
Execute checks: Run each verification check systematically
- Distinctive: line 168
Evidence pattern: Test output captured from pytest execution, line numbers from stack traces.
- Distinctive: line 225
Do not modify the artifact being verified
- Distinctive: line 226
Do not skip failing tests or mask errors
- Distinctive: line 227
Stop and clarify if conditions are ambiguous or missing
- Distinctive: line 229
Do not access paths outside the workspace for verification
- Very specific: line 276
Never verify without a spec (constrain invariants or explicit conditions)
- Distinctive: line 277
Never modify artifact during verification (breaks idempotency)
- Very specific: line 278
Never ignore passed: false and proceed with mutations
“Common” is measured: kept by at least 6 in 10 of the 167 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Live Context
Before verification, gather current state:
- Working directory: !
pwd - Git status: !
git status --short 2>/dev/null || echo "Not a git repo" - Recent commits: !
git log --oneline -5 2>/dev/null || echo "No git history" - Last modified files: !
find . -type f -mmin -30 -not -path './.git/*' 2>/dev/null | head -10 || echo "None"
Intent
Execute verify to determine whether an artifact (code, configuration, state, output) conforms to a specification, passes tests, or satisfies declared invariants.
Success criteria:
- Clear pass/fail result (
passed) with supporting evidence - Every check is grounded to observable output or file content
- Failures include actionable fix suggestions
- All assumptions about expected behavior are explicit
Compatible schemas:
schemas/output_schema.yaml
Inputs
| Parameter | Required | Type | Description |
target | No | any | What to verify |
conditions | Yes | array | Conditions to check |
strict | No | boolean | Fail on first violation |
Inputs not listed here are outside the capability's contract: a workflow step that binds them gets W604 (STANDARD v1.1 §5.5).
Procedure
- Load conditions: Read the test/invariant definitions in
conditions- Identify testable assertions from the conditions
- Parse test commands or invariant expressions
- Note any preconditions required for verification
- Examine target: Inspect the target being verified
- Read relevant code, config, or state
- Identify the specific behavior/properties to check
- Check preconditions are met before running tests
- Execute checks: Run each verification check systematically
- For test suites: execute via Bash, capture stdout/stderr
- For invariants: evaluate conditions, record boolean results
- For schema validation: compare structure against schema
- Record timing and resource usage if relevant
- Analyze results: Determine
passedfrom check outcomespassed: true: All checks succeedpassed: false: One or more checks fail (each listed inviolations)- Inconclusive (errors or missing data):
passed: falsewithinconclusive: true
- Ground claims: Attach evidence anchors to all findings
- Format:
file:line,tool:bash:<command>, ortest:<test_name> - Include exact error messages and stack traces for failures
- Format:
- Format output: Structure results per output contract
- Include fix suggestions for each failure
- Calculate coverage metrics if applicable
Output Contract
Return a structured object:
passed: boolean # true only when every check passed
inconclusive: boolean # true when checks could not run (passed is then false)
results: # Per-condition results
- name: string # Check identifier
type: assertion | invariant | regression | schema
target: string # What was checked
passed: boolean
evidence: string # Output or file reference
violations: # Failed conditions
- check: string # Which check failed
expected: string # What was expected
actual: string # What was observed
severity: low | medium | high | critical
fix_suggestions:
- violation_ref: string # Which violation (by check name)
suggestion: string # How to fix
confidence: number # 0.0-1.0 for suggestion quality
coverage:
checked: integer # Number of checks run
total: integer # Total checks possible
percentage: number # Coverage percentage
confidence: number # 0.0-1.0
evidence_anchors: ["file:line", "tool:bash:...", "test:..."]
assumptions: [] # Explicit assumptions madeField Definitions
| Field | Type | Description |
passed | boolean | Overall result: true only when every check passed |
inconclusive | boolean | True when checks could not be run; passed is then false |
results | array | Per-condition results for every check executed |
violations | array | Failed conditions with expected vs. actual |
fix_suggestions | array | Actionable suggestions to fix violations |
coverage | object | Metrics about verification coverage |
confidence | number | 0.0-1.0 based on evidence quality and check coverage |
evidence_anchors | array | File:line, URLs, or tool output references |
assumptions | array | Explicit assumptions about expected behavior |
Examples
Example 1: Unit Test Verification
Input:
target: "src/calculator.py"
conditions:
- "pytest tests/test_calculator.py -v passes"Output:
passed: false
inconclusive: false
results:
- name: test_add_positive
type: assertion
target: Calculator.add
passed: true
evidence: "tool:bash:pytest - PASSED"
- name: test_divide_by_zero
type: assertion
target: Calculator.divide
passed: false
evidence: "tool:bash:pytest - AssertionError: Expected ZeroDivisionError"
violations:
- check: test_divide_by_zero
expected: "ZeroDivisionError raised"
actual: "Returns infinity"
severity: high
fix_suggestions:
- violation_ref: test_divide_by_zero
suggestion: "Add check for divisor == 0 before division in Calculator.divide()"
confidence: 0.9
coverage:
checked: 5
total: 5
percentage: 100.0
confidence: 0.95
evidence_anchors:
- "tool:bash:pytest tests/test_calculator.py -v"
- "src/calculator.py:42"
assumptions:
- "Test environment has pytest installed"
- "Tests are deterministic"Evidence pattern: Test output captured from pytest execution, line numbers from stack traces.
Example 2: Schema Validation
Input:
target: "config/production.yaml"
conditions:
- type: schema
schema_path: "schemas/config.json"Output:
passed: true
inconclusive: false
results:
- name: schema_validation
type: schema
target: config/production.yaml
passed: true
evidence: "All 12 required fields present, types valid"
violations: []
fix_suggestions: []
coverage:
checked: 1
total: 1
percentage: 100.0
confidence: 1.0
evidence_anchors:
- "config/production.yaml:1-45"
- "schemas/config.json:1"
assumptions:
- "JSON Schema draft-07 validation semantics"Verification
Apply the following verification patterns:
- Evidence Grounding: All results anchored to test output or file content
- Contract Validation: Output matches schema with required fields
- Idempotency Check: Re-running verify produces the same
passedresult (given unchanged inputs) - Coverage Tracking: results.length == coverage.total
Verification tools: Bash (for test execution), Read (for evidence files)
Safety Constraints
mutation: falserequires_checkpoint: falserequires_approval: falserisk: low
Capability-specific rules:
- Do not modify the artifact being verified
- Do not skip failing tests or mask errors
- Stop and clarify if conditions are ambiguous or missing
- Timeout all external test execution (default 5 minutes)
- Do not access paths outside the workspace for verification
Bundled Scripts
This skill includes utility scripts for automated verification:
verify-state.sh
Located at: scripts/verify-state.sh
Usage:
./scripts/verify-state.sh [--git] [--files] [--tests] [--all]Options:
--git- Verify git state (uncommitted changes, branch status)--files- Verify file integrity (broken symlinks, empty files)--tests- Execute project tests (auto-detects npm/pytest/rspec)--all- Run all verification checks (default)
Output:
- Console output with color-coded PASS/FAIL results
- JSON report saved to
.verification-report.json
Example:
# Run all checks
./scripts/verify-state.sh --all
# Check only git and file integrity
./scripts/verify-state.sh --git --filesComposition Patterns
Commonly follows:
constrain- Provides the invariants/spec to verify againstexecute/mutate- Verify the outcome of executed changes (they must precede verify)plan- Provides expected postconditions to verify
Commonly precedes:
audit- Record verification results for compliancerollback- Ifpassedis false, trigger rollback (CAVR pattern)critique- Analyze root cause of failures
Anti-patterns:
- Never verify without a spec (
constraininvariants or explicitconditions) - Never modify artifact during verification (breaks idempotency)
- Never ignore
passed: falseand proceed with mutations
Workflow references:
- See
reference/composition_patterns.md#debug-code-changefor CAVR pattern - See
reference/composition_patterns.md#digital-twin-sync-loopfor verify-after-act usage
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

