Token导航 LogoToken导航

Agent Skill · 研究检索

ship(发布交付)

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

ship 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为接触敏感数据;许可证信息还不明确,第三方扫描已通过,按安装量在研究检索类的 73,675 个 Skill 里排第 56,324。

总安装 456周安装 19GitHub Stars 公开资料未说明下载 152核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 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

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

用于创建 Pull Request 并完成部署准备。适合在 Codex、Claude、Cursor、Gemini CLI 中推进代码合并。自动检查构建、类型和 lint 通过后生成 PR。关联任务文档并更新 TASKS.md 状态。

适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。ship 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/ship

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/eljun/claude-skills --skill ship;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要接触敏感数据,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

ship 怎么安装?

在终端执行 npx skills add https://github.com/eljun/claude-skills --skill ship。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

ship 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

ship 需要什么权限?

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

ship 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

ship 用的人多吗?

公开数据是累计安装 456 次,近一周安装 19 次,下载 152 次。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

ship 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 需要接触敏感数据,装到常用环境前要先评估影响面。
  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 环境里有大量密钥、凭证,不方便给第三方 Skill 读取的人。
  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
ship

发布交付 · 本页

456—接触敏感数据未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

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

平台分布

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