How do I install the Forge Verify skill?

Run npx skillmds@latest add forgeyclap/forge-verify-2 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Forge Verify safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Forge Verify?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Forge Verify free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Forge Verify?

ForgeyClap (@forgeyclap) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Forge Verify by forgeyclap — Agent Skill

Name: Forge Verify
Author: ForgeyClap

Forge Verify

Run Forge's verify-loop — after an agent (or a work package) claims to be done, check whether that claim actually holds against events.jsonl and the ticket store, and send the task back to the agent when it doesn't. Use after every agent/work-package completion in a /forge run, and again at the end of the run before the final report.

ForgeyClap a08dc5b 3.3 KB Updated Sep 17, 2026

File contents

forge-verify — the verify-loop

Closes the honesty gap between "an agent said it's done" and "the recorded events actually show it's done." Never trusts a completion claim on its own.

When to use (MANDATORY)

After each agent/work-package completes in a /forge run — before the Lead treats that agent's output as final.
At the end of the run, before writing the final report — a last honest check across every agent and every ticket the run touched.
Whenever the owner asks "did that agent actually finish?" or "check the tickets are really closed."

How to run

node .claude/forge-bin/forge-verify.cjs <run_id>                      # report only, exit 0/1
node .claude/forge-bin/forge-verify.cjs <run_id> --enforce            # report + send mismatches back
node .claude/forge-bin/forge-verify.cjs <run_id> --json               # full machine-readable result
node .claude/forge-bin/forge-verify.cjs <run_id> --root <projectRoot> # target a different project root

Exit code: 0 when there are no mismatches and no open tickets for the run; 1 otherwise — safe to gate a hook/CI step on it.

What it checks (mirrors the dashboard exactly)

Reconstructs per-agent task state from <run>/events.jsonl the same way the Forge Control Center does (forge-dashboard/app.js BACKBONE + taskStatus()): structural milestone events (run_started, agent_completed, lead_review_completed, …) are never counted as a "task"; every other event attributed to an agent is a task, and a task is "done" only when its status genuinely resolves to done. An agent "claims completed" once it has logged agent_completed or subagent_completed. A mismatch is an agent that claims completed while some of its own tasks are still open, running, or failed.

It also checks the ticket store (forge-bin/forge-store.cjs, forge-tickets/): any ticket whose run_id matches this run and whose status isn't done is reported open.

What `--enforce` does

For every mismatch, logs three already-registered events (no invented event_type names — see forge-dashboard/log-event.cjs KNOWN_EVENT_TYPES): lead_review_completed (the review finding) → rework_task_created (what's wrong + the required fix) → rework_assigned (back to the same agent).

For every open ticket belonging to the run: re-stores it with status: 'open' unchanged plus a note, and logs ticket_updated.

The task is now visibly back with the agent. The Lead must re-dispatch that agent with the open items listed in the rework event before treating the work as done again.

Honesty rule

forge-verify never marks anything done. It only reopens or flags — closing a task or ticket is always a real agent/human action, verified again by the next forge-verify pass. The dashboard shows the exact same mismatch (⚠) using the same taskStatus() logic, so the tool and the dashboard never disagree about what "done" means.

---name: forge-verify-2description: Run Forge's verify-loop — after an agent (or a work package) claims to be done, check whether that claim actually holds against events.jsonl and the ticket store, and send the task back to the agent when it doesn't. Use after every agent/work-package completion in a /forge run, and again at the end of the run before the final report.---# forge-verify — the verify-loopCloses the honesty gap between "an agent said it's done" and "the recorded events actually show it'sdone." Never trusts a completion claim on its own.## When to use (MANDATORY)- **After each agent/work-package completes** in a `/forge` run — before the Lead treats that agent's output as final.- **At the end of the run**, before writing the final report — a last honest check across every agent and every ticket the run touched.- Whenever the owner asks "did that agent actually finish?" or "check the tickets are really closed."## How to run```node .claude/forge-bin/forge-verify.cjs <run_id> # report only, exit 0/1node .claude/forge-bin/forge-verify.cjs <run_id> --enforce # report + send mismatches backnode .claude/forge-bin/forge-verify.cjs <run_id> --json # full machine-readable resultnode .claude/forge-bin/forge-verify.cjs <run_id> --root <projectRoot> # target a different project root```Exit code: 0 when there are no mismatches and no open tickets for the run; 1 otherwise — safe to gate ahook/CI step on it.## What it checks (mirrors the dashboard exactly)Reconstructs per-agent task state from `<run>/events.jsonl` the **same way** the Forge Control Centerdoes (`forge-dashboard/app.js` `BACKBONE` + `taskStatus()`): structural milestone events (`run_started`,`agent_completed`, `lead_review_completed`, …) are never counted as a "task"; every other eventattributed to an agent is a task, and a task is "done" only when its status genuinely resolves to done.An agent "claims completed" once it has logged `agent_completed` or `subagent_completed`. A **mismatch**is an agent that claims completed while some of its own tasks are still open, running, or failed.It also checks the ticket store (`forge-bin/forge-store.cjs`, `forge-tickets/`): any ticket whose`run_id` matches this run and whose `status` isn't `done` is reported **open**.## What `--enforce` doesFor every mismatch, logs three already-registered events (no invented event_type names — see`forge-dashboard/log-event.cjs` `KNOWN_EVENT_TYPES`):`lead_review_completed` (the review finding) → `rework_task_created` (what's wrong + the required fix) →`rework_assigned` (back to the same agent).For every open ticket belonging to the run: re-stores it with `status: 'open'` **unchanged** plus a note,and logs `ticket_updated`.The task is now visibly back with the agent. **The Lead must re-dispatch that agent** with the openitems listed in the rework event before treating the work as done again.## Honesty rule`forge-verify` **never marks anything done**. It only reopens or flags — closing a task or ticket isalways a real agent/human action, verified again by the next `forge-verify` pass. The dashboard showsthe exact same mismatch (⚠) using the same `taskStatus()` logic, so the tool and the dashboard neverdisagree about what "done" means.

Frequently asked questions