ship

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, bootstraps GitHub repositories with gh CLI when git or remotes are missing, and handles the full git workflow from staging to push.

missuo 4 Updated 2mo ago

Resources

GitHub

Install

npx skillscat add missuo/ship

Install via the SkillsCat registry.

SKILL.md

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:

Prepare repository - Initialize git and create a GitHub repo with gh if needed
Analyze git status - Check what files have been modified, added, or deleted
Infer commit type - Determine the appropriate type based on file changes and content
Generate commit message - Create a descriptive message following the format
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 0: Prepare Repository

Before analyzing changes, confirm the current directory is a usable git repository
with a push target:

Check whether the directory is inside a git repo:
- Run git rev-parse --is-inside-work-tree
- If it fails, run git init -b main
Check whether origin exists:
- Run git remote get-url origin
- If no origin exists, inspect git remote -v for any existing remote before
  creating a new one
If there is no remote repository configured, create one with GitHub CLI:
- Verify gh auth status; if not authenticated, ask the user to run gh auth login
- Infer the repo name from the current directory unless the user specified a name
- Infer a repo description and pass it with --description; do not leave the
  description empty by default
- Use AskUserQuestion to ask whether the GitHub repo should be private or
  public; present exactly those two choices unless the user already specified
  visibility
- Run gh repo create <repo-name> --source=. --remote=origin --description "<description>" --private
  or gh repo create <repo-name> --source=. --remote=origin --description "<description>" --public

Description inference order:

package.json description
pyproject.toml project.description
Cargo.toml package.description
SKILL.md frontmatter description
First useful README paragraph after the title
A concise generated description based on the repo name

Do not silently choose visibility. Always ask private vs public when creating a
GitHub repo. Use the inferred description without another prompt unless the user
asked for a custom description.

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

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

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

SAFETY CHECKS

Before committing:

Check for sensitive files - Do not commit: .env, credentials, private keys
Verify change scope - If changes are too large or mixed, suggest splitting
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:

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:

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:

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:

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:

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:

Summary of changes - What files were committed
Commit message - The full message used
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

ship

Resources

Install

Ship: Auto-generate Conventional Commits

Your Task

COMMIT MESSAGE FORMAT

Type Inference Rules

Scope Guidelines

PROCESS

Step 0: Prepare Repository

Step 1: Analyze Changes

Step 2: Determine Commit Type

Step 3: Determine Scope

Step 4: Generate Summary

Step 5: Optional Body

Step 6: Execute Git Commands

SAFETY CHECKS

When to Ask for Confirmation

EXAMPLES

Example 1: Simple Feature

Example 2: Bug Fix

Example 3: Documentation Update

Example 4: Breaking Change

Example 5: Multiple File Types

OUTPUT FORMAT

Categories

Install

Recommended Skills