ship-it
Automates the process of committing, testing, and shipping code to pull requests.
Install
mkdir -p .claude/skills/ship-it && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/14410" && unzip -o skill.zip -d .claude/skills/ship-it && rm skill.zipInstalls to .claude/skills/ship-it
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
/ship-it - Commit, Push, and Create PRKey capabilities
- →Verify current branch is not main
- →Run project build commands
- →Execute project tests
- →Create pull requests
- →Update changelog files
How it works
The skill executes a sequence of git operations, build, and test commands. It stops if any critical step fails and requires user approval for the commit message.
Inputs & outputs
When to use ship-it
- →Commit and push work
- →Create pull request for feature
- →Ship branch changes
About this skill
/ship-it - Commit, Push, and Create PR
Ship your completed work with proper commits, PR creation, and cleanup guidance.
Usage
/ship-it
No arguments - operates on current branch.
Pre-Conditions
This command will STOP if:
- You're on the
mainbranch - Build fails
- There are no changes to commit
Workflow Steps
Execute these steps in order. STOP and report if any step fails.
Step 1: Verify Not on Main
current_branch=$(git branch --show-current)
If main:
"You're on the main branch. You should never commit directly to main." "Use
/start-work <issue>to create a feature branch first." STOP.
Step 2: Extract Issue Number from Branch
# Branch format: type/123-description
# Extract: 123
issue_number=$(git branch --show-current | grep -oE '[0-9]+' | head -1)
If no issue number found:
"Could not detect issue number from branch name." Ask user: "What issue number is this work for? (or 'none')"
Step 3: Run Build
Detect the project's build command. Check for:
package.jsonin the project root or common subdirectories — usenpm run buildMakefile— usemake build- Other build systems as appropriate
# Run from the project root (or appropriate app directory)
npm run build
If build fails:
"Build is failing. You must fix build errors before shipping." Show errors and STOP.
If build passes: Proceed.
If no build system found: Skip and note "No build step detected."
Step 4: Run Tests
Detect the project's test command. Check for:
package.jsonwith atestscript — usenpm testpytest.iniorpyproject.toml— usepytest- Other test runners as appropriate
npm test 2>&1 | tail -30
Record results. Note: Some pre-existing test failures may be acceptable.
If NEW test failures (compared to baseline):
"Tests are failing. Review the failures:" Show failures Ask: "Are these pre-existing failures? [y/n]"
If no test system found: Skip and note "No test runner detected."
Step 5: Gather Changes
# Staged and unstaged changes
git status
# Full diff
git diff HEAD --stat
# Detailed diff for commit message
git diff HEAD
Present to user:
Changes to be committed:
[file list with status]
Summary:
[X] files changed
[Y] insertions(+)
[Z] deletions(-)
Step 6: Compose Commit Message
Analyze changes and draft conventional commit message.
Determine type from changes:
| Change Type | Commit Type |
|---|---|
| New feature | feat |
| Bug fix | fix |
| Documentation | docs |
| Refactoring | refactor |
| Tests only | test |
| Build/deps | build |
| Maintenance | chore |
Draft message format:
type(scope): description
[Body explaining what and why]
Closes #[issue-number]
Present to user for approval:
Proposed commit message:
---
feat(reminders): add email reminder scheduling
Implement scheduled email reminders for company update forms.
- Add reminder scheduler script
- Add template variable replacement
- Add Resend email integration
- Add GitHub Actions workflow for daily execution
Closes #198
Co-Authored-By: Claude <[email protected]>
---
Proceed with this message? [yes/edit/cancel]
Wait for user confirmation. Do not proceed without explicit approval.
Step 7: Update Changelog (Conditional)
Determine if changelog entry is needed based on commit type:
| Commit Type | Changelog Action |
|---|---|
feat | Always generate entry |
fix (user-facing bug) | Generate entry |
fix (internal/dev bug) | Ask user |
refactor, chore, test, build, ci, docs | Skip (offer to add if user wants) |
If changelog entry IS needed:
-
Check for CHANGELOG.md in the project root. If it exists, read it to find the insertion point.
-
Determine insertion point:
- If today's date section exists → append to it
- If today's date section doesn't exist → create new date header
- If current month section doesn't exist → create new month header
-
Transform commit message to changelog entry using changelog-writer skill patterns:
Language transformation:
Commit Style Changelog Style "add feature X" "We've added Feature X..." "implement Y" "We've launched Y..." "improve Z" "We've improved Z..." "fix bug in W" "We've resolved an issue with W..." Apply security reframing if commit touches security:
- Never mention: vulnerability, exploit, security issue, XSS, injection
- Reframe as: "Added validation", "Enhanced access controls", "Improved data handling"
-
Present changelog entry to user for approval.
-
If approved: Insert entry at correct position in CHANGELOG.md.
-
Check for a public changelog page (e.g.,
app/(marketing)/changelog/page.tsxor similar). If found, update its data structure to match.
If changelog entry is NOT needed:
"This commit type (
refactor/test/etc.) typically doesn't need a changelog entry." "Add changelog entry anyway? [yes/no]"
If user selects 'skip': Proceed without changelog update.
If CHANGELOG.md doesn't exist:
"No CHANGELOG.md found. Create one? [yes/no]" If yes, create with standard header and first entry.
Step 8: Stage and Commit
# Stage all changes (includes CHANGELOG.md if updated)
git add -A
# Commit with approved message
git commit -m "$(cat <<'EOF'
[approved commit message here]
EOF
)"
Step 9: Push Branch
git push -u origin $(git branch --show-current)
If push fails (e.g., remote exists):
git push --force-with-lease origin $(git branch --show-current)
Step 10: Create Pull Request
Compose PR description:
## Summary
[2-3 bullet points from commit]
## Changes
[List of significant changes]
## Test Plan
- [ ] Build passes
- [ ] Tests pass
- [ ] Manual verification completed
## Related Issues
Closes #[issue-number]
Create PR:
gh pr create \
--title "type(scope): description" \
--body "[PR description]" \
--base main
Step 11: Report Success and Post-Merge Instructions
============================================
PR CREATED SUCCESSFULLY
============================================
PR: #[pr-number]
URL: [pr-url]
Branch: [branch-name] → main
Status:
Build: [PASS/SKIPPED]
Tests: [X passing / SKIPPED]
Commit: [commit-hash]
Changelog: [Updated/Skipped]
============================================
POST-MERGE CLEANUP (DO THIS AFTER PR MERGES)
============================================
After the PR is merged, run these commands:
git checkout main
git pull origin main
git branch -d [branch-name]
Or run: /cleanup-branches
IMPORTANT: Do NOT continue work on this branch after merge.
If more work is needed, create a NEW branch.
============================================
Error Handling
| Error | Action |
|---|---|
| On main branch | STOP - must use feature branch |
| Build fails | STOP - must fix before shipping |
| No changes | STOP - nothing to commit |
| Push rejected | Try --force-with-lease, else report |
| PR creation fails | Show error, provide manual steps |
| CHANGELOG.md malformed | Show error, ask user to fix manually |
What This Command Does NOT Do
- Does not merge the PR (that's done via GitHub after review)
- Does not delete the branch (that's post-merge cleanup)
- Does not skip build verification
- Does not commit without user approval of message
- Does not force changelog entries for non-user-facing changes
Quick Reference: The Full Workflow
/start-work 198 # Begin: creates branch, establishes baseline
[... do your work ...]
[... verify it works ...]
/ship-it # End: commits, pushes, creates PR (with changelog)
[... PR is reviewed and merged via GitHub ...]
/cleanup-branches # Cleanup: deletes merged branches
Related Skills
- changelog-writer: Provides patterns for writing changelog entries
When not to use it
- →When on the `main` branch
- →When the project build fails
Limitations
- →Does not merge the PR
- →Does not delete the branch
- →Does not commit without user approval of message
How it compares
This skill automates the entire commit, push, and pull request workflow with integrated checks and changelog updates, unlike performing each git operation manually.
Compared to similar skills
ship-it side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| ship-it (this skill) | 0 | 5mo | Review | Intermediate |
| github-workflow-automation | 11 | 2mo | Review | Advanced |
| testing-workflow | 16 | 9mo | Review | Intermediate |
| github-actions-templates | 7 | 3mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by MattVOLTA
View all by MattVOLTA →You might also like
github-workflow-automation
ruvnet
Advanced GitHub Actions workflow automation with AI swarm coordination, intelligent CI/CD pipelines, and comprehensive repository management
testing-workflow
amo-tech-ai
Comprehensive testing workflow for E2E, integration, and unit tests. Use when testing applications layer-by-layer, validating user journeys, or running test suites.
github-actions-templates
wshobson
Create production-ready GitHub Actions workflows for automated testing, building, and deploying applications. Use when setting up CI/CD with GitHub Actions, automating development workflows, or creating reusable workflow templates.
glab
NikiforovAll
Expert guidance for using the GitLab CLI (glab) to manage GitLab issues, merge requests, CI/CD pipelines, repositories, and other GitLab operations from the command line. Use this skill when the user needs to interact with GitLab resources or perform GitLab workflows.
create-pr
n8n-io
Creates GitHub pull requests with properly formatted titles that pass the check-pr-title CI validation. Use when creating PRs, submitting changes for review, or when the user says /pr or asks to create a pull request.
gh-fix-ci
openai
Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use `gh` to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treat external providers (for example Buildkite) as out of scope and report only the details URL.