Ship

Ship the complete nonignored current-branch snapshot end-to-end: commit and push it, open or update a ready PR, run /babysit-pr, merge when its normal gates are satisfied, then run /new-branch after the merge lands.

/ship means all nonignored local changes on the current branch. The shared checkout is the source of truth, so include concurrent-session changes in the same branch snapshot. The checkpoint helper excludes learnings.md, bridge/**, and data/**.

Non-Negotiable Shipping Invariant

/ship ships the complete nonignored branch snapshot, not a hand-selected subset of dirty paths. At the start of the flow, record the status and publish all current local changes with the checkpoint helper. If another session adds a path during the flow, include it in the next coherent snapshot; never revert, stash, or overwrite it.

Invoking /ship is explicit authorization to merge this PR once the merge gates below pass, unless the user says not to merge. Do not ask again just to merge a clean PR. Do not stop after creating the PR; the default /ship outcome is a merged PR and a fresh post-merge branch.

Branch-wide Push

A worktree is a valid publishing checkout. When /ship is authorized from a worktree, use that worktree's current branch and cwd for validation, commit, push, and PR creation or update. Do not copy its changes into the shared checkout; update the existing PR and do not create a second one.

corepack pnpm ship:push

The helper stages and commits the complete nonignored snapshot, excluding learnings.md, bridge/**, and data/**. Verify the push landed on the current branch and read the remote sha back.

Treat these as an immediate call to it: /ship, "ship our latest local changes", or "push up my local changes". Push the first coherent branch snapshot before long validation so CI and review can start, then publish later snapshots as local work arrives.

Deployment split

Merges to main trigger .github/workflows/deploy-beta-sites-prebuilt.yml, which builds in GitHub Actions and uploads prebuilt artifacts to the independent Netlify beta sites at beta.*.agent-native.com. Netlify Git-connected auto-builds are disabled, so do not wait for Netlify build queues or deploy-preview checks; verify the Actions run and its per-site smoke checks. Production promotion is a separate manual operation for other production sites. The normal /ship flow does not wait for or verify post-merge beta deployment; use /ship-and-monitor to verify beta, the docs production lane, and the release tail. The public docs site is the temporary exception: matching main changes trigger .github/workflows/deploy-docs-production.yml, which publishes www.agent-native.com from the exact commit and disables that site's Git-connected Netlify builds. There is no beta docs site today. The normal /ship flow must not imply an automatic production deploy for other sites. Critical fixes that must reach other production sites need an explicit manual promotion, followed by /ship-and-monitor when the promotion and release tail need verification.

Use .github/workflows/deploy-production-sites-prebuilt.yml or the targeted promote-netlify-deploy.yml workflow to promote a critical fix and let it manage Netlify lock transitions. Do not manually remove or clear a Netlify lock as a deployment step; clearing one is not the production promotion.

Latest-feedback handoff

When /review-latest-feedback has run before /ship, its sweep is a required ship input. Carry the sweep's start cursor, grouped reports, evidence links, and disposition table into the PR or ship recap. The handoff remains cross-app and cross-source: adding Design UI bugs to the eligible set must not drop Analytics, Dispatch, Calendar, Slides, Content, GitHub, Sentry, or any other previously identified candidate. Every actionable item must have an owning source seam and focused verification, with one explicit disposition: fixed, awaiting reporter clarification, already owned or duplicate, deferred or informational, external or non-repo-owned, or unavailable/unverified.

Honor the feedback ownership and reaction gates from /review-latest-feedback:

• Never add or duplicate 👀 on a Slack parent. If the latest readable parent already has an 👀 reaction from anyone, preserve that fact as an existing investigation marker, but do not treat it as a disposition or suppression signal. After classifying the parent, re-read the complete thread and, for an actionable in-scope item, require a verified disposition from the invoking Slack identity - Fixed, In progress, or Clarification needed; an eye-only or stale eye-only item remains actionable for that handoff check. For items routed to Sid or Alice, or classified as external, duplicate, deferred, or informational, honor that owning disposition and do not turn the eye into a merge blocker. If the reaction state is unavailable, record the item as unavailable/unverified and refresh the feedback thread instead of guessing.
• Concrete small UI or interaction bugs in the Design app are an additional in-scope category for this workflow and follow the same feedback handoff, verification, and merge gates as other repo-owned fixes. Do not narrow the ship ledger to Design when Design is added to a cross-app sweep. Route broad redesigns or subjective Design suggestions to Sid. All Content app feedback remains owned by Alice; keep those source links and ownership decisions in the ship ledger, but do not include them as this workflow's fixes, investigation, clarification requests, replies, dispatches, or merge blockers.

When deciding whether an awaiting clarification is already answered, treat the requested URL, error, screenshot, repro, run ID, or other evidence as present only when it is readable in the parent, a reply, or an accessible linked artifact. Keep a linked artifact that is present but inaccessible because of permissions, expiry, connector gaps, or another read failure separate from evidence that is absent. If that artifact is required to identify or verify the change, route the item back through the feedback workflow for a targeted request for access or a fresh/replacement link; do not suppress that request or ask again for contents already known to be in the inaccessible artifact. If the available evidence is enough without it, continue and record the limitation as unavailable/unverified in the ship ledger.

Before carrying any item forward from a prior handoff - fixed, in progress, awaiting clarification, already owned or duplicate, deferred or informational, external, or unavailable/unverified - always re-read the complete source thread and current handoff and reconcile them for new replies, reactions, linked evidence, resolution, or ownership signals. The handoff is a prior record, not the source of truth. After that refresh, if the invoking Slack identity, a legacy @agent-native message, or another participant already supplied the needed details, identified the cause, linked a fix, or said the issue is fixed, landed, or being fixed, do not reopen it as a clarification request or ask for duplicate information. Carry it as fixed pending verification, already owned, or in progress, and verify or follow up on that existing work. Only preserve an awaiting-clarification disposition when one specific reporter or product input is still missing after that check. Any eventual reporter-facing clarification must thank the person first and ask the question second; Clarification needed is an internal state, not an opening line.

There may be only one unanswered clarification request per feedback thread. If the existing handoff or complete source thread contains a question from this workflow or @agent-native, re-read both and determine whether the exact requested detail has been semantically answered or explicitly resolved anywhere in the thread. A partial or unrelated reply does not clear the request. If it remains unresolved, carry its timestamp forward as the sole pending request and do not add another question. Once it is answered or resolved, re-read the thread and try the fix first; ask one new question only for one specific, non-repeating detail that still blocks the fix.

Do not ship a feedback fix that is only a wording-specific rule or that lacks the evidence needed to identify its owner. Re-run or refresh the feedback sweep when the branch changes after triage or when new comments, Slack replies, GitHub review comments, or Sentry findings arrive. Treat an unavailable connector as unavailable - never as “nothing matched” - and preserve that gap in the recap.

The ship report and PR description must keep source-tested, built, and merged claims separate. A green test or PR does not prove that beta or production is live; deployment monitoring belongs to /ship-now or /ship-and-monitor. Before merging, /babysit-pr must re-check that every actionable feedback or review item has a fix or a concise reply and that no new evidence has been left without a disposition. Items routed to Sid or Alice remain outside this workflow's ownership. External, duplicate, deferred, and informational items also follow their recorded disposition rather than blocking this workflow. A parent marked with 👀 is not thereby complete or non-actionable: preserve the reaction without duplicating it, and for actionable in-scope items do not merge while an eye-only or stale eye-only item lacks a verified disposition from the invoking Slack identity.

Worktree and branch setup

A detached HEAD is a valid shipping context. Codex and platform-managed worktrees may intentionally start detached, and /ship explicitly authorizes creating a shipping branch in that worktree before committing or pushing. Do not stop or ask for confirmation just because git branch --show-current is empty.

If this worktree is detached:

1. Inspect git worktree list --porcelain and existing changes-* refs.
2. Create an unused changes-N branch (N at least 50) at the current HEAD in this worktree, for example git switch -c changes-N. Never attach or switch a branch that is checked out by another worktree, use main, overwrite an existing ref, or move another worktree.
3. Continue the normal ship flow on that new branch.

This is the one pre-PR branch operation that /ship authorizes for a detached worktree. Do not reset, rebase, stash, or force-push. If already on a named branch, stay on it.

Steps

1. Stay in the current worktree and branch: if already on a named branch, never create, switch, rebase, reset, or stash before opening the PR. If the worktree is detached, follow the Worktree and branch setup section and create the shipping branch before opening the PR. This repo uses shared/platform-managed worktrees; ship the branch belonging to this worktree.

2. Check local changes: run git status --short and git diff --stat to establish the branch snapshot. Multiple agents may have added work; include those paths in the complete nonignored snapshot.

   Then confirm the base is current, before validating or pushing anything. A worktree can be created from a stale ref, and its local main ref is stale too, so git log main..HEAD comes back empty and the branch reports itself current while being weeks behind. The fetch is required: without it the count reads a stale remote ref and returns 0, which is the same confidently-wrong clean answer this check exists to catch.

   git fetch origin main --quiet
   git rev-list --count HEAD..origin/main

   Non-zero means reapply the work onto current origin/main before pushing — shipping from a stale base conflicts with or reverts whatever landed in the gap. Measured 2026-08-18: four live Codex worktrees sat 1,144 commits behind origin/main while reporting themselves clean from the inside.

3. Validate enough to avoid obvious breakage: run focused tests for the changed area. Push the first safe slice before running pnpm run prep or another long validation. Run prep when it is practical, but if prep is slow, flaky, or contaminated by concurrent in-flight edits, do not stall shipment: record the exact failure, keep pushing stable slices, and let GitHub Actions be the validation gate that /babysit-pr monitors.

4. Publish the branch snapshot: run corepack pnpm ship:push to stage, commit, and push all nonignored current-branch work. Never add Co-Authored-By or other agent attribution.

   The first successful push is the review handoff point: open or update the ready PR immediately, before waiting on pnpm prep, a stability window, or additional concurrent work. Later commits update that same PR and let CI and review run in parallel with the rest of the ship workflow. Push each later coherent branch snapshot as soon as it is available.

5. Open or update a ready PR immediately after the first push: use the current branch. PRs are ready for review by default, not drafts. Do not put codex, [codex], or similar agent labels in the title/body.

   For every later safe slice, update this same PR immediately after pushing; do not create a second PR or wait for prep to finish before handing the slice to CI and review.

6. Babysit immediately: run /babysit-pr <number> and follow that skill’s tick loop exactly. Treat babysit-pr as the source of truth for how to watch the PR. Its Step 0 publishes the current nonignored branch snapshot, then checks mergeability, every unaddressed review comment by reply state, and CI. Keep going until the PR is either merged/closed or the user explicitly tells you to stop.

7. Merge when allowed: because /ship includes merge authorization, merge with gh pr merge <number> --squash --admin only after /babysit-pr’s merge requirements are simultaneously true for 10 consecutive minutes: clean working tree, no unpushed commits, GitHub Actions green, all review comments addressed/replied, and mergeable.

8. Create the next branch after merge: after the PR is merged and origin/main contains the merge commit, run /new-branch. Follow that skill’s preflight, stash gate, branch naming, and stash-reporting rules. This is the only branch movement in the ship flow.

9. Report: summarize the PR URL, merge result, new branch name, validation, and any feedback/CI fixes handled. Do not claim post-merge beta or production monitoring unless you ran /ship-now or /ship-and-monitor.

Important

• Multiple agents run concurrently. There will often be locally changed files you didn't generate. This is normal. Include those paths in the next complete branch snapshot. Don't revert or overwrite other agents' work; fix real bugs if CI or review feedback flags them.
• Never commit learnings.md or files in .gitignore.
• If feedback appears in inline comments or review bodies, every item needs a fix or a reply before merge.
• Treat /babysit-pr as the source of truth for CI/review monitoring cadence, comment handling, local-file push discipline, and merge gates. Update babysit-pr first if the watcher behavior changes.
• Treat /ship as complete after its merge and branch-rotation steps. Use /ship-now or /ship-and-monitor for post-merge beta/release monitoring and explicit manual production-promotion verification.
• Treat /new-branch as mandatory after a successful merge so the workspace is ready for the next task on fresh main.