Agent skill

Verify Findings

by closedloop-ai in closedloop-ai/claude-plugins

Dispatch and collect the finding-verifier fleet at stage23verifyfindings (PLN-722).

Apache-2.0Auto-check passedTesting & QA

Install Verify Findings

skills CLI
$ npx skills add closedloop-ai/claude-plugins --skill verify-findings -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install closedloop-ai/claude-plugins verify-findings --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/closedloop-ai/claude-plugins.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/code-review/skills/verify-findings .claude/skills/verify-findings && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
verify-findings
GitHub stars
122
Token cost
~2k tokens
SKILL.md length
884 words
Files
1
Skills in repo
41
Repo updated
First seen
Licence
Apache-2.0

At a glance

Dispatch and collect the finding-verifier fleet at stage23verifyfindings (PLN-722).

  • The reviewer fleet (stage20 — see the spawn-reviewers skill)
  • Calls claude
  • The PLN-725 singletons (stage11/stage15 — see the singleton-dispatch skill)

What it does

Verify Findings is an agent skill from closedloop-ai/claude-plugins. Dispatch and collect the finding-verifier fleet at stage23verifyfindings (PLN-722). Reads verifymanifest.json (written by stage22bverifyprepare), spawns one falsify-oriented verifier Task per toverify[] entry with mode-specific Task scheduling (GitHub mode dispatches verifiers synchronously; local mode uses parallel background + blocking TaskOutput), skips cachehits[], and collects outputs without retry — missing outputs degrade to pendingverification[] (and, in GitHub mode, a missing BLOCKING/HIGH verifier…

Its SKILL.md is about 2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA, covering Test coverage. It works with GitHub. The repository describes itself as: Open-source Claude Code plugins for multi-agent software delivery. Plan-first SDLC workflow, code review, LLM quality judges, and self-learning — grounded in your codebase… The licence is Apache-2.0.

When your agent uses it

  • The reviewer fleet (stage20 — see the spawn-reviewers skill)
  • The PLN-725 singletons (stage11/stage15 — see the singleton-dispatch skill)

Example prompts

  • “/verify-findings”

What it can do on your machine

Read from SKILL.md and the folder at commit 476b54c. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • claude

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Verify Findings loads about 2k tokens when it runs. Until then it costs about 196 tokens; SKILL.md has 884 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~196
When it runs · the whole SKILL.md, loaded when a task matches
~2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from closedloop-ai/claude-plugins at commit 476b54c, republished under its Apache-2.0 licence (© closedloop-ai). 884 words, ~2,013 tokens.

Download SKILL.mdSave it as .claude/skills/verify-findings/SKILL.md (or your agent's skills folder).
name
verify-findings
description
Dispatch and collect the finding-verifier fleet at stage_23_verify_findings (PLN-722). Reads verify_manifest.json (written by stage_22b_verify_prepare), spawns one falsify-oriented verifier Task per to_verify[] entry with mode-specific Task scheduling (GitHub mode dispatches verifiers synchronously; local mode uses parallel background + blocking TaskOutput), skips cache_hits[], and collects outputs without retry — missing outputs degrade to pending_verification[] (and, in GitHub mode, a missing BLOCKING/HIGH verifier raises a coverage-gap signal). Invoke when the walker reaches stage_23_verify_findings. Do NOT use for the reviewer fleet (stage_20 — see the spawn-reviewers skill) or the PLN-725 singletons (stage_11/stage_15 — see the singleton-dispatch skill).

Finding-Verifier Fleet Dispatch (stage_23_verify_findings)

This skill is the canonical finding-verifier dispatcher for /code-review at stage_23_verify_findings. It is split out of commands/start.md so the orchestration spine stays lean; the orchestrator invokes it when the walker reaches stage_23_verify_findings. The content below is authoritative for both MODE=local and MODE=github, with mode-specific Task scheduling: GitHub mode dispatches verifiers synchronously, while local mode preserves parallel background dispatch plus blocking TaskOutput collection.


Verifier Fleet (stage_23_verify_findings)

This stage runs when the walker reaches stage_23. It implements PLN-722's finding-verification pass: each eligible finding gets an independent second opinion from a verifier agent prompted to falsify (not confirm) the original claim. Findings that survive land in verified[]; findings rejected with positive evidence land in rejected[] and surface in the "Dismissed Findings" section so humans can falsify the dismissal.

Inputs

stage_22b_verify_prepare already wrote <CR_DIR>/verify_manifest.json and one input file per eligible finding at <CR_DIR>/verifier_inputs/<finding_id>.json. Read the manifest:

{
  "to_verify": [{"finding_id", "model", "input_path", "output_path", ...}, ...],
  "skipped_no_verification": [...],
  "deferred_budget": [...],
  "cache_hits": [...]
}

cache_hits[] entries have already been materialized at their output_path; do NOT respawn them. Only entries in to_verify[] need fleet dispatch.

If verify_manifest.json is absent, do NOT dispatch any verifier — stop and report. stage_22b_verify_prepare writes it last and exits 3 without it when it could not prove the review root, so a missing manifest means the verifiers would resolve source paths against a tree that is not the one under review.

Spawn contract

First branch on MODE. GitHub and local runs intentionally use different Task scheduling because GitHub headless mode cannot survive outstanding background verifiers after the assistant turn ends.

GitHub mode (MODE=github): dispatch synchronously. Spawn exactly one verifier at a time and wait for its Task response before spawning the next to_verify[] entry. Omit run_in_background or set run_in_background: false; never set it to true for GitHub verifiers. Do not use TaskOutput, watcher files, sleep loops, polling loops, or "wait for background task" turns in GitHub verifier dispatch. Each verifier must finish, write its verdict JSON to the manifest entry's output_path (<CR_DIR>/agent_verifier_<finding_id>.json), and return before the walker dispatches the next to_verify[] entry. When stage_23 completes in GitHub mode there must be no verifier task still running.

Local mode (MODE=local): spawn ALL verifiers at once. Use run_in_background: true on every verifier Task. You can spawn all agents in a single message or across a few messages.

Each spawned verifier — in either mode — uses subagent_type: "code-review:code-review-worker" (tool allowlist Read, Write, Grep, Glob — identical to the Reviewer Fleet's, so no permission changes are needed) and this prompt template:

You are the FINDING VERIFIER. Read your prompt at:
  {VERIFIER_PROMPT_PATH}

Your input file is at:
  {INPUT_PATH}

Read it for the finding to verify, the canonical output path, and the
per-output JSON shape. Write your verdict JSON to the output path the
input file specifies. Do not write anywhere else.

Substitute the resolved paths from the manifest entry (the verifier prompt is at <CR_DIR>/verifier_prompt.txt, copied by stage_02_prep_assets). Each input file also carries a review_root field — an absolute path stage_22b_verify_prepare proved holds this diff before writing the manifest, so it is never empty on a healthy run; the verifier prompt tells the agent to resolve every source path under it rather than against its own working directory (which is the invoking session's checkout, not the code under review) — no extra wiring is needed here. Set model to the entry's model field (currently uniform sonnet; future revisions may split by original-reviewer model for cross-model independence).

Show full SKILL.md (381 more words)Show less
Collection contract
  • Local collection (MANDATORY for MODE=local): Call TaskOutput (block: true) for every spawned local background verifier before letting the walker proceed past stage_23. You MUST collect ALL verifiers before consolidation. In headless GitHub mode there is no asynchronous completion notification, so GitHub verifier dispatch uses the synchronous branch above instead of backgrounding and collecting with TaskOutput.
  • A missing agent_verifier_<finding_id>.json is NOT a fatal error — cmd_verify_consolidate tags it as pending_verification[] so operators see what didn't get verified. In MODE=github, a missing verifier output for a BLOCKING/HIGH finding additionally raises a durable coverage-gap signal (see cmd_verify_consolidate / stage_24a_verify_consolidate) so an unverified high-severity finding cannot pass silently to an approved verdict.
  • Do NOT retry verifier agents in the walker. If a verifier fails, the finding's downstream handling already covers the gap (pending) — and verifier retries would burn tokens on a finding already flagged for human review. If a verifier is re-dispatched at all, it uses the same mode branch — GitHub verifier retries are synchronous; local retries may use the local background-plus-TaskOutput collection contract.
  • stage_23.on_failure == "continue": a fleet-wide failure does NOT abort the pipeline; verify-consolidate and finalize-result produce a usable envelope even when zero verifier outputs land on disk.
Cache hits (skip spawn)

Entries in verify_manifest.json.cache_hits[] are already on disk at agent_verifier_<finding_id>.json. Skip them. They flow into verify-consolidate the same way fresh fleet outputs do.

What you do NOT do
  • Do not read finding source files in the orchestrator (verifier agents read files via Read/Grep themselves).
  • Do not parse agent_verifier_*.json in the orchestrator — cmd_verify_consolidate (stage_24a) reads them.
  • Do not regenerate verify_manifest.json in the walker — cmd_verify_prepare (stage_22b) is the only writer.

Headless mode warning. In GitHub mode the review runs under headless claude -p, where there is NO asynchronous subagent-completion notification: when the orchestrator's assistant turn ends with no pending synchronous tool call, the process terminates immediately (terminal_reason: "completed"). If you background a verifier and then end your turn to "wait" for it, the run dies before stage_24a_verify_consolidate through stage_30_footer execute, so the verifier verdicts never land and any BLOCKING/HIGH finding whose verifier was outstanding ships unverified. The GitHub verifier synchronous Task calls and local-mode blocking TaskOutput collection are the only supported ways to keep the turn alive until verifiers finish; never substitute either with watcher files, sleep loops, polling loops, or "I'll continue when notified."

© closedloop-ai, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in plugins/code-review/skills/verify-findings of closedloop-ai/claude-plugins.

Open the folder on GitHubat commit 476b54c

Compare with similar skills

Verify Findings next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Verify Findings compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Verify Findings this skillclosedloop-ai/claude-plugins122—~2kAutomated safety check: PassApache-2.0
Reuse Before BuildAi-Eastern/reuse-before-build101—~5kAutomated safety check: PassMIT
Reviewwebern/cargo-readme385—~2kAutomated safety check: NotesApache-2.0
Reviewapollographql/apollo-mcp-server311—~2.9kAutomated safety check: PassMIT
Unit TestsWildGums/Orc.LicenseManager108—~2.1kAutomated safety check: PassCustom licence
Dev ReviewFHIR/fhir-codegen154—~5kAutomated safety check: PassMIT

Similar skills

  • Reuse Before Build

    Ai-Eastern/reuse-before-build

    Discover reusable implementations and tests before architecture design, substantial changes, or test work.

    101 GitHub stars~5k tokensUpdated 12 days ago
    Testing & QAAuto-check passed
  • Review

    webern/cargo-readme

    Reviews a GitHub pull request for correctness, architecture, security, backward compatibility, and test coverage.

    385 GitHub stars~2k tokensUpdated 11 days ago
    Testing & QAAuto-check: notes
  • Review

    apollographql/apollo-mcp-server

    Review a GitHub pull request for a Rust codebase. An agent skill from apollographql/apollo-mcp-server.

    311 GitHub stars~2.9k tokensUpdated yesterday
    Testing & QAAuto-check passed
  • Unit Tests

    WildGums/Orc.LicenseManager

    Write unit tests for this repository using NUnit following repository best practices.

    108 GitHub stars~2.1k tokensUpdated today
    Testing & QAAuto-check passed
  • Dev Review

    FHIR/fhir-codegen

    Performs a two-track code-quality and QA review in the roles of a staff-level Engineering Lead and QA Lead, then synthesizes both critiques into a single analysis.md.

    154 GitHub stars~5k tokensUpdated today
    Testing & QAAuto-check passed
  • Sonar

    ffroliva/gflow-cli

    Check the SonarCloud quality gate for a PR (or the current branch) and drive it to zero.

    264 GitHub stars~1.1k tokensUpdated today
    Testing & QAAuto-check: notes

More from closedloop-ai/claude-plugins

All 41 skills in this repo
  • Codex Review

    closedloop-ai/claude-plugins

    Run Codex to review a plan file and return structured feedback with a verdict.

    122 GitHub stars~1.4k tokensUpdated today
    Auto-check: notes
  • Critic Cache

    closedloop-ai/claude-plugins

    Check if critic reviews are still valid before re-running Phase 2.5 critics.

    122 GitHub stars~528 tokensUpdated today
    Auto-check: notes
  • Cross Repo Cache

    closedloop-ai/claude-plugins

    Check if cross-repo coordinator results can be reused, avoiding redundant Sonnet agent launches.

    122 GitHub stars~683 tokensUpdated today
    Auto-check: notes
  • Eval Cache

    closedloop-ai/claude-plugins

    Check for a cached plan-evaluation.json result before launching the plan-evaluator agent.

    122 GitHub stars~516 tokensUpdated today
    Auto-check: notes
  • Find Plugin File

    closedloop-ai/claude-plugins

    This skill should be used when needing to locate files within the Claude Code plugins cache directory (~/.claude/plugins/cache).

    122 GitHub stars~812 tokensUpdated today
    Auto-check passed
  • Gh Monitor PR

    closedloop-ai/claude-plugins

    Start a detached GitHub pull-request monitor that wakes the exact launching Codex Desktop or CLI root through the managed Codex App Server when review, CI, conflict, merge-queue, closure, readiness…

    122 GitHub stars~5.1k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Verify Findings

What does Verify Findings do?

Dispatch and collect the finding-verifier fleet at stage23verifyfindings (PLN-722). Verify Findings is an agent skill from closedloop-ai/claude-plugins. Dispatch and collect the finding-verifier fleet at stage23verifyfindings (PLN-722).

When should I use Verify Findings?

Verify Findings fits situations like: the reviewer fleet (stage20 — see the spawn-reviewers skill); the PLN-725 singletons (stage11/stage15 — see the singleton-dispatch skill).

How do I install Verify Findings in Claude Code?

Run `npx skills add closedloop-ai/claude-plugins --skill verify-findings -a claude-code`. Or copy the skill folder (plugins/code-review/skills/verify-findings in closedloop-ai/claude-plugins) into .claude/skills/verify-findings in your project. Claude Code loads it when a task matches its description.

How do I install Verify Findings in Codex?

Run `npx skills add closedloop-ai/claude-plugins --skill verify-findings -a codex`. Or copy the skill folder (plugins/code-review/skills/verify-findings in closedloop-ai/claude-plugins) into .agents/skills/verify-findings in your project. Codex loads it when a task matches its description.

Can I use Verify Findings in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add closedloop-ai/claude-plugins --skill verify-findings -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/verify-findings, .gemini/skills/verify-findings, .github/skills/verify-findings and .opencode/skills/verify-findings in your project.

What does Verify Findings need to run?

Going by SKILL.md and its folder, Verify Findings needs the command-line tools its instructions call (claude).

Does Verify Findings access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Verify Findings safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Verify Findings use?

Verify Findings is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Verify Findings use?

About 2k tokens (SKILL.md is roughly 8.1k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Verify Findings?

Skills that share tags, products or a category with Verify Findings: Reuse Before Build (Ai-Eastern/reuse-before-build, 101 stars), Review (webern/cargo-readme, 385 stars), Review (apollographql/apollo-mcp-server, 311 stars) and Unit Tests (WildGums/Orc.LicenseManager, 108 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Verify Findings?

closedloop-ai (a GitHub organization) maintains it in closedloop-ai/claude-plugins, which has 122 GitHub stars. The repository holds 41 skills in this directory. The repository was last updated on October 7, 2026.

Source: closedloop-ai/claude-plugins on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.