Deliver Work

Take finished work into a commit, a pushed or merged branch, a pull request, a release or production, only as far as the user said yes.

The Rules are binding; if one cannot be met, stop and say why. Everything else is judgment: adapt it when another choice serves its goal better.

Routes

Start every route with delivery-state (node <deliver-work-directory>/scripts/delivery-state.mjs): branch, upstream counts from local refs, staged, unstaged and untracked counts, a Git operation in progress, every worktree with the one holding this session's directory flagged, the latest tag, the version and the changelog's Unreleased entries. It reads only; what needs the network it reports unavailable. With --task <task folder> --base <ref> it also prints Review Work's Review: line for HEAD, which The Review Check below reads.

A request spanning routes, such as "commit and push": take them in order, each within its own yes, and stop at the first that fails.

Rules

• Merging, a pull request, deleting or discarding a branch, worktree or uncommitted work, deploying, and every exposure stage need their own yes, like commit, push and release. Loading this skill, a readiness question or an approved plan gives none, and one route's success never authorizes the next.
• Never use --amend, --allow-empty, --no-verify, a force push, a history rewrite, a moved release tag or an overwritten published version unless the user asked for that exact action; never bypass or blindly retry a failing hook or check.
• Never stage or publish Working Records (.freeflow/tasks/**, or a Freeflow store's task folders), secrets, credentials, private keys, local environment files or unexplained sensitive content. Only Track Work's script syncs the Freeflow store, and only to the user's own private remote.
• Never absorb or unstage pre-existing staged changes, or remove a worktree, checkout or other state you did not create. Never run a destructive reset, clean, branch or remote deletion, worktree removal or force push merely to produce a clean status.
• After a commit, push, publication or deployment step fails or loses its acknowledgement, inspect what changed before retrying, and stop while it stays unknown; a network error does not mean nothing happened.

The Review Check

Goal: work crosses its review unit only with a review on record for the commit that crosses it.

Before the step the user's review.unit names (opening a pull request by default; a push, a commit, or the Return under agreement), read delivery-state's Review: line, Review Work's review-status. On record for the head: go on. None: run the plan's review first, as Review Work's The Review Gate says, or under manual propose it with its plan and cost and wait for a yes. A stale line names the diff-only re-review that covers the commits since. Until Freeflow's gates enforce it, this check is yours: nothing in the host stops the step without it.

Commit

Goal: one commit that holds exactly the supported state.

1. Boundary. The user asked for this commit, or the work agreement they gave covers it, such as a commit at a return point they agreed; a Working Record can carry that agreement, not create it. Fresh checks support the state, or the user asked to preserve incomplete work; a review they selected is done, its findings settled.
2. Inspect before touching the index: commit-state lists every staged, unstaged and untracked path as yours, pre-existing or unknown (from a snapshot taken before your first edit, or --mine <path>), with partly staged files, sensitive-looking paths and Working Records flagged; then read git diff and git diff --cached. Staged does not mean yours. If the second Routes row matches, read commit now.
3. Stage only what the claim needs: explicit paths or hunks, with the tests, docs and generated output it requires; stage broadly only when every changed path was inspected and belongs. Then git diff --cached --check: conflict markers or whitespace damage stop the commit; fix them in the content they belong to, never edit content just to silence the check.
4. Message in the repository's style; otherwise a short imperative subject naming what this commit holds, and a body only for what the diff cannot show: why, trade-offs, residual risk, why incomplete work is kept. Invent no trailers.
5. Check git show --stat --oneline HEAD and git status --short --branch: the claimed contents, nothing unexpected left.
6. Record the commit on the current Slice, as a one-line result naming its SHA, through Track Work, when a Working Record exists.

Rules for a commit:

• Claim no more than the checks and selected review support. A preservation commit the user asked for may hold incomplete or failing work: say so, and do not take it as leave to cross what is unresolved.
• A commit is never a Slice of its own; after it, stage no leftovers and begin no other Slice.

Other Owners

A choice that is the user's goes to Discuss Work, with the supported routes as options; what a check supports, to Verify Work; a failure without a known cause, to Execute Work's diagnose; a selected review not yet run, reported for Review Work.

Stop

Stop and return the smallest blocking fact when:

• what a route's yes covers is unclear;
• live state differs from what was verified, reviewed or approved: changes, source commit, version, artifact, configuration or target;
• required evidence, a selected review, or the review the unit needs (The Review Check) is missing;
• a destination is unclear: remote, branch, base, pull-request target, registry, channel or environment;
• a conflict needs more than a mechanical resolution of both sides' settled intended behavior, such as a behavior, source-of-truth or owner decision; never end a conflict by taking ours or theirs.

Report

End with the lines that apply:

Route:      <route and stage, and what the yes covered>
Identity:   <SHA and subject, branch and remote, pull-request URL, version and tag, artifact and target>
Evidence:   <each check on the final state and what it shows; the selected review's outcome>
Not shown:  <what this does not establish (pushed is not merged, merged not released, a prepared release not published, published not deployed); what went unverified>
Remaining:  <unpushed or uncommitted work, pending CI or review, observation windows left, temporary machinery with its owner and cleanup, partial failures and recovery>
Next:       <the next route as a question, and whose call it is>