mcpField
S
ship

ship

github.com/helderbertoDevelopment1952 installsUpdated 4d ago
Repository

About ship

ship is a workflow skill for validating, committing, and pushing code changes. It runs code and sensitive-data checks before committing by default, then groups changes into commits and verifies the push.

Key features

  1. 01Pre-commit code validation
  2. 02Sensitive-data scan of diffs
  3. 03Group changes into atomic commits
  4. 04Push and verify branch status
  5. 05Optional fast mode with restrictions

Use cases

  1. 01Run checks before committing code
  2. 02Separate unrelated changes into commits
  3. 03Push a branch and confirm its status

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/helderberto/agent-skills --skill ship

After installing, type/shipin Claude Code to confirm it loaded.

Details

From the project README

Ship Changes

Ship runs a pre-launch gate before committing. By default: validate-code + safe-repo. The gate ensures nothing broken or unsafe leaves the working tree.

Arguments

  • --fast — skip the pre-launch gate. Only for hotfixes, disposable branches (spike/prototype/CI), or when the gate already passed manually this session. Never on main/release. State the reason in the commit body.

Workflow

Phase 1 — Pre-launch gate (skipped if --fast)
  1. Validate code: invoke the validate-code skill. Auto-fixes formatting, verifies types, runs tests.
    • If validate-code returns FAIL → report errors, STOP. Do not commit or push.
  2. Sensitive data scan: invoke the safe-repo skill against the staged + unstaged diff only (not the whole repo).
    • If sensitive data found → report findings, STOP. Do not commit or push.
Phase 2 — Commit
  1. Review all changes from status and diff
  2. Analyze recent commit style from log
  3. Group changed files by logical concern using commit grouping rules
  4. For each group: stage specific files by name, commit with HEREDOC format
  5. If all changes form one logical unit, stage files by name (never git add -A or git add .)
Phase 3 — Push
  1. Push: git push (current branch)
  2. Run git status after to verify

Rules

  • Pre-launch gate runs by default; only skip via --fast with a stated reason; never --fast on main/release branches
  • Group changes into atomic commits when they serve distinct purposes
  • NEVER force push (-f or --force)

Error Handling

  • If git push is rejected (non-fast-forward) → run git pull --rebase then retry push once
  • If pre-commit hook fails → fix reported issues, re-stage, create a NEW commit (never --amend)
  • If --fast is used → log "Pre-launch gate skipped via --fast" in agent output for traceability

Comments

Markdown supported