What makes ia-verification-before-completion notable?

2.1K downloads. Trust evidence available

How should ia-verification-before-completion be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

ia-verification-before-completion

Enforces fresh verification evidence before any completion claim. Use when about to claim "tests pass", "bug fixed", "done", "ready to merge", handing off work, or before editing when a request has ambiguous scope.

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

2.1k

Updated

Oct 9, 2026

Version

5.0.1

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 2.1K downloads reported by the source. Last updated 10/9/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 9, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 9, 2026
Adoption signal: 2.1K downloadsadoption · observed Oct 9, 2026
Latest release: 5.0.1release · observed Oct 3, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17bcar8wq0xhegs0ny6f57ypd8484bw:compound-eng-verification-before-completion

Install using `clawhub skill install s17bcar8wq0xhegs0ny6f57ypd8484bw:compound-eng-verification-before-completion` in an isolated environment before connecting it to live workloads.
No published capability contract is available yet, so validate auth and request/response behavior manually.
Review the upstream CLAWHUB listing at https://clawhub.ai/iliaal/compound-eng-verification-before-completion before using production credentials.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-iliaal-compound-eng-verification-before-completion/snapshot"

Documentation

CLAWHUB

145,997 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: ia-verification-before-completion
class: discipline
description: >-
Enforces fresh verification evidence before any completion claim. Use when
about to claim "tests pass", "bug fixed", "done", "ready to merge", handing
off work, or before editing when a request has ambiguous scope.
---

# Verification before completion

Make completion claims only from fresh evidence for the actual claim. Follow the user's authorized scope; repository instructions supply applicable checks, not permission to mutate, publish, or weaken a requirement.

## Procedure

1. Resolve ambiguous scope before editing. Inspect the repository and state a safe assumption when one interpretation is clear. Ask only when materially different interpretations remain; do not edit the disputed scope while waiting.
2. Inspect `git status --porcelain` and preserve unrelated work. Before any suite or migration runs, including a baseline, confirm its database and service targets are disposable (a dedicated test database, container, or throwaway schema; never the dev database) ([proof-integrity.md](./references/proof-integrity.md), Pre-Verification Check). For dependency/framework upgrades, codegen, or migrations, capture the existing validation command set before writing and rerun it unchanged afterward. If that baseline is red, report before proceeding. Shared-module verification on a dirty tree needs an isolated base comparison.
3. **Identify** the command that proves the claim. For ship-level claims, check the full applicable chain: build, types, lint, tests, security scan, and diff review; stop on the first failure. Read project-declared gates and run the ones that apply to this action in their required order; do not invent gates.
4. **Run** the proof now. Earlier output, a subagent's report, confidence, and a renamed success phrase do not replace fresh execution.
5. **Read** complete output and exit status, including warnings, executed/passed counts, and missing artifacts. A suite that executes nothing is not proof. Confirm the intended binary, interpreter, source revision, and entry point actually ran.
6. **Verify** that evidence covers the requirements and relevant failure paths. An implemented safe positive capability must work through its intended entry point; a refusal-only path, stub, mock, or unreachable implementation is partial.
7. **Claim** only what the evidence establishes. Report the outcome, exercise command/URL/click path, failed or skipped checks, and material residual risks. State narrower proof scope and distinguish deterministic fixtures from live behavior.

Never make an oracle easier to satisfy to obtain green. Review and justify semantic changes before regenerating expected output. Never hard-code the exercised subject or success path. A clean review is valid when it covers the relevant criteria; broaden checks only for a named remaining risk.

## Route by verification risk

- For dirty worktrees, broad changes, strict input validation, or fixture

_meta.json

{
  "ownerId": "kn715jrbbh71q9zncr0bqdkr8n848q1a",
  "slug": "compound-eng-verification-before-completion",
  "version": "5.0.1",
  "publishedAt": 1791047532495
}

references/change-strategies.md

# change strategies

## Verification Strategies by Change Type

For runnable code with those checks available, type-check and unit tests form a baseline, not sufficient proof on their own. Apply the repository's actual checks to other artifacts. Match the strategy to the change:

| Change type | Required verification |
|-------------|----------------------|
| Frontend (component, page, form) | Start the dev server, exercise the feature in a browser, check the console; test the happy path AND one failure path |
| Backend handler / endpoint | `curl` the endpoint, check response shape and status code, hit at least one error path (invalid input, missing auth) |
| Asynchronous workflow / queued job | Exercise the real entry point, then wait within its documented deadline for terminal processing and inspect the durable business effect. Acceptance or enqueue success alone proves no completion. Exercise a relevant terminal failure or dead-letter path and verify its recorded outcome |
| CLI tool | Run the binary with real inputs; check stdout, stderr, exit code. Run from `/tmp` to catch "only works from source" bugs |
| Infra / IaC (Terraform, Dockerfile, k8s) | `terraform plan` / `docker build` / `kubectl apply --dry-run=server`; review the diff before applying |
| Database migration | Run migration up, down, then up again against production-shape data |
| Refactoring (no behavior change) | Full test suite passes unchanged; public API surface diff shows no breakage (`grep` exported identifiers) |
| Mechanical or scripted sweep (width-based rewrap, regex pass, in-place edit) | Verify with a parser or compiler (`compileall`, `cargo check`, `tsc --noEmit`, a build), never with the linter's error tally |
| Library / package update | Run the consumer's test suite against the new version; check for deprecation warnings |
| Published package or release artifact | Install the published version into a throwaway directory and exercise the API the release added; the working tree shares the source, autoloader, and every uncommitted edit, so it proves nothing about what a consumer receives |
| Schema change | Old consumers parse the new shape (forward compat); new consumers handle old data still present (backward compat) |
| Documentation / prose | Read the rendered output; confirm links, formatting, and content match intent |
| Config with no validator | Validate syntax where possible (`jq .`, `yamllint`); otherwise read the file and confirm it matches the intended change |
| Non-runnable changes | `git diff`, confirm the diff matches intent, and state explicitly: "No automated verification available; verified by reading the diff." |

Reading code is not a strategy. If the table has no row for the change, fall back to the Non-runnable row. The principle holds even when no test suite applies: state what was checked and how.

A falling lint count is fully compatible with a corrupted file: most linters report only the *first* parse failure per file, so six broken liter

references/claims-and-failures.md

# claims and failures

## When This Applies

- About to claim "tests pass", "build succeeds", or "bug fixed"
- About to commit, push, create a PR, or mark a task complete
- Before closing a phase or work item
- Reporting results to the user
- A subagent reports success on delegated work

## Red Flags

**Clean results do not require manufactured findings.** A first pass with zero issues is valid when the evidence covers the stated acceptance criteria and relevant failure paths. Broaden verification only when the current proof leaves a named risk untested.

**Do not inflate the claim.** Name the proof scope when it is narrower than the natural reading of the completion claim. A targeted test supports the named behavior; only the full suite supports a full-suite claim.

## Requirements vs Tests

"Tests pass" and "requirements met" are different claims: re-read the plan or requirements, create a line-by-line checklist, verify each item against the implementation, then report gaps or confirm completion. Passing tests prove the code works, not that the right code was written.

## Common Claims and Their Proof

| Claim | Required Proof |
|-------|---------------|
| "Tests pass" | Test runner output showing 0 failures, exit code 0 |
| "Build succeeds" | Build command output with exit code 0 |
| "Bug is fixed" | Original reproduction case now passes |
| "Feature complete" | All acceptance criteria verified individually |
| "No regressions" | Full test suite passes, not just new tests |
| "Regression test works" | Red-green cycle: test passes, revert fix, test fails, restore fix, test passes |
| "Linting clean" | Linter output showing 0 errors/warnings |

## Classify Before Claiming Done

Before marking a deliverable done, classify how it can be verified, then verify by that route:

| Class | Example | Verification route |
|-------|---------|-------------------|
| Diff-verifiable | new service, validation logic, migration file | the change appears in `git diff <base>...HEAD` and its check runs |
| Cross-repo | a file or contract in a sibling repository | the sibling is reachable on disk: check the path exists and holds the expected content; unreachable means unverifiable, cite what to check |
| External state | DNS record, cloud console setting, OAuth allowlist, secret-manager entry | unverifiable from the tree; name the system and the exact check the user must run |
| Content shape | a file must follow a convention | in this repo: run the project's validator; elsewhere: cross-repo rules apply |

The ledger tracks per-item sweep state; these outcomes classify each deliverable in the final report; a ledger row is `done` only when its deliverable classifies as done or changed. Outcomes are **done**, **partial**, **not done**, **changed** (same goal, different means; say how), or **unverifiable**. A concrete filesystem path is never unverifiable: run the existence check and report done or not done. Code that *handles* a deliverable is not the deliverable; shi

references/isolated-verification.md

# Isolated Verification

A green build or test run in the working tree is not proof the change is sound. Unrelated work-in-progress already present (uncommitted edits, untracked files, a sibling branch's leftovers) can supply a missing symbol, satisfy an import, or mask a break that the change alone would expose. The contaminated local pass is not the evidence; a clean pass in isolation is.

When the change is high-stakes (touches shared modules consumed elsewhere) or the tree cannot be made clean first, reproduce the pass against an explicit known-good base with only the selected owned delta applied.

1. Resolve the base and enumerate exact repository-relative file paths, including deleted paths, both sides of renames, and selected untracked files. Do not use directory or glob selections.
2. Choose the snapshot source. Leave `owned_patch` empty only when every base-to-current difference in each selected file is owned; this mode captures current bytes, including committed, staged, unstaged, and selected untracked work. It does not verify a staged-only or PR-head scope.
3. For mixed owned/caller hunks or another selected revision, prepare an owned-only checkout at the base, apply the inspected owned hunks there, and copy only the selected new-file bytes. Stage the explicit files in that scratch checkout and export its reviewed binary `git diff --cached --no-textconv --no-ext-diff --binary <base> -- <paths>` to a private patch file. Set `owned_patch` to that absolute path. Inspect the patch against the requested scope before using it; a whole-file diff from the dirty caller is not an owned patch.
4. Materialize the snapshot using a separate index and a detached worktree. Check the expected tree and actual file content before running verification. Neither snapshot mode writes the caller's files or index.

This recipe requires Git, Bash, and Python 3. Fill the base, exact paths, optional reviewed patch, and build/test commands before running:

```bash
set -euo pipefail
umask 077
export GIT_LITERAL_PATHSPECS=1
repo_root=$(git rev-parse --show-toplevel)
verify_base=$(git -C "$repo_root" rev-parse --verify "<known-good-commit>^{commit}")
owned_paths=(path/to/owned-file path/to/other-owned-file path/to/selected-new-file)
owned_patch=""
scratch_root=$(mktemp -d)
verify_dir="$scratch_root/tree"
snapshot_index="$scratch_root/index"

cleanup() {
    git -C "$repo_root" worktree remove --force "$verify_dir" >/dev/null 2>&1 || true
    rm -rf -- "$scratch_root"
}
trap cleanup EXIT
snapshot_git() {
    GIT_INDEX_FILE="$snapshot_index" git -C "$repo_root" "$@"
}

snapshot_git read-tree "$verify_base"
if [[ -n "$owned_patch" ]]; then
    snapshot_git apply --cached "$owned_patch"
else
    snapshot_git add --all --force -- "${owned_paths[@]}"
fi
expected_tree=$(snapshot_git write-tree)
snapshot_git diff --cached --no-textconv --no-ext-diff --binary "$verify_base" -- "${owned_paths[@]}" > "$scratch_root/owned.patch"

git -C "$repo_root" worktree add --detach "$veri

Github ReposUpdated 5h agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.