一键导入
ship
Create a versioned release with tag, push, and GitHub release. Use when the user says "ship", "release", "tag and release", "create release", "ship it".
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Create a versioned release with tag, push, and GitHub release. Use when the user says "ship", "release", "tag and release", "create release", "ship it".
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Audits agents, prompts, skills, knowledge, and documentation for gaps, inconsistencies, and improvement opportunities. Proposes changes for user approval. Triggers on "agent-audit", "audit agents", "review config", "what can we improve".
Use before any creative work or spec creation. Explores intent, challenges assumptions, and produces specs. Triggers on "brainstorm", "let's design", "spec out", "define requirements", "write a spec", "challenge this", "poke holes", "what am I missing".
Detects documentation drift after structural changes. Dispatches parallel specialist reviewers and auto-fixes. Triggers on "check my docs", "audit docs", "doc drift", "check doc drift", or auto from post-implementation when tracked categories change.
Automated post-implementation workflow. Triggers when the orchestrator receives DONE from an implementation subagent. Runs quality gate, doc staleness check, auto-review, and improvement capture.
Periodic codebase health check. Use when the user says "health check", "technical debt", "what needs attention", "codebase audit", "codebase health".
Takes a spec phase and generates an execution plan with parallel stages, agent routing, review gates, and verification criteria. Use before dispatching implementation work. Triggers on "plan execution", "generate execution plan", "how should we execute this", or internally when the orchestrator is about to implement a spec phase.
| name | ship |
| description | Create a versioned release with tag, push, and GitHub release. Use when the user says "ship", "release", "tag and release", "create release", "ship it". |
Tag, push, and create a GitHub release. On feature branches, creates a PR first. Orchestrator-handled - no delegation.
Announce at start: "Preparing release."
git branch --show-current # Must be on main
git status # Must be clean
git log --oneline -10
git describe --tags --abbrev=0 2>/dev/null || echo "No tags yet"
Hard stops:
If on a feature/* branch, switch to PR creation mode (Step 1.5). If on main, continue to Step 2.
Triggered when ship is called from a feature branch.
Delegate to the create-pr skill. It handles prerequisite checks, context gathering, PR composition, and creation.
After the PR is created, stop. Do not proceed to Step 2.
STOP here. Do not proceed to tagging or releasing.
From this point forward, all steps require being on
main.
git fetch origin --tags
git tag -l "v<VERSION>"
If tag exists - ABORT and suggest next available version.
Title format: v<VERSION> - <Short Title> (regular hyphen, never em dash).
If user provided version: use it. If not: auto-bump from commits since last tag:
feat: - minor (v0.1.0 - v0.2.0)fix:, docs:, chore:, refactor:, infra: - patchBREAKING CHANGE - majorv0.1.0Auto-generate short title from commit analysis if not provided.
grep "v<VERSION>" docs/reference/CHANGELOG.md
Do NOT auto-create CHANGELOG entries.
Read docs/reference/CHANGELOG.md for the version entry AND analyze commits.
GitHub release format:
## Summary
<One paragraph - what this release contains and why it matters.
Derived from CHANGELOG entry. No bullet lists here.>
## What's Included
### <Meaningful Category - e.g. "Multi-Agent Orchestrator", "Security">
- **Feature name** - what it does and why it matters
### <Another Category>
- **Item** - brief description
Full details: [CHANGELOG](docs/reference/CHANGELOG.md)
Rules:
## Summary is required - always a paragraph## Commits section - GitHub shows the diff automaticallyRelease Plan:
Version: v<VERSION>
Title: v<VERSION> - <Short Title>
Commits: <N> since <last-tag>
CHANGELOG: Entry found / Missing
Remote: origin
Release notes preview:
<full markdown preview>
Proceed? (waiting for confirmation)
Do NOT proceed until user confirms.
# Create annotated tag
git tag -a v<VERSION> -m "<tag annotation>"
# Push
git push origin main
git push origin v<VERSION>
# Verify tag on remote
git ls-remote origin refs/tags/v<VERSION>
# Create GitHub release
gh release create v<VERSION> \
--title "v<VERSION> - <Short Title>" \
--notes "<release notes>"
If push fails - ABORT before creating release.
After release succeeds, prune stale remote refs and check for merged feature branches:
git fetch --prune
git branch --merged main | grep 'feature/' | head -5
If merged feature branches exist, ask:
"Delete local branch feature/<name>?"
On confirmation:
git branch -d feature/<name>
Use -d (not -D) - git will refuse if the branch isn't fully merged. This is a safety net.
Note: remote branch is typically already deleted by GitHub's "Delete branch" button on merge. git fetch --prune cleans up the stale tracking ref. If the remote branch still exists, also run git push origin --delete feature/<name>.
Release complete:
Tag: v<VERSION>
Title: v<VERSION> - <Short Title>
Release: <URL>
CHANGELOG: docs/reference/CHANGELOG.md
Cleanup: feature/<name> deleted (local + remote) / skipped