agentleFS
synaptiaisynaptiai/agent-capability-standard/skills/verify/SKILL.md

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

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.
  • TheKREATORSSkill

    instinct-export

    Export instincts from project/global scope to a file

    Also in 3 projects that use this

  • TheKREATORSSkill

    instinct-import

    Import instincts from file or URL into project/global scope

    Also in 3 projects that use this

  • AviadPSkill

    risk-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-tobalinaSkill

    build-fix

    Fix build and compilation errors systematically. Run when build fails.

    Also in 6 projects that use this

  • AaravChadhaSkill

    secure

    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

  • ArvorCoSkill

    specify

    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

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
  1. Distinctive:

    Before verification, gather current state:

    line 14
  2. Distinctive:

    Every check is grounded to observable output or file content

    line 27
  3. Distinctive:

    All assumptions about expected behavior are explicit

    line 29
  4. Very specific:

    Load conditions: Read the test/invariant definitions in conditions

    line 46
  5. Distinctive:

    Read relevant code, config, or state

    line 52
  6. Distinctive:

    Check preconditions are met before running tests

    line 54
  7. Distinctive:

    Execute checks: Run each verification check systematically

    line 56
  8. Distinctive:

    Evidence pattern: Test output captured from pytest execution, line numbers from stack traces.

    line 168
  9. Distinctive:

    Do not modify the artifact being verified

    line 225
  10. Distinctive:

    Do not skip failing tests or mask errors

    line 226
  11. Distinctive:

    Stop and clarify if conditions are ambiguous or missing

    line 227
  12. Distinctive:

    Do not access paths outside the workspace for verification

    line 229
  13. Very specific:

    Never verify without a spec (constrain invariants or explicit conditions)

    line 276
  14. Distinctive:

    Never modify artifact during verification (breaks idempotency)

    line 277
  15. Very specific:

    Never ignore passed: false and proceed with mutations

    line 278

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

ParameterRequiredTypeDescription
targetNoanyWhat to verify
conditionsYesarrayConditions to check
strictNobooleanFail 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

  1. 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
  2. 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
  3. 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
  4. Analyze results: Determine passed from check outcomes
    • passed: true: All checks succeed
    • passed: false: One or more checks fail (each listed in violations)
    • Inconclusive (errors or missing data): passed: false with inconclusive: true
  5. Ground claims: Attach evidence anchors to all findings
    • Format: file:line, tool:bash:<command>, or test:<test_name>
    • Include exact error messages and stack traces for failures
  6. 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 made

Field Definitions

FieldTypeDescription
passedbooleanOverall result: true only when every check passed
inconclusivebooleanTrue when checks could not be run; passed is then false
resultsarrayPer-condition results for every check executed
violationsarrayFailed conditions with expected vs. actual
fix_suggestionsarrayActionable suggestions to fix violations
coverageobjectMetrics about verification coverage
confidencenumber0.0-1.0 based on evidence quality and check coverage
evidence_anchorsarrayFile:line, URLs, or tool output references
assumptionsarrayExplicit 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 passed result (given unchanged inputs)
  • Coverage Tracking: results.length == coverage.total

Verification tools: Bash (for test execution), Read (for evidence files)

Safety Constraints

  • mutation: false
  • requires_checkpoint: false
  • requires_approval: false
  • risk: 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 --files

Composition Patterns

Commonly follows:

  • constrain - Provides the invariants/spec to verify against
  • execute / mutate - Verify the outcome of executed changes (they must precede verify)
  • plan - Provides expected postconditions to verify

Commonly precedes:

  • audit - Record verification results for compliance
  • rollback - If passed is false, trigger rollback (CAVR pattern)
  • critique - Analyze root cause of failures

Anti-patterns:

  • Never verify without a spec (constrain invariants or explicit conditions)
  • Never modify artifact during verification (breaks idempotency)
  • Never ignore passed: false and proceed with mutations

Workflow references:

  • See reference/composition_patterns.md#debug-code-change for CAVR pattern
  • See reference/composition_patterns.md#digital-twin-sync-loop for verify-after-act usage

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.