Back to Details

ship

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/ship - Deployment Agent

/ship - 部署Agent

Model: haiku (scripted deployment commands)
模型： haiku（脚本化部署命令）

Command Flags

命令参数

FlagShortDescription
--help
-h
Show available commands and options
--version
-v
Show workflow skills version
参数简写描述
--help
-h
展示可用命令和选项
--version
-v
展示工作流技能版本

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
当使用 
-h
或 
--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
当使用 
-v
或 
--version
时： 输出内容：
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
当满足以下条件时调用
/ship {ID}
：
  • 任务在TASKS.md中处于「已获批」状态
  • 文档已全部完成
  • 准备好部署到生产环境
示例： 
/ship 1
或 
/ship 001-dashboard-redesign

Task ID Resolution

任务ID解析

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
{ID}
支持以下格式：
  • 数字ID： 
    1
    、
    2
    、
    3
    → 会在TASKS.md中查找匹配的任务文档
  • 补零ID： 
    001
    、
    002
    → 和数字ID逻辑一致
  • 完整文件名： 
    001-dashboard-redesign
    → 直接引用对应文件

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.
/ship {ID}
       ↓
1. 解析任务ID → 查找对应的任务文档
2. 校验任务在TASKS.md中处于已获批状态
3. 检查自动化字段（manual | auto）
4. 在TASKS.md中将任务移动到「待发布」状态
5. 运行部署前检查
6. 创建/更新分支（feature/{ID}-{task-name}）
7. 创建Pull Request（附带任务ID引用）
8. 用PR链接更新TASKS.md
       ↓
合并后 → 更新「已合并」列（仍保留在「待发布」状态）
       ↓
/release → 将任务移动到「已发布」并关联版本号
重要提示： 任务即使合并后也会保留在「待发布」状态，只有运行
/release
才会将任务移动到「已发布」状态并关联发布版本，确保发布跟踪的准确性。

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.
当任务文档中配置了
Automation: auto
时：
PR创建完成后，自动化流水线会自动完成后续流程：
[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"
注意： 自动模式下仍会创建PR并通知你，由你决定何时合并，自动化流程不会自动合并PR。

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:
bash
undefined
如果要发布的任务是多任务执行的一部分，提交记录会通过
[task-{ID}]
前缀进行追踪：
bash
undefined

Find all commits for a specific task

Find all commits for a specific task

git log --oneline --grep="[task-1]"
git log --oneline --grep="[task-1]"

Example output:

Example output:

a1b2c3d [task-1] feat: Add JWT authentication middleware

a1b2c3d [task-1] feat: Add JWT authentication middleware

e4f5g6h [task-1] feat: Add token refresh logic

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

这种机制让`/ship`可以：
1. 识别哪些变更属于对应任务
2. 生成准确的PR描述
3. 在PR正文中引用特定提交记录

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

1. 校验获批状态

Check TASKS.md:
  • Task must be in "Approved" section
  • Feature doc exists
  • Test report shows PASS
检查TASKS.md：
  • 任务必须在「已获批」分区
  • 功能文档存在
  • 测试报告显示通过

2. Review Changes

2. 审查变更

bash
git status
git diff main...HEAD
Verify:
  • All intended files are changed
  • No unintended changes
  • No sensitive files (
    .env
    , credentials)
bash
git status
git diff main...HEAD
校验：
  • 所有预期的文件都已修改
  • 没有非预期的变更
  • 没有敏感文件（
    .env
    、凭证信息）

3. Run Pre-Deployment Checks

3. 运行部署前检查

bash
undefined
bash
undefined

Build check

Build check

pnpm build
pnpm build

Type check

Type check

pnpm typecheck
pnpm typecheck

Lint check

Lint check

pnpm lint

All must pass before creating PR.

---
pnpm lint

创建PR前所有检查必须全部通过。

---

Update TASKS.md

更新TASKS.md

Move task to "Ready to Ship":
markdown
undefined
将任务移动到「待发布」分区：
markdown
undefined

Ready to Ship

Ready to Ship

IDTaskBranchPRMergedTask Doc
1Quick Actions Redesignfeature/1-quick-actionsPendingNo001-quick-actions.md

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

---
IDTaskBranchPRMergedTask Doc
1Quick Actions Redesignfeature/1-quick-actionsPendingNo001-quick-actions.md

**注意：** 「已合并」列用于跟踪合并状态，任务会一直保留在此分区直到运行`/release`命令。

---

Git Workflow

Git工作流

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)
分支名称中加入任务ID保证清晰度：
feature/{ID}-{task-name}     - 新功能 (e.g., feature/1-auth-jwt)
fix/{ID}-{task-name}         - Bug修复 (e.g., fix/2-login-redirect)
enhance/{ID}-{task-name}     - 功能优化 (e.g., enhance/3-dashboard)

If Branch Doesn't Exist

分支不存在时的操作

bash
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}
bash
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

分支已存在时的操作

bash
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
bash
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

创建Pull Request

Use GitHub CLI to create PR:
bash
gh pr create --title "[Task #{ID}] {PR Title}" --body "$(cat <<'EOF'
使用GitHub CLI创建PR：
bash
gh pr create --title "[Task #{ID}] {PR Title}" --body "$(cat <<'EOF'

Summary

Summary

{2-3 bullet points describing the changes}
{2-3 bullet points describing the changes}

Task Documentation

Task Documentation

  • Task ID: #{ID}
  • Task Doc: docs/task/{ID}-{task-name}.md
  • Test Report: docs/testing/{ID}-{task-name}.md
  • Feature Doc: docs/features/{feature}.md
  • Task ID: #{ID}
  • Task Doc: docs/task/{ID}-{task-name}.md
  • Test Report: docs/testing/{ID}-{task-name}.md
  • Feature Doc: docs/features/{feature}.md

Changes

Changes

FileChange
path/to/file
Description
FileChange
path/to/file
Description

Commits

Commits

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

Testing

Testing

  • E2E tests passed (see test report)
  • Manual testing completed
  • Ready for code review
  • E2E tests passed (see test report)
  • Manual testing completed
  • Ready for code review

Screenshots

Screenshots

{If UI changes, include before/after}
Generated with Claude Code EOF )"

---
{If UI changes, include before/after}
Generated with Claude Code EOF )"

---

PR Checklist

PR检查清单

Before creating PR, verify:
创建PR前，校验以下内容：

Code Quality

代码质量

  • Build passes (
    pnpm build
    )
  • No TypeScript errors
  • Lint passes (
    pnpm lint
    )
  • No console.log statements
  • No commented-out code
  • 构建通过（
    pnpm build
    ）
  • 无TypeScript错误
  • Lint检查通过（
    pnpm lint
    ）
  • 无console.log语句
  • 无注释掉的代码

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
  • 无硬编码的密钥
  • 没有包含
    .env
    文件
  • API密钥未暴露
  • 已配置正确的权限校验

Testing

测试

  • E2E tests pass
  • Manual testing done
  • Edge cases handled
  • E2E测试通过
  • 已完成手动测试
  • 已处理边界情况

Update TASKS.md with PR

用PR信息更新TASKS.md

After PR is created:
markdown
undefined
PR创建完成后：
markdown
undefined

Ready to Ship

Ready to Ship

IDTaskBranchPRMergedTask Doc
1Quick Actions Redesignfeature/1-quick-actions#123No001-quick-actions.md

---
IDTaskBranchPRMergedTask Doc
1Quick Actions Redesignfeature/1-quick-actions#123No001-quick-actions.md

---

Post-Merge Actions

合并后操作

After PR is merged, update the "Merged" column but keep in "Ready to Ship":
PR合并后，更新「已合并」列但仍保留在「待发布」分区：

1. Update TASKS.md Merged Status

1. 更新TASKS.md的合并状态

markdown
undefined
markdown
undefined

Ready to Ship

Ready to Ship

IDTaskBranchPRMergedTask Doc
1Quick Actions Redesignfeature/1-quick-actions#123✅ Jan 26001-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
IDTaskBranchPRMergedTask Doc
1Quick Actions Redesignfeature/1-quick-actions#123✅ 1月26日001-quick-actions.md

**重要提示：** 不要现在就移动到「已发布」分区，任务会一直保留在「待发布」分区直到运行`/release`命令，这样`/release`可以：
1. 识别哪些内容需要包含在本次发布中
2. 准确跟踪每个功能所属的发布版本

2. Update Task Document Status

2. 更新任务文档状态

Update task document to reflect merge:
markdown
> **Status:** MERGED
> **Merged:** {Date}
> **PR:** #{number}
更新任务文档以反映合并状态：
markdown
> **Status:** MERGED
> **Merged:** {Date}
> **PR:** #{number}

3. When to Run /release

3. 何时运行/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
markdown
undefined
一个或多个任务合并后，运行
/release
来：
  • 创建带变更日志的版本化发布
  • 将所有已合并的任务从「待发布」移动到「已发布」
  • 为每个任务关联发布版本
markdown
undefined

Shipped

Shipped

IDTaskPRReleaseShipped
1Quick Actions Redesign#123v1.2.0Jan 26

---
IDTaskPRReleaseShipped
1Quick Actions Redesign#123v1.2.01月26日

---

Handling Issues

问题处理

Build Fails

构建失败

  1. Fix the build errors
  2. Commit fixes
  3. Re-run checks
  4. Continue with PR
  1. 修复构建错误
  2. 提交修复内容
  3. 重新运行检查
  4. 继续PR流程

PR Review Requested Changes

PR审查要求修改

  1. Make requested changes
  2. Commit with descriptive message
  3. Push to branch
  4. Re-request review
  1. 按要求修改内容
  2. 用描述清晰的信息提交变更
  3. 推送到对应分支
  4. 重新请求审查

Merge Conflicts

合并冲突

  1. Fetch latest main
  2. Rebase or merge main into branch
  3. Resolve conflicts
  4. Push updated branch
  1. 拉取最新的main分支代码
  2. 变基或将main分支合并到当前分支
  3. 解决冲突
  4. 推送更新后的分支

Deployment Verification

部署验证

After merge, verify deployment:
合并后，验证部署状态：

Vercel (Web)

Vercel (Web)

  • Check Vercel dashboard for deployment status
  • Verify preview URL works
  • Check production URL after deploy
  • 检查Vercel控制台的部署状态
  • 验证预览URL可正常访问
  • 部署完成后检查生产URL是否正常

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
如果生产环境发现问题：
  1. 快速修复： 创建热修复分支、PR、合并
  2. 回滚： 执行
    git revert {commit}
    并创建PR
  3. 记录： 在测试报告中补充遗漏的测试点

Summary Output

摘要输出

Check the task document for 
Automation: auto
field.
检查任务文档中的
Automation: auto
字段。

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
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.
[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
/implement
If fixes needed before shipping
/test
If additional testing needed
/document
If docs need updates
/release
After multiple items merged, create versioned release
技能适用场景
/implement
发布前需要修复问题时
/test
需要补充测试时
/document
需要更新文档时
/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-practices
vercel-labs/agent-skillsReact/Next.js code fixes
supabase-postgres-best-practices
supabase/agent-skillsDatabase-related fixes
这些插件必须单独安装，安装后必须调用，不要跳过：
插件安装地址调用时机
vercel-react-best-practices
vercel-labs/agent-skillsReact/Next.js代码修复时
supabase-postgres-best-practices
supabase/agent-skills数据库相关修复时