agentleFS
Sign inStart free
BuddhiliveBuddhilive/buddhi-cli/.agents/skills/verify/SKILL.md

verify

Skill1 starsChanged 14 days agoMITView on GitHub

Prove that changes work and satisfy acceptance criteria by running real build, lint, and test commands via the terminal-runner agent, mapping evidence to SDD user stories when available, and reporting genuine pass/fail evidence. Use when validating changes with /verify.

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 8 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

  • Jurel89Skill

    ai-slop-cleaner

    Clean AI-generated code slop with a regression-safe, deletion-first workflow and optional reviewer-only mode

    Also in 4 projects that use this

The file

We split this skill into the rules it gives an agent

11 rules. 0 are common, 3 are distinctive, and 8 are very specific to this project.

  • 0

    Common

    Most of the 167 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 8

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run buddhi sdd check --paths-only --json (via the terminal-runner agent).

    line 21
  2. Very specific:

    If a valid feature spec (FEATURE_SPEC) and tasks (TASKS) exist for the current branch, operate in SDD Convergence Mode: read spec.md to …

    line 22
  3. Distinctive:

    If no feature context is active, operate in Generic Verification Mode.

    line 25
  4. Very specific:

    Run git diff / git status (via terminal-runner) to determine changed files, or use the explicit target specified in $ARGUMENTS.

    line 27
  5. Distinctive:

    When the feature touches UI, visual styling, or frontend templates:

    line 39
  6. Very specific:

    Run buddhi scripts verify-a11y (or MCP verify_a11y) via the terminal-runner agent to run the static gate (anti-patterns, contrast evidence, …

    line 40
  7. Very specific:

    Run buddhi scripts contrast or MCP check_contrast to verify all measured pairs against WCAG floors.

    line 41
  8. Very specific:

    Run /compare-screenshots (using buddhi scripts visual-parity-diff) to check objective pixel, edge, and scene metrics against the reference …

    line 42
  9. Very specific:

    Run /screenshot-critique using a fresh, unprimed subagent to inspect the UI, and verify the report with buddhi scripts receipts.

    line 43
  10. Very specific:

    Run a consolidated /review pass (refactor-clean → code-review → write-docs) to ensure the codebase remains free of legacy wrappers, dead …

    line 45
  11. Distinctive:

    Never claim a requirement is verified without presenting actual execution evidence.

    line 48

“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

/verify

$ARGUMENTS

Prove that changes work by actually running real verification commands and mapping results against acceptance criteria, rather than claiming success from static reading.

Steps

  1. Check feature context (SDD convergence check): Run buddhi sdd check --paths-only --json (via the terminal-runner agent).
    • If a valid feature spec (FEATURE_SPEC) and tasks (TASKS) exist for the current branch, operate in SDD Convergence Mode: read spec.md to extract each user story's acceptance scenarios (Given/When/Then) and success criteria (SC-001...).
    • If no feature context is active, operate in Generic Verification Mode.
  2. Identify changed scope: Run git diff / git status (via terminal-runner) to determine changed files, or use the explicit target specified in $ARGUMENTS.
  3. Determine project verification commands: Consult .buddhi/docs/ and query the code graph via Buddhi MCP tools (buddhi_search, buddhi_read, see the okf-context skill) plus the project's manifest/build configuration files to detect the exact build, lint, typecheck, and test commands genuinely used by this project. Never guess or assume generic commands without confirming them in project configuration.
  4. Execute verification via terminal-runner: Execute every verification command exclusively through the terminal-runner agent. Commands should leverage buddhi scripts rtk run -- to keep context lean while preserving all errors and saving full raw logs under .buddhi/rtk/raw/ on failure for complete auditability.
  5. Visual & Accessibility verification gates (for UI/Visual changes):
    • When the feature touches UI, visual styling, or frontend templates:
      • Run buddhi scripts verify-a11y (or MCP verify_a11y) via the terminal-runner agent to run the static gate (anti-patterns, contrast evidence, freshness, and artifact integrity). Verify that REPORT.md contains fresh execution records and passes the gate.
      • Run buddhi scripts contrast or MCP check_contrast to verify all measured pairs against WCAG floors.
      • Run /compare-screenshots (using buddhi scripts visual-parity-diff) to check objective pixel, edge, and scene metrics against the reference design.
      • Run /screenshot-critique using a fresh, unprimed subagent to inspect the UI, and verify the report with buddhi scripts receipts.
  6. Code closeout verification:
    • Run a consolidated /review pass (refactor-clean → code-review → write-docs) to ensure the codebase remains free of legacy wrappers, dead references, and stale docs.
  7. Analyze and report evidence:
    • Map each execution outcome (command, real exit code, filtered output, and raw recovery log path if failed) to the relevant acceptance criteria in spec.md.
    • Never claim a requirement is verified without presenting actual execution evidence.

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.

Check your setup, free