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.

Review ownership

Every review and review gate in this workflow is an agentic technical review. The conductor arranges the required review, or performs an in-scope review itself where existing policy permits; it must not implicitly assign technical review to Magnus or stop at “ready for review” while agent review remains. Where existing policy permits self-review as a fallback, label it as such: it is never independent review, and independent cross-model requirements remain unchanged.

Agent review is evidence, not authorization. Magnus's explicit approval or decision remains distinct from review; agent review neither grants nor replaces that owner decision. Handoffs and final messages must not describe Magnus as the technical reviewer or imply that he must perform the review.

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.

Retry and unknown outcomes

Diagnose a failed check before retrying. Retry a demonstrated transient failure once. Further repair needs a new evidence-backed hypothesis. After three attempts without progress on the same condition, pause that branch and report the diagnosis and smallest missing decision or capability. This is a conductor diagnosis point, not automatically a new owner-approval request: resume within the mandate when new evidence supports a bounded hypothesis; apply global policy if the missing condition is authority or a scope change. Continue independent work. After an interrupted command or an unknown external outcome, reconcile provider state and receipts against the intended immutable revision before deciding whether to retry. Do not repeat publication, merge, or deployment merely because a response was lost.

Evidence and handoff

At each endpoint retain the smallest useful evidence in the repository's designated handoff: requested endpoint, candidate revision and scope, checks, review identity and dispositions, external receipts, and any pending blocker. On continuation, re-read live facts. A changed candidate invalidates affected check and review evidence. A changed target or sensitive action is handled under the global authorization rules. Do not mark later endpoints complete when only an earlier endpoint was reached.

For multiple independent tickets in one owning repository, read batch.md. It adds batching mechanics without changing this skill's endpoint or authority boundaries.