ship

name	ship
description	Ship workflow for committing and pushing changes. Use when user says "ship", "commit", "push", "deploy", or wants to finalize and submit their work. Handles build verification, test execution, brainstorm status check, changelog updates, and git operations.

Ship

A disciplined shipping workflow that ensures quality before code leaves the branch.

Shipping is not just git push. It's a checklist: build passes, tests pass, the brainstorm state is correct, the commit message is meaningful, and the code is pushed cleanly. This skill enforces that checklist every time.

When to Use

• User says "ship", "commit", "push", "let's ship it", "we're done"
• User wants to finalize current work and push to remote
• User asks to create a commit for recent changes

Pre-Ship Checklist

Before any commit, run through these checks in order. Stop at the first failure and report it to the user.

1. Brainstorm Status Check

Read .github/brainstorm.md if it exists:

Brainstorm Status	Ship Allowed?	Action
Planning	❌ No	Design not finalized — finish the brainstorm first
Questioning	❌ No	Open questions remain — answer them first
Ready	❌ No	Design confirmed but not started — begin implementing first
Implementing	⚠️ Partial	Allow shipping intermediate progress with a WIP commit
Completed	✅ Yes	Full ship allowed
Paused	❌ No	Work is paused — resume or complete first
No file	✅ Yes	No brainstorm needed (quick fix path)

For WIP commits during Implementing:

• Commit message must start with WIP: prefix
• Remind the user that the brainstorm is still in progress

2. Build Verification

Run the project build:

./gradlew build

• If build fails → stop and report errors
• If build succeeds → continue

3. Test Verification

Tests are run as part of the Gradle build. If any tests fail:

• Report which tests failed
• Do not proceed with commit

4. Uncommitted Changes Review

Run git status and git diff --stat to show the user what will be committed:

• List all modified, added, and deleted files
• Show a brief summary of changes
• Ask user to confirm the changes look correct

Commit Process

Commit Message Format

<type>: <concise description>

<optional body explaining what and why>

Co-authored-by: Copilot <[e-mail]>

Types:

• feat — new feature or capability
• fix — bug fix
• refactor — code restructuring without behavior change
• docs — documentation only
• chore — build, CI, dependencies
• test — adding or updating tests

Generate the commit message based on the actual changes. Present it to the user for approval before committing.

Git Operations

1. git add — stage relevant files (not blindly git add .; be intentional)
2. git commit — with the approved message
3. git push — push to the current branch's remote
4. Create or update PR:
   • If no PR exists for this branch → create one with gh pr create
   • If a PR already exists → push is sufficient, the PR updates automatically
   • PR title follows the commit message format; body summarizes the changes

If push fails due to diverged history, inform the user and suggest options (pull --rebase, force push, etc.) rather than acting unilaterally.

Post-Ship

After a successful ship:

1. If brainstorm status was Completed, note that the feature is shipped
2. Trigger the reflect skill — remind the user (or automatically initiate) a reflection on what was shipped
3. Report success with a summary: branch name, commit hash, files changed

Error Recovery

• Build failure: Show the error output, suggest fixes
• Test failure: Show failing tests, suggest investigation
• Merge conflict: Explain the conflict, do not auto-resolve
• Push rejection: Explain why (usually needs pull), suggest safe resolution
• Network issues: Retry once, then report

Quick Ship

For trivial changes (typos, config tweaks) where no brainstorm exists, the flow is streamlined:

1. Build check
2. Show changes
3. Commit and push

No brainstorm check needed, no WIP prefix — just a clean commit.