agentleFS
June74June74/agentic-workflow/skills/delivery/SKILL.md

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

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
  1. Distinctive:

    If the work could not be completed, return a delivery saying so, with the evidence of what blocked it.

    line 48

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.

RejectedAccepted
"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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.