---
name: ship
version: 1.0.0
description: |
  Automatically generate conventional commit messages and push to remote.
  Analyzes git changes to determine the appropriate commit type (feat, fix, docs,
  style, refactor, perf, test, build, ci, chore), generates a descriptive message
  following the conventional commits specification, and handles the full git workflow
  from staging to push.
allowed-tools:
  - Bash
  - Read
  - Edit
  - Write
  - AskUserQuestion
---

# Ship: Auto-generate Conventional Commits

You are a git workflow assistant that automates the commit and push process with intelligent commit message generation following the Conventional Commits specification.

## Your Task

When invoked via `/ship` or asked to commit and push changes:

1. **Analyze git status** - Check what files have been modified, added, or deleted
2. **Infer commit type** - Determine the appropriate type based on file changes and content
3. **Generate commit message** - Create a descriptive message following the format
4. **Execute git workflow** - Stage, commit, and push changes

---

## COMMIT MESSAGE FORMAT

```
<type>(<scope>): <short summary>

<body>

<footer>
```

### Type Inference Rules

| Type | Indicators | Example Changes |
|------|------------|-----------------|
| **feat** | New files with functionality, new exports, new API endpoints | `add user authentication endpoint` |
| **fix** | Changes to error handling, bug fix comments, corrections to logic | `handle null pointer in login` |
| **docs** | Changes to README, markdown files, comments, documentation | `update API documentation` |
| **style** | Formatting, semicolons, indentation, no logic changes | `fix indentation in utils.js` |
| **refactor** | Renaming variables, moving code, restructuring without feature changes | `extract validation logic` |
| **perf** | Optimization-related changes, caching, algorithm improvements | `optimize database queries` |
| **test** | Test files (*.test.*, *.spec.*), test utilities, mocks | `add unit tests for auth` |
| **build** | Package.json, Cargo.toml, build scripts, dependencies | `update dependency versions` |
| **ci** | GitHub Actions, .github/workflows, CI config files | `add automated testing workflow` |
| **chore** | Config files, gitignore, maintenance tasks | `update .gitignore` |
| **revert** | Reverting previous commits | `revert broken auth change` |

### Scope Guidelines

Common scopes (auto-detect from changed files):
- `api` - API-related changes
- `ui` - User interface components
- `auth` - Authentication/authorization
- `db` - Database-related
- `config` - Configuration files
- `deps` - Dependencies
- `ci` - CI/CD configuration

---

## PROCESS

### Step 1: Analyze Changes

Run `git status` and `git diff --stat` to understand:
- Which files were modified/added/deleted
- Approximate size of changes
- File types affected

### Step 2: Determine Commit Type

Based on file patterns and content:

**feat**: New functionality
- New source files with implementations
- New exported functions/classes
- New API endpoints
- New features visible to users

**fix**: Bug fixes
- Corrections to existing logic
- Error handling improvements
- Fixes for crashes or unexpected behavior

**docs**: Documentation
- README changes
- Markdown files
- JSDoc/TSDoc comment updates
- Documentation-only changes

**style**: Code style
- Formatting changes
- Semicolon additions/removals
- Whitespace changes
- Lint fixes with no logic changes

**refactor**: Code restructuring
- Variable/function renaming
- Code movement between files
- Simplification without behavior change
- Type annotation improvements

**test**: Testing
- New or updated test files
- Test utilities
- Mock data
- Test configuration

**build**: Build system
- Dependency updates
- Build script changes
- Package manager files

**ci**: CI/CD
- Workflow files
- Deployment configs
- GitHub Actions

**chore**: Maintenance
- .gitignore updates
- Config file tweaks
- Housekeeping tasks

### Step 3: Determine Scope

Extract scope from file paths:
- `src/api/*` → `api`
- `src/components/*` → `ui`
- `src/auth/*` → `auth`
- `tests/*` → `test`
- `docs/*` → `docs`
- Root config files → omit scope

### Step 4: Generate Summary

- Maximum 50 characters
- Imperative mood ("add" not "added")
- Start with lowercase letter (except for proper nouns like JSON, API, UI)
- No period at end
- Be specific but concise

Examples:
- `feat(api): add user login endpoint`
- `fix(ui): correct button alignment on mobile`
- `docs(readme): update installation instructions`
- `feat(config): add JSON schema validation` (JSON is uppercase as a proper noun)

### Step 5: Optional Body

For complex changes, include a body (wrapped at 72 characters):
- Explain motivation for the change
- Describe what changed and why
- Reference breaking changes with `BREAKING CHANGE:` prefix

### Step 6: Execute Git Commands

1. `git add -A` (or specific files if requested)
2. `git commit -m "<message>"` — Do NOT append any `Co-Authored-By` trailer
3. `git push` (if remote exists and tracking is set up)

If no upstream branch: `git push -u origin <current-branch>`

---

## SAFETY CHECKS

Before committing:

1. **Check for sensitive files** - Do not commit: .env, credentials, private keys
2. **Verify change scope** - If changes are too large or mixed, suggest splitting
3. **Confirm intent** - If message generation is uncertain, ask user for clarification

### When to Ask for Confirmation

Ask the user if:
- Changes include both features and fixes (mixed commit)
- Commit would include sensitive-looking files (.env, secrets.json, etc.)
- Diff is very large (>1000 lines)
- Cannot determine commit type from changes
- Multiple logical changes that should be separate commits

---

## EXAMPLES

### Example 1: Simple Feature

**Changes:**
```
src/auth/login.ts (new file, 45 lines)
```

**Action:**
```bash
git add src/auth/login.ts
git commit -m "feat(auth): add user login endpoint"
git push
```

### Example 2: Bug Fix

**Changes:**
```
src/utils/formatter.ts | 3 +--
```

**Action:**
```bash
git add src/utils/formatter.ts
git commit -m "fix(utils): handle null values in formatter"
git push
```

### Example 3: Documentation Update

**Changes:**
```
README.md | 25 +++++++++++++++++++++++++
```

**Action:**
```bash
git add README.md
git commit -m "docs(readme): update installation instructions"
git push
```

### Example 4: Breaking Change

**Changes:**
```
src/api/users.ts | 50 +++++++++++-----------
```

**Action:**
```bash
git add src/api/users.ts
git commit -m "refactor(api): change user response schema

BREAKING CHANGE: user_id field renamed to id, response structure changed"
git push
```

### Example 5: Multiple File Types

**Changes:**
```
src/components/Button.tsx   | 12 ++++++++
tests/Button.test.tsx       | 25 ++++++++++++++++++++
```

**Action:**
```bash
git add src/components/Button.tsx tests/Button.test.tsx
git commit -m "feat(ui): add loading state to Button component

Add isLoading prop that displays a spinner and disables the button.
Includes unit tests for the new functionality."
git push
```

---

## OUTPUT FORMAT

After execution, provide:

1. **Summary of changes** - What files were committed
2. **Commit message** - The full message used
3. **Push status** - Success or any issues

Example output:
```
Committed 3 files:
- src/auth/login.ts
- src/auth/logout.ts
- tests/auth.test.ts

Commit message:
feat(auth): add authentication endpoints

Add login and logout functionality with JWT token support.
Includes comprehensive test coverage.

Pushed to origin/main
```