deliver-spec
Skill41 starsChanged 15 days agoMITView on GitHub
Deliver a finished spec: commit as 'feat: … ({id})' through the gate, read its verdict, push, open the PR. Triggers after apply-spec, or on 'deliver the spec', 'ship it', 'open the PR'.
- Commits and pushes
2 other projects use a version of this.
Adopted by
Most recently taken up by
- siarhei-belavus/agent-smitttheir own version, first seen Nov 8, 2026
- chrisbanes/skillstheir own version, first seen Jun 18, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- chrisbanes/skills★ 1.1ksame name
- siarhei-belavus/agent-smitt★ 4same 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 repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- apply-specSkill
- bootstrap-projectSkill
- create-specSkill
- deliver-seriesSkill
- log-decisionSkill
- review-specSkill
- spec-first-workflowSkill
- update-projectSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 20
If gh auth status fails, stop before pushing and tell the user: gh must be installed and authenticated to open the pull request.
- Very specific: line 33
Keep ({id}) exactly: the id in parentheses is what the commit gate keys on.
- Distinctive: line 66
Write the body from the spec, in this order:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Deliver Spec
The one owner of a spec's commit. Run it in the spec's worktree (branch spec/{id}) once apply-spec has verified the done criteria. Stop at the first failure and report it; never push past one.
1. Check the preconditions
git branch --show-current # must be spec/{id}
gh auth status # must succeedA phase/{id} branch cut under 2.4 is accepted: if it still carries .{project}/phases/, run update-project's scripts/migrate-specs-layout.py on it and commit first; push and open the PR on phase/{id} (until the script is removed).
If gh auth status fails, stop before pushing and tell the user: gh must be installed and authenticated to open the pull request.
2. Commit through the gate
Stage the spec's work: code, tests, the spec now in specs/done/, decisions/{id}.yaml, the context.yaml entry. Note HEAD, then commit once, with a literal -m:
git add -A
git status --short # nothing unrelated may ride along
head=$(git rev-parse --short HEAD)
git commit -m "feat: {short description} ({id})"Keep ({id}) exactly: the id in parentheses is what the commit gate keys on. Never pipe the commit and never build the message with $(…) or -F -; the gate cannot read those and lets the commit through unchecked.
With gate: git the stages run inside this Bash call, in the commit-msg hook: give the call a timeout of 600000 ms. The hook's own deadline is 570 s, so a slow suite blocks with a ledger line instead of being cut off.
The plugin's gate runs every context's verify: stages at this commit, once. If it blocks, the commit did not happen: fix the cause and commit again. Never bypass it.
3. Read the verdict
The gate writes one line per spec commit to spec-first-gate.log in the git common directory, shared by all worktrees. Read the newest line for this spec, this tree and the HEAD you noted:
log="$(git rev-parse --path-format=absolute --git-common-dir)/spec-first-gate.log"
awk -F'\t' -v id="{id}" -v tree="$(git rev-parse --show-toplevel)" -v head="$head" \
'$3 == id && $4 == tree && $5 == head' "$log" | tail -1Fields: time, verdict, spec, tree, parent, detail.
- passed: the verify stages ran and were green. Go on. With
gate: gitthe line comes from the commit-msg hook; it counts the same. - not-gated with
gate: project: the project's own gate checked the commit. The commit exists, so it passed there. Go on, and say in the PR body that the project's gate checked it. - not-gated with any other detail, or no line at all: no gate checked this commit (hooks disabled, the hook timed out or could not start, PyYAML missing, no verify stages declared). Run the stages yourself now, as below. On a fix,
git commit --amend --no-edit; the amend is gated again. - blocked: the commit did not happen. Fix the cause and go back to step 2.
Running the stages by hand: read verify: from every .{project}/contexts/*/context.yaml, each {label, command, when_present?}, and run them in order from the repository root. when_present set and that path absent: skip the stage and say so, skipped {label}: {when_present} not present. A non-zero exit stops delivery: report the label, the command and the tail of its output. No stages anywhere: say "no verify stages declared" and go on.
4. Push and open the pull request
git push -u origin spec/{id}
gh pr create --base {default-branch} --head spec/{id} \
--title "feat: {short description} ({id})" --body-file {body.md}Write the body from the spec, in this order:
- Goal: the spec's
goal:. - Done: each
done:criterion with how it was confirmed. - Tests: each
tests:entry, and who ran the verify stages: the plugin's gate (the ledger line), the project's gate, or this skill by hand (with any skipped stage and why). - Decisions: one line per entry of
decisions/{id}.yaml(chose / over). - Upgrade impact: the spec's
upgrade_impact:, or "nothing an operator must change". - Proven live: the spec's
proven_live:: what the tests prove, and what still needs a live check.
Report the PR URL to the user. Removing the worktree after merge is the user's call: git worktree remove {path}.
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.

