agentleFS
holgerleichsenringholgerleichsenring/specification-first-agentic-development/skills/deliver-spec/SKILL.md

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

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. chrisbanes/skills★ 1.1ksame name
    2. 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.

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
  1. Very specific:

    If gh auth status fails, stop before pushing and tell the user: gh must be installed and authenticated to open the pull request.

    line 20
  2. Very specific:

    Keep ({id}) exactly: the id in parentheses is what the commit gate keys on.

    line 33
  3. Distinctive:

    Write the body from the spec, in this order:

    line 66

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

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

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 succeed

A 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 -1

Fields: time, verdict, spec, tree, parent, detail.

  • passed: the verify stages ran and were green. Go on. With gate: git the 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}.

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.