Back to Details

ship

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Ship

Ship

Sequential release pipeline for the current branch. Run only when explicitly invoked — it commits, pushes, and opens a PR.
Each stage delegates to an existing skill. Run them in order and do not advance while a stage still has unresolved findings.
Copy this checklist and track progress:
Ship progress:
- [ ] 1. Review the diff against AGENTS.md
- [ ] 2. Deslop the touched code
- [ ] 3. Commit and push
- [ ] 4. Open the PR
- [ ] 5. Babysit to merge-ready
针对当前分支的顺序发布流水线。仅在显式调用时运行——它会执行提交、推送并创建PR。
每个阶段都会委托给现有skill执行。按顺序运行这些阶段，若某一阶段仍有未解决的问题则不进入下一阶段。
复制以下检查清单并跟踪进度：
Ship进度:
- [ ] 1. 对照AGENTS.md审查差异
- [ ] 2. 优化修改过的代码（执行deslop）
- [ ] 3. 提交并推送代码
- [ ] 4. 创建PR
- [ ] 5. 持续跟进直至可合并

1. Review against AGENTS.md

1. 对照AGENTS.md审查

Read 
AGENTS.md
first (its rules change), then run 
/review
on this branch's diff, judging it against those rules. Fix real violations before continuing. Pause for the user only if a fix would change behavior or broaden scope.
先阅读
AGENTS.md
（其规则会更新），然后对当前分支的差异运行
/review
，对照其中的规则进行评判。在继续之前修复真正的违规问题。仅当修复会改变行为或扩大范围时才暂停并询问用户。

2. Deslop

2. 执行deslop

Run 
/deslop
(
../deslop/SKILL.md
) to simplify the recently modified code while preserving functionality, including its 
truffler
duplicate-consolidation pass. Apply the refinements before committing.
运行
/deslop
（详见
../deslop/SKILL.md
）以简化最近修改的代码，同时保留功能，包括其
truffler
重复代码合并步骤。在提交前应用这些优化。

3. Commit and push

3. 提交并推送

  • Stage only the intended changes; never commit secrets.
  • Add a changeset first when a published package's behavior changed (follow the Changeset section of 
    /rule-validate
    ); skip only for private/docs/test/tooling-only changes and note why.
  • Run the repo checks that fit the change before committing: 
    nr test
    , 
    nr lint
    , 
    nr typecheck
    , 
    nr format:check
    .
  • Write a concise commit message in the repo's style, focused on the why.
  • Push the branch, setting upstream with 
    -u
    on the first push.
  • Git safety: no force-push to 
    main
    , no skipped hooks, no 
    git config
    changes.
  • 仅暂存预期的更改；绝对不要提交机密信息。
  • 当已发布包的行为发生变化时，先添加变更集（遵循
    /rule-validate
    中的Changeset章节）；仅针对私有/文档/测试/工具类更改可跳过，并注明原因。
  • 提交前运行与更改匹配的仓库检查：
    nr test
    、
    nr lint
    、
    nr typecheck
    、
    nr format:check
    。
  • 按照仓库的风格撰写简洁的提交信息，重点说明更改原因。
  • 推送分支，首次推送时使用
    -u
    设置上游分支。
  • Git安全规则：禁止强制推送到
    main
    分支，禁止跳过钩子，禁止修改
    git config
    。

4. Open the PR

4. 创建PR

Create the PR with 
gh pr create
, writing the body with the PR Description structure from 
/rule-validate
(
../rule-validate/SKILL.md
): Why (with before/after), What changed, Eval results (omit the table if RDE was not run), Test plan. Pass the body via a heredoc. Return the PR URL.
使用
gh pr create
创建PR，按照
/rule-validate
（详见
../rule-validate/SKILL.md
）中的PR Description结构撰写PR正文：更改原因（包含前后对比）、更改内容、评估结果（若未运行RDE则省略表格）、测试计划。通过here-doc传递正文内容。返回PR链接。

5. Babysit

5. 持续跟进

Run 
/babysit
to drive the PR to merge-ready: resolve merge conflicts preserving intent, triage unresolved comments (including Bugbot), and fix in-scope CI in a loop until the PR is mergeable, green, and its comments are triaged. Report back instead of merging.
运行
/babysit
推动PR进入可合并状态：解决合并冲突并保留原有意图，处理未解决的评论（包括Bugbot），循环修复范围内的CI问题，直到PR可合并、检查全部通过且评论已处理。仅反馈进度，不执行合并操作。

Stop conditions

暂停条件

Pause and ask the user when:
  • Review or babysit surfaces a change that would broaden scope or alter intended behavior.
  • A merge conflict has genuinely conflicting intent on the two branches.
  • CI fails for reasons outside this branch's scope even after merging the latest base.
出现以下情况时暂停并询问用户：
  • 审查或跟进过程中发现会扩大范围或改变预期行为的更改。
  • 两个分支之间存在真正意图冲突的合并冲突。
  • 即使合并了最新的基础分支，CI仍因超出当前分支范围的原因失败。