ship
This skill contains shell command directives (!`command`) that may execute system commands. Review carefully before installing.
Ship Changes
Pre-loaded context
- Status: !
git status - Diff: !
git diff HEAD - Log: !
git log --oneline -10
Workflow
- Review all changes from status and diff
- Analyze recent commit style from log
- Check for quality check commands:
- If
package.jsonexists, check forlintandtestscripts - Run available checks in parallel:
npm run lint,npm test - If no package.json, skip quality checks
- If
- If checks fail: report errors, STOP — do not commit or push
- Group changed files by logical concern using atomic-commits grouping rules
- For each group: stage specific files by name, commit with HEREDOC format
- If all changes form one logical unit, stage files by name (never
git add -Aorgit add .) - Push:
git push(current branch) - Run
git statusafter to verify
Rules
- Stage files by name, never
git add -Aorgit add . - Group changes into atomic commits when they serve distinct purposes
- Generate message from changed files, match repo style
- Only run package manager commands if package.json exists with those scripts
- NEVER push if lint or tests fail
- NEVER force push (
-for--force) - NEVER skip hooks
- NEVER commit secrets
- Push to current branch only
Error Handling
- If lint or tests fail → report all errors, stop; do not commit or push
- If
git pushis rejected (non-fast-forward) → rungit pull --rebasethen retry push once - If pre-commit hook fails → fix reported issues, re-stage, create a NEW commit (never
--amend)
More from helderberto/skills
explain-code
Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?" Don't use for modifying code, fixing bugs, or generating new implementations.
45refactor-plan
Create structured refactoring plans. Use when user wants to plan a refactor, needs a refactoring strategy, or mentions breaking down large changes into small commits. Don't use for implementing code changes directly, small one-line fixes, or renaming a single variable.
44safe-repo
Check for sensitive data in repository. Use when user asks to "check for sensitive data", "/safe-repo", or wants to verify no company/credential data is in the repository. Don't use for general code review, adding .gitignore entries, or scanning non-git directories.
41lint
Run linting and formatting checks. Use when user asks to "run linter", "/lint", "check linting", "fix lint errors", or requests code linting/formatting. Don't use for running tests, type-checking only, or projects without a lint script in package.json.
40tdd
Guides test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants test-first development, or requests TDD workflow. Don't use for writing tests after implementation, adding tests to existing untested code, or one-off test fixes.
40commit
Create git commits following repository style. Use when user asks to "create a commit", "commit changes", "/commit", or requests committing code to git. Don't use for pushing code, creating pull requests, or reviewing changes.
38