ship — 将工作投入生产（git + gh）
平台无关的 ship 工作流。无绕过，无捷径。
预推送：本地 CI 流水线（推送前一切通过）
- 格式化 —
cargo fmt --check/prettier --check/ruff format --check - Lint —
cargo clippy -- -D warnings/eslint/ruff check - 类型检查 —
cargo check/npx tsc --noEmit - 测试 —
cargo test/npm test/pytest（显示输出） - 构建 —
cargo build/npm run build
如果某一步失败：修复并重新运行所有检查。切勿推送已知失败的代码。
流程
- 专用分支（切勿直接在
main上工作）。 - 按阶段提交，使用约定式提交 + 证据优先消息（SHA/PR/CI）。
git push推送该分支。- 开启 PR：摘要 + 测试计划（若仓库使用 5 段模板）。
- 监控 CI：
gh pr checks <n>— 全部 SUCCESS 后再继续。 - 合并：仅使用合并提交（绝不 squash，绝不 rebase — 为并行代理保留历史）。
- 合并后：删除分支，快进本地
main，报告合并提交的 SHA。
人工门控（STOP — 先询问）
- 合并到
main且影响分支保护/安全/许可证/发布基础设施 (#1) - 强制推送到
main(#2) — 未经明确确认始终禁止 - CI 未全部通过 → 不要合并任何待处理/失败的代码
审查评论
每条评论（人类或机器人）都必须被分析、理解和妥善解决 — 切勿
静默解决，也切勿仅触及引用的行而忽略实质的“修复”。
在线程中回复你做了什么以及原因，然后解决。参见 skills/review。