ship-and-babysit

交付并盯守

当用户希望将某个分支端到端交付时，对 tinyhumansai/openhuman 使用此技能：

• 提交本地更改
• 将分支推送到用户的 fork
• 针对 tinyhumansai/openhuman:main 打开或复用 PR
• 主动运行可能的合并门禁验证，并立即开始修复问题
• 在轮询循环中监控 CI 和评审反馈，而不是空等每一项检查完成
• 处理可执行的评审意见并推送后续修复
• 仅当 PR 变绿且干净时才停止

前置条件

• 从仓库根目录开始工作。
• 遵循 AGENTS.md 中的仓库规则，包括验证和 PR 检查清单要求。
• 假定 origin 是用户可写的 fork，upstream 指向 tinyhumansai/openhuman。
• 在开始时解析一次 fork 所有者并复用：
  • FORK_OWNER=$(git remote get-url origin | sed -E 's#.*[:/]([^/]+)/[^/]+(\.git)?$#\1#')
• 如果 origin 解析为 tinyhumansai，停止并让用户添加一个 fork 远程。绝不要将分支推送到 upstream。
• 如果工作在本地 main 上开始，在提交前创建一个新的描述性分支，以便更改立即离开 main。
• 绝不要直接推送到 main。
• 绝不要推送到 upstream。
• 绝不要修改或重写已经推送的提交，除非用户明确要求。
• 绝不要为自己更改引入的破坏绕过钩子。
• 默认自主执行。当存在合理的安全默认值时，不要停下来向用户询问流程问题。
• 仅当工作流因缺少访问权限、缺少凭据或无法从仓库上下文推断的不可逆选择而真正受阻时，才向用户提问。

工作流

阶段 1：检查并提交

1. 在更改任何内容之前检查分支。优先并行读取：
   • git status --short
   • git diff --stat
   • git diff --cached --stat
   • git log --oneline --decorate -n 12
2. 确定当前分支：
   • git rev-parse --abbrev-ref HEAD
3. 确认分支通常遵循 feat/、fix/、refactor/、chore/、docs/ 或 test/。
   • 如果当前分支是 main，立即创建一个新的描述性分支并在那里继续。
   • 如果名称不遵循约定，且它已经是非 main 分支，则继续使用它，除非它仍是本地分支且可以在不干扰已推送分支的情况下轻松安全地重命名。
4. 如果有未提交的更改，在做任何其他事情之前先将它们带到新分支上，以便本地 main 不包含 Agent 编写的提交。
5. 如果有未提交的更改，在提交前对涉及区域运行最小但有意义的本地验证。
6. 仅暂存相关文件，并创建一条聚焦的约定式提交信息。
7. 如果没有本地更改，则不创建提交并继续。

功能 E2E 要求

在交付功能工作之前，验证 PR 包含新行为的端到端覆盖。

• 核心、领域、持久化、命令行或 JSON-RPC 功能更改需要在 tests/*_e2e.rs 中提供 Rust E2E 覆盖，通常通过 pnpm test:rust:e2e -- --suite <suite> 或 bash scripts/test-rust-e2e.sh --suite <suite> 定向运行。
• 新增或更改的 JSON-RPC 接口通常应扩展 tests/json_rpc_e2e.rs，除非有更聚焦的 *_e2e.rs 套件负责该领域。
• 前端用户流程需要在 app/test/e2e/specs/*.spec.ts 中提供 Playwright E2E 覆盖；使用 pnpm --filter openhuman-app test:e2e:web:build 构建/运行定向 Web E2E，并使用 bash app/scripts/e2e-web-session.sh test/e2e/specs/<spec>.spec.ts。
• 全程 mock 后端调用。使用仓库的 mock 后端（scripts/mock-api-server.mjs、scripts/mock-api/*、app/test/e2e/mock-server.ts）和管理行为端点；不要访问真实后端服务或第三方 API。
• 对于狭义的逻辑，仍然期望有单元测试，但它们不能替代新构建功能的 E2E 覆盖。

阶段 2：推送

1. 将当前分支推送到 origin。
2. 如果缺少上游跟踪，使用 -u 推送。
3. 如果 pre-push 钩子因你自己的更改而失败，修复问题后再次推送。
4. 如果 pre-push 钩子仅因无关的既有问题而失败，使用 --no-verify 推送，并在 PR 正文中明确记录这一点。
5. 在 babysit 循环中之后的每一次修复提交后，都要再次推送。不要停留在本地提交。

阶段 3：打开或复用 PR

1. 使用 git remote -v 验证远程仓库，并确认 upstream 指向 tinyhumansai/openhuman。
2. 检查是否存在针对该确切分支的现有 PR：
   • gh pr list --repo tinyhumansai/openhuman --head <fork-owner>:<branch> --state open --json number,url
3. 如果 PR 已存在，记录其编号和 URL 并复用它。
4. 如果不存在 PR：
   • 检查 git log main..HEAD 和 git diff main...HEAD
   • 按原样填写 .github/PULL_REQUEST_TEMPLATE.md
   • 将每个检查清单项标记为已勾选；对于不适用的项，使用 - [x] N/A: <reason>，以便 pnpm pr:checklist 接受
   • 以 --head <fork-owner>:<branch> 针对 tinyhumansai/openhuman:main 创建 PR
5. 向用户打印 PR URL。
6. 在打开或复用 PR 后，立即根据所涉及的领域开始主动验证，而不是等待远程 CI 完成：
   • 运行覆盖已更改代码的最小可能合并门禁命令集
   • 优先使用快速失败检测器，例如 format、typecheck、lint、针对性测试，以及与所涉及文件相关的 cargo 检查
   • 立即修复本地发现的失败，然后在下一次 CI 轮询前再次提交并推送

阶段 4：看护循环

运行一个显式的轮询循环，直到 PR 变为绿色且干净。不要将其视为一次性的状态检查，也不要坐等所有检查完成后再采取行动。

• 大约每 5 分钟轮询一次。
• 最多持续循环 12 个 tick，总计约 60 分钟。
• 如果环境不支持持久唤醒，则保持在会话中并使用 sleep 270 重复轮询。
• 在每个 tick，向用户发布一条简短的进度更新。
• 在 tick 之间，优先做有用的工作，而不是被动等待：
  • 一旦出现已完成的失败，立即检查
  • 立即检查审查评论和未解决的讨论串
  • 在远程检查仍在进行时，对已更改的区域运行可能的本地验证
  • 一旦修复准备好就推送，而不是将它们积压在整个 CI 时间线之后

每个 tick：

1. 获取 CI 状态：
   • gh pr checks <pr-number> --repo tinyhumansai/openhuman --json name,state,link,description
2. 将 PENDING 视为仍在进行中。在检查仍在运行时不要声称成功。
3. 如果任何已完成的检查为 FAILURE 或 CANCELLED：
   • 如果 link 是 GitHub Actions 运行 URL，提取运行 id 并用 gh run view <id> --log-failed --repo tinyhumansai/openhuman 检查失败日志
   • 否则根据检查名称、状态和描述进行处理
   • 进行最小的正确修复
   • 重新运行针对性验证
   • 提交
   • 推送
4. 如果检查大多仍为 PENDING，不要等待整个矩阵完成后再采取行动：
   • 检查已更改的文件和最近的提交差异
   • 主动运行最相关的本地 merge-gate 命令
   • 立即修复任何本地复现的失败
   • 一旦修复验证通过就提交并推送
5. 获取 PR 审查评论：
   • gh api repos/tinyhumansai/openhuman/pulls/<pr-number>/comments --paginate
6. 获取 issue 级别的 PR 评论：
   • gh api repos/tinyhumansai/openhuman/issues/<pr-number>/comments --paginate
7. 通过 GraphQL 检查审查讨论串，而不仅仅是扁平评论，以免未解决的讨论被遗漏：
   • 查询 reviewThreads 并分页，直到 hasNextPage 为 false
8. 特别检查来自 coderabbitai 和 coderabbitai[bot] 的 bot 反馈，但也要检查人类可操作的审查评论。
9. 对于每条可操作的审查评论或未解决的审查讨论串：
   • 阅读引用的文件和行
   • 应用最小的正确修复
   • 重新运行针对性验证
   • 提交
   • 推送
10. 对于不正确、过时或超出范围的审查反馈，在现有的审查讨论串中回复具体理由。不要开启新的无关审查，只有在理由明确且平台支持时才解决或驳回。
11. 处理完一个审查讨论串后，在适当的情况下通过 GitHub 审查讨论串 API 解决它。
12. 跟踪自上一个 tick 以来是否出现了新的 issue 级别 CodeRabbit 评论，以免循环在新 bot 反馈仍在等待时退出。
13. 仅当所有必需的检查均为 SUCCESS、没有未解决的可操作审查讨论串、没有新的可操作 CodeRabbit issue 评论，且最新修复已提交并推送到 PR 分支时，才退出循环。

如果循环达到硬性上限，则停止并报告 PR URL、当前 CI 快照以及任何未解决的审查讨论串或评论。

有用的检查

• pnpm typecheck
• pnpm lint
• pnpm format:check
• pnpm test
• cargo check --manifest-path Cargo.toml
• cargo check --manifest-path app/src-tauri/Cargo.toml
• pnpm test:rust
• pnpm test:rust:e2e -- --suite <suite>
• pnpm --filter openhuman-app test:e2e:web:build
• bash app/scripts/e2e-web-session.sh test/e2e/specs/<spec>.spec.ts

当涉及的区域较窄时，优先使用针对性测试命令，但如果某条命令未运行，就不要声称验证已通过。

说明

• 除非用户明确要求，否则不要合并 PR。
• 如果该分支已存在 PR，请复用现有的 PR。
• 始终推送后续提交，以便 PR 在修复后确实得到更新。
• 如果从 main 调用，请先创建分支，然后再交付。不要让用户去清理 main 上的 agent 提交。
• 仅检查一次 gh pr checks --watch 并不足以完成 babysitting。该技能应主动持续轮询 CI 和评审界面，直到满足退出条件。
• 该技能不应就常规工作流选择向用户请求确认，例如分支命名、是否开始修复 CI，或是否对明显的可操作失败采取行动。
• 该技能应假定用户希望主动 babysitting：持续检查、修复、提交并推送，直到被阻塞或变绿。
• 评审处理必须包括：
  • PR 评审评论
  • issue 级别的 PR 评论
  • 未解决的评审线程
• 如果 CI 或评审界面暴露出无关的既有故障，请明确指出，并避免将其掩盖为已修复。
• 如果 GitHub 鉴权、远程仓库或分支保护不允许该工作流，请报告确切的阻塞点，并在第一个被阻塞的步骤处停止。

调用提示

• Use $ship-and-babysit for this branch
• Ship this and babysit the PR
• Open the PR and stay on CI until it is green