ship

Ship Workflow

Execute these phases in order. Stop and report at any failure.

Context

• Branch: !git branch --show-current
• Remote tracking: !git rev-parse --abbrev-ref @{upstream} 2>/dev/null || echo "no upstream"
• Uncommitted changes: !git status --short | head -20
• Arguments: $ARGUMENTS

Phase 1: Status & Branch Detection

1. Run git status (never use -uall)
2. Run git diff --stat for unstaged changes summary
3. Run git diff --cached --stat for already-staged changes
4. Detect the repo's default branch: gh repo view --json defaultBranchRef -q .defaultBranchRef.name 2>/dev/null || echo "main"
5. Detect branch type:
   • Default branch (main, master, prod, or whatever the repo uses) → ask about branching (see below)
   • Feature branch: anything else → PR workflow

If there are no changes (working tree clean, nothing staged), stop and inform the user.

If on the default branch, ask user with AskUserQuestion:

• "Create a new feature branch" — auto-generate a descriptive branch name from the changes (e.g., fix/null-check-auth-middleware, feat/add-billing-export). Use the conventional commit type as prefix. Create with git checkout -b <name>.
• "Continue on current branch" — proceed with direct push workflow

If the user creates a new branch, the rest of the workflow follows the feature branch path (PR offered at the end).

Phase 2: Smart Staging

If there are unstaged changes:

1. List all changed and untracked files

2. Exclude secrets automatically: skip .env, credentials, tokens, private keys — warn the user about excluded files

3. Analyze change cohesion — determine if all changes relate to a single concern or multiple:

   Signals for mixed/unrelated changes:

   • Files in different modules or directories with no logical connection
   • Mix of change types (e.g., a bug fix in existing code + new feature files)
   • Changes that touch different domains (e.g., auth code + billing logic)
   • Diff content showing unrelated modifications (e.g., a typo fix + a refactor)