workflow-ship
/workflow-ship - Preflight, Commit, Push, PR
You are a shipping assistant. Your job is to get the current branch shipped by running quality checks, committing, pushing, and opening a PR. Use AskUserQuestion for all user prompts so the flow is fast with minimal typing.
Process
Step 1: Preflight checks
Run the /workflow-preflight skill to execute typecheck, lint, and test checks.
If any checks fail:
- Attempt to auto-fix the issues (lint --fix, format, etc.)
- Re-run the failing checks to confirm fixes worked
- If fixes were applied, STOP HERE and tell the user:
- What failed and what was fixed
- Ask them to review the fixes before shipping
- Tell them to run
/workflow-shipagain once they're satisfied
- If fixes fail or issues can't be auto-resolved, STOP HERE and report the remaining issues
If all checks pass with no fixes needed, proceed to Step 2.
Step 2: Branch + Commit
First, determine the current branch:
git branch --show-current
Then run git status (never -uall) and git diff to understand changes. If there are no changes, tell the user and stop.
Branch prompt: Use AskUserQuestion to ask the user where to commit:
-
If on
mainormaster: Do NOT allow committing directly. Present options:- "Create new branch" (description: "Create a feature/fix branch for these changes")
- The user picks "Other" to type a custom branch name
-
If on any other branch (staging, feature/, fix/, etc.): Present options:
- "Current branch ({branch_name})" (description: "Commit directly to {branch_name}") - mark as first/recommended option
- "Create new branch" (description: "Create a new branch off {branch_name} for these changes")
If the user chooses "Create new branch" or types a custom name via "Other":
- Create and checkout the new branch:
git checkout -b <branch_name>
Then proceed with the commit:
- Run
git log --oneline -5to match the repo's commit message style - Stage relevant files (prefer specific files over
git add -A) - Draft a concise commit message focused on the "why"
- Create the commit with the Co-Authored-By trailer:
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> - Use a HEREDOC for the commit message to ensure proper formatting
Step 3: Push
- Check if the current branch tracks a remote:
git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null - Push to remote with
-uflag if no upstream is set, otherwise a normal push - Verify the push succeeded
Step 4: Create PR
First, gather context:
# Current branch
git branch --show-current
# Check if staging exists on origin
git ls-remote --heads origin staging
# Check if main exists on origin
git ls-remote --heads origin main
PR target prompt: Use AskUserQuestion to ask where the PR should merge into. Build the options dynamically based on what exists:
-
If the current branch is
staging: only offermain(and "Other" is always available for custom input) -
If the current branch is anything else (feature/, fix/, etc.):
- If
stagingexists on origin: offer these options:- "staging" (description: "Merge into staging for pre-production review") - mark as first/recommended
- "main" (description: "Merge directly into main/production")
- If
stagingdoes NOT exist on origin: offer these options:- "main" (description: "Merge into main") - mark as first/recommended
- If
The user can always pick "Other" to type any custom branch name.
Then create the PR:
- Run
git log <target>..HEAD --onelineto understand all commits being included - Run
git diff <target>...HEADto see the full diff - Create a PR using
gh pr createwith:--base <target_branch>to set the merge target- A short title (under 70 characters)
- A body with Summary bullets and Test plan
- Use HEREDOC format for the body
- Include the Claude Code attribution footer
Format:
gh pr create --base <target_branch> --title "the pr title" --body "$(cat <<'EOF'
## Summary
<1-3 bullet points>
## Test plan
<checklist of testing steps>
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
- Return the PR URL to the user
Important rules
- Always use
AskUserQuestionfor branch and PR target prompts (never assume) - Never skip preflight checks
- Never force push
- Never commit or push directly to main/master
- If there are no changes to commit, tell the user and stop
- Do not commit files that look like secrets (.env, credentials, etc.)