Skip to content
Back to skills

Verify Delegated Work

ASecurity

Use AFTER a delegate (local model, cloud subagent, or external tool) returns output that modifies state, generates code, or asserts facts. Triggered by the need to validate correctness before trusting the result. Do NOT use for planning, briefing, or runtime checks. Covers ground-truth comparison, mutation testing of generated tests, and the retry ceiling.

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 26, 2026
ai-agentsrusttestinggit

Security analysis

A100/100

Scanned October 7, 2026

npx -y skills add haiggoh/free-agents --skill verify-delegated-work --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Verify Delegated Work?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Verify Delegated Work
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/haiggoh-verify-delegated-work/badge)](https://www.skillsdirectory.com/skills/haiggoh-verify-delegated-work)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: verify-delegated-work
description: 'Use AFTER a delegate (local model, cloud subagent, or external tool) returns output that modifies state, generates code, or asserts facts. Triggered by the need to validate correctness before trusting the result. Do NOT use for planning, briefing, or runtime checks. Covers ground-truth comparison, mutation testing of generated tests, and the retry ceiling.'
---

# verify-delegated-work — trust nothing, verify everything

A smaller model or automated agent’s default failure mode is **plausible-but-wrong**. It will return a clean diff, a passing test suite, or a confident summary that is subtly incorrect. Verification is not optional; it is the cost of offloading.

## Capture ground truth BEFORE delegating
You cannot verify what you do not know. Before dispatching work that touches files or asserts facts, capture the baseline:
- **File state:** `git diff` for tracked files, otherwise a content hash — use `shasum -a 256`, which is
  present on both macOS and Linux (`md5sum` is GNU coreutils and is missing from most macOS installs).
- **Fact state:** The actual list of files, the current value of a variable, or the output of a diagnostic command.
- **Test state:** The current pass/fail status of the test suite.

Store this baseline in a temporary variable or file. When the delegate returns, compare its output against this baseline, not against your memory of it.

## Judge by observable outcome change
Do not accept "it replied" or "no error" as success. Verify by **observable change**:
- **Code/Files:** Does the diff match the intent? Does the file exist where promised?
- **Tests:** Did the test suite pass *after* the change? If the delegate wrote new tests, **mutation-test them**: break the code intentionally and ensure the new tests fail. If they don’t, the tests are useless.
- **Facts/Summaries:** Does the summary match the ground truth captured in step 1? Spot-check specific claims against the source.

## Verify at the seam the framework reads, with a probe that fails on the old code
A correct part is not a working integration. When a fix is wired INTO something — a framework
driver, a plugin hook, injected config, an env var a launcher exports — assert on the object or
behaviour the framework actually USES at runtime, not on the component the delegate wrote.
Construct the real thing and inspect it: the live instance attribute, the environment the child
process receives, the command the hook really emits. Measured: a delegate set a correct driver
subclass as a CLASS attribute, the framework's constructor overwrote it on the INSTANCE, and the
waypoint closed "done, all tests pass" because the tests checked the subclass. One probe that
built the app and printed the instance attribute showed the default driver.

Then make sure the probe can tell old from new. Run it against the code BEFORE the change and
watch it fail; if it passes on both, it proves nothing. Prefer replaying the real failing input
(the exact command, request or payload from the log or transcript) over a hand-written paraphrase:
in the same audit, two hand-written probes passed on both versions of a guard hook, and only the
replayed command told them apart. Same for a wiring test that greps the source for the right text:
it passes while the line is commented out. Run the wired block and check what it produced.

## The retry ceiling (stop looping)
Verification is cheap, but infinite loops are not. If a delegate fails verification:
1. **Correct the briefing** (was the instruction ambiguous? Was the context missing?) and re-dispatch.
2. **Count failures.** After **N failed verifications** (default N=3), **stop looping**.
3. **Fallback:** Either do the work directly on the cloud model (if quality-critical) or park the item with a clear reason ("failed verification 3x, parked for manual review").

Do not keep retrying the same delegate with the same briefing. The compute is free, but your time is not.

## Universal application
This skill applies to **any** handoff: local models, cloud subagents, or external scripts. The principle is identical: capture truth, delegate, compare, and enforce a ceiling.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.