delivery
Skill0 starsChanged 3 months agoMITView on GitHub
Use for every upward return from a team to the Scrum Master, and to judge whether a returned delivery is acceptable. Requires evidence per acceptance criterion rather than assertions of success.
7 other projects use a version of this.
Adopted by
Most recently taken up by
- pfangueiro/claude-code-agentstheir own version, first seen Nov 8, 2026
- TerryFYL/ai-research-armytheir own version, first seen Nov 8, 2026
- wheslleyrimar/BuildCLI-Agentstheir own version, first seen Oct 22, 2026
- rcelebrone/DotAgentstheir own version, first seen Oct 14, 2026
- hieuphung97/delytheir own version, first seen Sep 16, 2026
- gener8v/gener8v.claude-skillstheir own version, first seen Sep 15, 2026
Other versions7 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 7
- hieuphung97/dely★ 93same name
- rcelebrone/DotAgents★ 15same name
- TerryFYL/ai-research-army★ 9same name
- pfangueiro/claude-code-agents★ 7same name
- gener8v/gener8v.claude-skills★ 3same name
- wheslleyrimar/BuildCLI-Agents★ 3same name
- Xopoko/delivery★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository14 other files it gives its agents.
- capability-scanSkill
- conveneSkill
- decision-recordSkill
- escalateSkill
- flag-checkSkill
- haltSkill
- interface-contractSkill
- merge-guardSkill
- profile-bootstrapSkill
- roster-preflightSkill
- setback-checkSkill
- setback-logSkill
- stability-checkpointSkill
- work-orderSkill
The file
We split this skill into the rules it gives an agent
1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.
0
Common
Most of the 5 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 48
If the work could not be completed, return a delivery saying so, with the evidence of what blocked it.
“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Delivery
A delivery is the upward half of the work-order contract. Use
templates/delivery.md.
The one rule that matters
Every acceptance criterion is checked with EVIDENCE, not a claim.
| Rejected | Accepted |
| "Tests pass" | pytest tests/test_conflicts.py -q → 24 passed in 3.1s |
| "The layout is responsive" | screenshots at 375px and 1280px |
| "Endpoint returns 409 on conflict" | the actual request and response |
| "I verified this works" | what you ran, and what it printed |
A delivery whose criteria are asserted rather than evidenced is rejected and re-dispatched, not accepted with a note. Accepting one teaches the system that assertions are currency.
Verify at the right layer
Structural success is not functional success. A file that imports cleanly, a
document that is well-formed XML, an endpoint that returns 200 — none of these
prove the thing does what the requester needed. Check at the layer the requester
will actually use: open the file in its real viewer, click the button, call the
endpoint for real. See deliverable-acceptance-check and
verification-before-completion.
Required fields
- Artifacts — paths, PR links, tags, branch names. Concrete locations.
- Acceptance checklist — each criterion, its evidence, and pass/fail.
- Open risks — what you are uncertain about, what you did not test, what you noticed but did not fix. This section being empty is itself a signal worth distrusting.
- Out of scope — anything in the work order you did NOT do, and why. A partial delivery reported honestly is useful. A partial delivery reported as complete is a defect that surfaces at G3.
Failure is a valid delivery
If the work could not be completed, return a delivery saying so, with the evidence of what blocked it. Do not substitute adjacent work that was easier. The Scrum Master can re-scope; it cannot un-ship something built against the wrong goal.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

