Ship

Commit, push, and optionally create or update a PR for the current staged changes.

Task Tracking

At the start, use TaskCreate to create a task for each phase:

1. Determine intent
2. Branch (if needed)
3. Stage unstaged changes
4. Run /commit-rules skill
5. Commit
6. Update PR (if requested)
7. Push (if requested)
8. Create PR (if requested)
9. Link changelog entries to the PR (if needed)

Step 1: Determine Intent

Detect the repository state:

• Default branch: gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
• Current branch name, and whether it tracks an upstream
• Whether a PR already exists for the current branch (gh pr view)

Sample the prevailing workflow from recent default-branch history (git log --first-parent origin/<default-branch> -n 30 --pretty=%s): judge whether changes mostly land through pull requests (merge-PR commits or (#N)-suffixed squash commits) or are committed directly to the default branch.

Output a one-line summary of the detected state as text. Then use AskUserQuestion to choose how to proceed, offering these options:

• Commit, push, and create/update the PR — say "create a PR" when no PR exists for the current branch and "update the PR" when one does; on the default branch, Step 2 creates a feature branch first
• Commit and push — commit, then push to the current branch's remote
• Commit only — commit the staged changes, do not push

Recommend the option that fits this repo by listing it first and labeling it (Recommended): when the current branch already has a PR, recommend updating it; otherwise follow the prevailing workflow — recommend the PR path for a PR-based history, or commit and push for a direct-commit history.

If the user declines (chooses the free-form "Other" option or asks to abort), leave the changes staged and do not commit.

Step 2: Branch (if Needed)

If the chosen option creates a PR and the current branch is the default branch:

1. Suggest a branch name based on the changes and use AskUserQuestion to confirm or adjust
2. Create and switch to the new branch: git checkout -b <branch-name>

Step 3: Check for Unstaged Changes

Run git status to check for unstaged changes. Stage by path the files that belong to the current changeset; this catches files modified by auto-formatters that were not re-staged. When one also carries unrelated changes, write git diff <file> to a patch file, back the unrelated changes out of it (delete their + lines and turn their - lines into context lines), and stage it with git apply --cached --recount <patch>.

Step 4: Run /commit-rules Skill

Run the /commit-rules skill to load commit message rules and technical constraints.

Step 5: Commit

Commit the already-staged changes (do not stage additional files) with a message following the loaded rules. Keep the branch Step 2 left in place and commit on it, including when that is the default branch.

If the commit fails due to a pre-commit hook (formatter, linter), fix the issues — or run the project's format/lint script to auto-fix — then re-stage by path the files the hook modified before retrying. Pre-commit hooks may modify files in the working tree without updating the staging area.

Step 6: Update PR (if Requested)

If the chosen option updates the PR, run the /update-pr skill.

Step 7: Push (if Requested)

If the chosen option includes pushing, push to the current branch's remote:

git push

Step 8: Create PR (if Requested)

If the chosen option creates a PR, run the /create-pr skill.

When /create-pr hands the body file over for editing instead of posting, report that path and that no PR was opened yet, and leave Step 9 pending until the PR is posted or cancelled.

Step 9: Link Changelog Entries to the PR (if Needed)

When Step 8 opened a PR, including one posted after the user edited its body, and this branch added Unreleased changelog entries that carry no PR reference while the changelog's earlier entries carry one, run the /changelog-rules skill and add to each of those entries the references it calls for with the new PR. Stage the changelog by path and commit it with a message following the commit rules Step 4 loaded, handling a pre-commit hook as Step 5 does, then push to the current branch's remote.

Then use the TaskList tool and proceed to any remaining task.

Rules

• Run the /commit-rules skill before every commit; do not commit without loading it first.
• Never stage or commit files containing secrets (.env, credentials, API keys). Warn if detected.
• Don't reference .turbo/ content (filenames, acceptance criteria, step numbers, headings) in branch names. .turbo/ is gitignored, so these references would be opaque to anyone reading without local copies.