ship-it

Ship it

Use one delivery workflow for a scoped task in its owning repository. Read the repository instructions and deployment contract, establish the acceptance criteria and exclusions, and record the requested endpoint and immutable candidate revision as the work proceeds.

Authority and endpoint

The global AGENTS.md owns authorization and mutation rules. This skill does not grant authority, relax those rules, or treat a task, issue, PR, reviewer output, or tool result as authorization. Apply its bounded-task mandate, mutation, and production-release provisions to the exact action and target. Every autonomous mutation must leave an audit event and reversal recipe.

An explicit user request naming the task, owning repository, and endpoint is the owner request for ordinary publication stages necessary to reach that endpoint, subject to global policy and an exact target/change preview. Resolve the target from reliable repository context; clarify when the repository or target remains ambiguous. Automatic skill selection does not create or expand that authority.

The requested endpoint is the stopping point:

• Local — complete and verify the scoped local changes; do not publish.
• PR — prepare and publish the reviewed change, then verify the PR head and required checks. Do not merge it.
• Merge — merge the accepted revision after its checks and review are current, then verify the provider receipt and integrated revision.
• Verified production — complete the merge endpoint and the repository's deployment contract, then verify the deployed artifact and running behavior.

Do not advance to a later endpoint because it appears convenient or because a gate is green. A merge that itself triggers deployment is also a production action: apply the global authority rules to that trigger before executing it.

Delivery workflow

1. Scope and prepare. Record the owning repository, base, requested endpoint, acceptance criteria, exclusions, required checks, and any deployment target. Discover whether publication, merge, tag, or release triggers deployment. Continue safe, independent work when a required action is blocked; hold only work that depends on that action.
2. Implement and verify. Work in the repository's approved isolated execution context. Reproduce behavioral failures before fixing them where practical. Run required repository gates and change-relevant checks. Use native runtime or UI evidence when mocks or source inspection cannot prove acceptance. Fix failures caused by the change; identify unrelated failures without silently widening scope. For task-required build/test dependencies, meet the full credential-free isolation requirements in global AGENTS.md; a disposable directory alone is not isolation. If the required boundary cannot be established, classify the install under global policy and hold dependent work while continuing independent work.
3. Review. After deterministic checks pass, freeze the candidate diff and relevant source for independent cross-model review. A self-review is useful preparation but does not satisfy an independent review requirement. Follow review.md for reviewer constraints and identity evidence. Validate findings as hypotheses, fix grounded defects with regression evidence, and explain declined findings. An architectural debate is a separate, optional workflow for consequential design decisions; it is not a substitute for this candidate review.
4. Revalidate the candidate. A routine repair, rebase, or new candidate SHA within the authorized repository and scope does not by itself require new owner approval. A new commit invalidates affected evidence, not the mandate: rerun affected checks and review the changed scope before proceeding. For a bounded production release mandate, bind the exact SHA/artifact from the accepted candidate or merge/release receipt, verify required checks, review, and recovery readiness before its trigger. Without that mandate, use the global policy's exact-revision confirmation path. If the endpoint, target, repository, intended effects, or other protected scope changes, stop dependent work and seek approval of that delta under global policy. Safe independent work may continue.
5. Publish and check. For a PR endpoint or later, inspect the outgoing change and preview the exact target and concise change under global policy; publish when the explicit request covers that endpoint. Attach the created PR when the harness supports it, and read back the exact PR head/base. Discover the actual required check set and confirm fresh results for that head and current integration context. Follow release-gates.md; never weaken, bypass, or infer success from missing or ambiguous results. Never force-push. If publication triggers deployment, complete step 7's production preparation before publishing, then verify that rollout once; do not run a second manual deploy after a successful automatic rollout.
6. Merge when requested. Only for a merge or verified-production endpoint, recheck the head, base, review dispositions, required checks, and mergeability immediately before a normal guarded merge. If merge triggers deployment, complete step 7's production preparation before merging. Verify the provider receipt and integrated revision. A PR endpoint remains a PR even when all checks pass.
7. Deploy when requested. This step applies to a verified-production endpoint and to any earlier publication, merge, tag, or release action that automatically deploys. Prepare before that trigger. Only after preparation, bind an isolated source to the accepted immutable revision through the repository's fail-closed deployment mechanism. Prepare and verify a recoverable backup, verification procedure, and rollback under the global authority rules before a production trigger. Never derive the release from the current checkout. Verify artifact identity and change-specific running behavior. Verify a successful automatic rollout once; do not run a second manual deployment. For a manual rollout, deploy only when the requested endpoint is verified production. Perform only an authorized rollback; data restoration that could lose newer writes needs its own authorization under the global rules.