Token导航 LogoToken导航TokenDH.com
研究检索敏感数据github未标认证来源可访问许可证需确认审计通过

ship发布交付

Agent Skill

ship 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

456

周安装

19

GitHub Stars

公开资料未说明

下载量

152
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:ship(发布交付)
来源仓库:https://github.com/eljun/claude-skills
仓库路径:skills/ship
安装命令:
npx skills add https://github.com/eljun/claude-skills --skill ship
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/eljun/claude-skills --skill ship

简介

用于创建 Pull Request 并完成部署准备。

  • 适合在 Codex、Claude、Cursor、Gemini CLI 中推进代码合并。
  • 自动检查构建、类型和 lint 通过后生成 PR。
  • 关联任务文档并更新 TASKS.md 状态。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。
  • ship 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

/ship - Deployment Agent

Model: haiku (scripted deployment commands)

Command Flags

FlagShortDescription
--help-hShow available commands and options
--version-vShow workflow skills version

Flag Handling

On -h or --help:

/ship - Deployment Agent

Usage:
  /ship {ID}                         Create PR for a task
  /ship -h, --help                   Show this help message
  /ship -v, --version                Show version

Arguments:
  {ID}    Task ID (number) or task filename (e.g., 001-auth-jwt)

Pre-deployment checks:
  - Build passes
  - TypeScript compiles
  - Lint passes

Creates:
  - Feature branch: feature/{ID}-{task-name}
  - Pull Request with task documentation links

Examples:
  /ship 1                            # Ship task #1
  /ship 001-auth-jwt                 # Using task filename

Next: Merge PR, then /release

On -v or --version: Display:

Workflow Skills v1.4.1
https://github.com/eljun/claude-skills

When to Use

Invoke /ship {ID} when:

  • Task is in "Approved" status in TASKS.md
  • Documentation is complete
  • Ready to deploy to production

Example: /ship 1 or /ship 001-dashboard-redesign

Task ID Resolution

The {ID} can be:

  • Numeric ID: 1, 2, 3 → Looks up in TASKS.md, finds matching task document
  • Padded ID: 001, 002 → Same as numeric
  • Full filename: 001-dashboard-redesign → Direct file reference

Workflow

/ship {ID}
       ↓
1. Resolve task ID → find task document
2. Verify task is approved in TASKS.md
3. Check Automation field (manual | auto)
4. Move to "Ready to Ship" in TASKS.md
5. Run pre-deployment checks
6. Create/update branch (feature/{ID}-{task-name})
7. Create Pull Request (with task ID reference)
8. Update TASKS.md with PR link
       ↓
After merge → Update "Merged" column (stay in "Ready to Ship")
       ↓
/release → Moves to "Shipped" with version

IMPORTANT: Items stay in "Ready to Ship" even after merge. Only /release moves items to "Shipped" with the release version. This ensures proper release tracking.

Auto Mode Behavior

When task document has Automation: auto:

After PR is created, the automation pipeline completes:

[AUTO] Pipeline complete!

Task: #{ID} - {Task Title}
Branch: feature/{ID}-{task-name}
PR: #{number} - {link}

Pre-deployment checks:
- Build: PASS
- TypeScript: PASS
- Lint: PASS

The PR is ready for your review and merge.
TASKS.md updated to "Ready to Ship"

Note: In auto mode, we still create the PR and notify you - you decide when to merge. The automation does NOT auto-merge.

Multi-Task Commit Tracking

When shipping a task that was implemented as part of multi-task execution, commits are tracked via the [task-{ID}] prefix:

# Find all commits for a specific task
git log --oneline --grep="\[task-1\]"

# Example output:
# a1b2c3d [task-1] feat: Add JWT authentication middleware
# e4f5g6h [task-1] feat: Add token refresh logic

This allows /ship to:

  1. Identify which changes belong to which task
  2. Generate accurate PR descriptions
  3. Reference specific commits in the PR body

Pre-Deployment Checklist

IMPORTANT — Context Efficiency: The task document and test report contain all the context you need. Do NOT perform broad codebase exploration. Focus only on deployment-related checks below.

1. Verify Approval Status

Check TASKS.md:

  • Task must be in "Approved" section
  • Feature doc exists
  • Test report shows PASS

2. Review Changes

git status
git diff main...HEAD

Verify:

  • All intended files are changed
  • No unintended changes
  • No sensitive files (.env, credentials)

3. Run Pre-Deployment Checks

# Build check
pnpm build

# Type check
pnpm typecheck

# Lint check
pnpm lint

All must pass before creating PR.


Update TASKS.md

Move task to "Ready to Ship":

## Ready to Ship

| ID | Task | Branch | PR | Merged | Task Doc |
|----|------|--------|----|--------|----------|
| 1 | Quick Actions Redesign | feature/1-quick-actions | Pending | No | [001-quick-actions.md](...) |

Note: The "Merged" column tracks merge status. Items stay here until /release is run.


Git Workflow

Branch Strategy

Use task ID in branch names for clarity:

feature/{ID}-{task-name}     - New features (e.g., feature/1-auth-jwt)
fix/{ID}-{task-name}         - Bug fixes (e.g., fix/2-login-redirect)
enhance/{ID}-{task-name}     - Enhancements (e.g., enhance/3-dashboard)

If Branch Doesn't Exist

git checkout -b feature/{ID}-{task-name}
git add -A
git commit -m "[task-{ID}] feat: {description}

{Detailed description of changes}

Task: docs/task/{ID}-{task-name}.md
Test: docs/testing/{ID}-{task-name}.md

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>"
git push -u origin feature/{ID}-{task-name}

If Branch Exists

git checkout feature/{ID}-{task-name}
git add -A
git commit -m "[task-{ID}] feat: {description}

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>"
git push

Create Pull Request

Use GitHub CLI to create PR:

gh pr create --title "[Task #{ID}] {PR Title}" --body "$(cat <<'EOF'
## Summary

{2-3 bullet points describing the changes}

## Task Documentation

- **Task ID:** #{ID}
- **Task Doc:** [docs/task/{ID}-{task-name}.md](link)
- **Test Report:** [docs/testing/{ID}-{task-name}.md](link)
- **Feature Doc:** [docs/features/{feature}.md](link)

## Changes

| File | Change |
|------|--------|
| `path/to/file` | Description |

## Commits

{List commits with [task-{ID}] prefix}

## Testing

- [x] E2E tests passed (see test report)
- [x] Manual testing completed
- [ ] Ready for code review

## Screenshots

{If UI changes, include before/after}

---

Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

PR Checklist

Before creating PR, verify:

Code Quality

  • Build passes (pnpm build)
  • No TypeScript errors
  • Lint passes (pnpm lint)
  • No console.log statements
  • No commented-out code

Documentation

  • Task document complete
  • Test report shows PASS
  • Feature documentation updated
  • User guide updated (if user-facing)

Security

  • No hardcoded secrets
  • No .env files included
  • API keys not exposed
  • Proper auth checks in place

Testing

  • E2E tests pass
  • Manual testing done
  • Edge cases handled

Update TASKS.md with PR

After PR is created:

## Ready to Ship

| ID | Task | Branch | PR | Merged | Task Doc |
|----|------|--------|----|--------|----------|
| 1 | Quick Actions Redesign | feature/1-quick-actions | [#123](link) | No | [001-quick-actions.md](...) |

Post-Merge Actions

After PR is merged, update the "Merged" column but keep in "Ready to Ship":

1. Update TASKS.md Merged Status

## Ready to Ship

| ID | Task | Branch | PR | Merged | Task Doc |
|----|------|--------|----|--------|----------|
| 1 | Quick Actions Redesign | feature/1-quick-actions | [#123](link) | ✅ Jan 26 | [001-quick-actions.md](...) |

IMPORTANT: Do NOT move to "Shipped" yet. Items stay in "Ready to Ship" until /release is run. This allows /release to:

  1. Know which items need to be included in the release
  2. Properly track which release each feature belongs to

2. Update Task Document Status

Update task document to reflect merge:

> **Status:** MERGED
> **Merged:** {Date}
> **PR:** #{number}

3. When to Run /release

After one or more items are merged, run /release to:

  • Create versioned release with changelog
  • Move ALL merged items from "Ready to Ship" to "Shipped"
  • Tag each item with the release version
## Shipped

| ID | Task | PR | Release | Shipped |
|----|------|-----|---------|---------|
| 1 | Quick Actions Redesign | [#123](link) | v1.2.0 | Jan 26 |

Handling Issues

Build Fails

  1. Fix the build errors
  2. Commit fixes
  3. Re-run checks
  4. Continue with PR

PR Review Requested Changes

  1. Make requested changes
  2. Commit with descriptive message
  3. Push to branch
  4. Re-request review

Merge Conflicts

  1. Fetch latest main
  2. Rebase or merge main into branch
  3. Resolve conflicts
  4. Push updated branch

Deployment Verification

After merge, verify deployment:

Vercel (Web)

  • Check Vercel dashboard for deployment status
  • Verify preview URL works
  • Check production URL after deploy

Rollback Procedure

If issues found in production:

  1. Quick fix: Create hotfix branch, PR, merge
  2. Revert: git revert {commit} and create PR
  3. Document: Add to test report what was missed

Summary Output

Check the task document for Automation: auto field.

Manual Mode

Deployment initiated for: #{ID} - {Task Title}

Branch: feature/{ID}-{task-name}
PR: #{number} - {link}

Pre-deployment checks:
- Build: PASS
- TypeScript: PASS
- Lint: PASS

TASKS.md updated to "Ready to Ship"

Next Steps:
  1. Review and merge the PR
  2. After merging, run /release to create versioned release

Auto Mode

[AUTO] Pipeline complete!

Task: #{ID} - {Task Title}
Automation: Full pipeline executed

Summary:
├── /task ✓ (task document created)
├── /implement ✓ (code written)
├── /test ✓ (tests passed)
├── /document ✓ (docs updated)
└── /ship ✓ (PR created)

Branch: feature/{ID}-{task-name}
PR: #{number} - {link}

Pre-deployment checks:
- Build: PASS
- TypeScript: PASS
- Lint: PASS

The PR is ready for your review and merge.

Related Skills

SkillWhen to Use
/implementIf fixes needed before shipping
/testIf additional testing needed
/documentIf docs need updates
/releaseAfter multiple items merged, create versioned release

Recommended Plugins (Install Separately)

These plugins must be installed separately. Once installed, they MUST be invoked — do not skip them:

PluginInstall FromWhen to Invoke
vercel-react-best-practicesvercel-labs/agent-skillsReact/Next.js code fixes
supabase-postgres-best-practicessupabase/agent-skillsDatabase-related fixes

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

35.09%
按下载量换算53

Claude

28.96%
按下载量换算44

Cursor

18.94%
按下载量换算29

Gemini CLI

8.59%
按下载量换算13

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills