---
title: "done-is-a-claim"
description: "Evidence-first workflows for acceptance, verification, reviews, handoffs and delivery."
canonical: https://agentpluginsdirectory.com/plugins/done-is-a-claim
last-updated: 2026-10-11
---

# done-is-a-claim
Evidence-first workflows for acceptance, verification, reviews, handoffs and delivery.
- Slug: done-is-a-claim
- Publisher: Grit
- Repository: https://github.com/Grit-77/done-is-a-claim
- Manifest: plugin.json
- Version: 1.7.0
- License: Apache-2.0
- Category (editorial): other
- Skills: 15 (acceptance-design, checking-delivery, collecting-worker-results, debugging-with-evidence, evidence-freshness, executing-plans, implementing-with-tests, planning-changes, public-claims, reading-measurements, responding-to-review, resuming-work, reviewing-changes, using-done-is-a-claim, whose-red)
- MCP servers: 0
- Stars: 30
- Repository created: 2026-10-05
- Repository last pushed: 2026-10-11
- Publisher type: User
- Listing: https://agentpluginsdirectory.com/plugins/done-is-a-claim
- Schema: https://agent-plugins.org/schemas/1.0.0/plugin.schema.json

## What done-is-a-claim does, in the publisher's words

Your agent says "done". What would prove it?

An evidence-first development workflow for coding agents: understand → plan → implement → diagnose → review → verify → deliver. 15 connected skills, 18 incident-backed rules, and optional tools that keep the evidence attached to the work it tested. Small tasks take a shorter path.

Try the local example with Python 3.10+:

From the project README, punctuation lightly normalized. Full text: https://raw.githubusercontent.com/Grit-77/done-is-a-claim/HEAD/README.md

## Skills

- acceptance-design: Define executable acceptance for a bounded task before work or dispatch. Use when writing a worker brief, selecting success checks, or repairing an acceptance contract that cannot test the intended outcome.
- checking-delivery: Verify an artifact at its actual delivery destination and distinguish send attempts, acknowledgements, publication and consumer checks. Use when reporting a file, message, export or deployment as delivered; creating a local draft alone does not imply delivery.
- collecting-worker-results: Inspect a stopped worker's returned work and evidence before accepting it, retrying it or handing it to an integration owner. Use when a worker finishes, records disagree, or a green result has no visible change. Collection does not authorize merging.
- debugging-with-evidence: Diagnose unexpected behavior with a reproduction, competing explanations and experiments that separate them before fixing. Use for bugs, failed checks or repeated unsuccessful fixes; attribute branch failures only with suitable comparison evidence.
- evidence-freshness: Bind a check or action to the input snapshot it actually used. Use before relying on cached verification, consuming a reviewed batch, acting while inputs may change, or retrying an operation with an ambiguous result.
- executing-plans: Carry an actionable change plan through implementation, checks, review and an evidence-backed report. Use when executing several planned steps or integrating bounded worker returns, within existing authorization.
- implementing-with-tests: Implement runtime behavior changes and bug fixes with meaningful before-and-after checks, preserved behavior and relevant regression evidence. Use while editing code; prose-only changes do not need a failing test.
- planning-changes: Prepare a compact, executable plan for a substantial change with acceptance, file ownership, dependencies and expected observations. Use when several steps or collaborators need coordination; tiny clear edits can proceed directly.
- public-claims: Write and fact-check public copy so that every figure, credential, promise and command has a receipt, a source with a locator, a command that re-derives it, or the author's own words, and remove any claim without one instead of softening it. Use when drafting or reviewing a README, release notes, a…
- reading-measurements: Read a number without being fooled by it: an exit code, a passing result file, a test count, a list size, a control run, a red or a green. Use before reporting any figure, before turning a test run into a verdict, before acting on 'N items are broken', and whenever two outputs or two counts of the…
- responding-to-review: Resolve incoming code-review feedback against the current revision and user contract. Use to assess comments, implement authorized fixes, explain supported disagreement and verify item status; review does not authorize posting replies.
- resuming-work: Resume a saved task after a session, context or machine change by checking its checkpoint, artifacts and current ownership. Use when receiving unfinished work or reconciling a stop; ordinary uninterrupted edits do not need a handoff.
- reviewing-changes
- using-done-is-a-claim
- whose-red

Descriptions come from the frontmatter of each SKILL.md, punctuation lightly normalized.