ship-and-babysit

Ship and Babysit

ユーザーがブランチをエンドツーエンドで出荷したい場合、tinyhumansai/openhuman に対してこのスキルを使用します：

• ローカルの変更をコミットする
• ブランチをユーザーのフォークにプッシュする
• tinyhumansai/openhuman:main に対して PR を作成または再利用する
• マージゲートになりそうな検証を先回りして実行し、問題の修正をすぐに開始する
• すべてのチェックが完了するのをただ待つのではなく、ポーリングループで CI とレビューフィードバックを監視する
• 対応可能なレビューコメントに対処し、フォローアップの修正をプッシュする
• PR がグリーンでクリーンになったときのみ停止する

前提条件

• リポジトリのルートから作業します。
• 検証や PR チェックリストの要件を含む、AGENTS.md のリポジトリルールに従います。
• origin はユーザーの書き込み可能なフォークであり、upstream は tinyhumansai/openhuman を指していると想定します。
• フォークのオーナーを早い段階で一度解決し、再利用します：
  • FORK_OWNER=$(git remote get-url origin | sed -E 's#.*[:/]([^/]+)/[^/]+(\.git)?$#\1#')
• origin が tinyhumansai に解決される場合は、停止してユーザーにフォークリモートの追加を依頼します。ブランチを upstream にプッシュしないでください。
• ローカルの main で作業が始まる場合は、コミットする前に説明的な新しいブランチを作成し、変更がすぐに main から離れるようにします。
• main に直接プッシュしないでください。
• upstream にプッシュしないでください。
• ユーザーが明示的に要求しない限り、すでにプッシュされたコミットを amend したり書き換えたりしないでください。
• 自分の変更によって引き起こされた破損に対してフックをバイパスしないでください。
• デフォルトでは自律的に実行します。合理的で安全なデフォルトが存在する場合、プロセス上の質問をするためにユーザーのところで止まらないでください。
• ワークフローがアクセスの欠如、認証情報の欠如、またはリポジトリのコンテキストから推測できない不可逆的な選択によって真にブロックされている場合にのみ、ユーザーに質問してください。

ワークフロー

フェーズ 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 にエージェントが作成したコミットが残らないようにします。
5. 未コミットの変更がある場合は、コミットする前に、触れた領域に対して意味のある最小限のローカル検証を実行します。
6. 関連するファイルのみをステージングし、焦点を絞った conventional commit メッセージを作成します。
7. ローカルの変更がない場合は、コミットを作成せずに続行します。

機能の E2E 要件

機能作業を出荷する前に、PR に新機能のエンドツーエンドのカバレッジが含まれていることを確認します。

• コア、ドメイン、永続化、CLI、または JSON-RPC の機能変更には、tests/*_e2e.rs での Rust E2E カバレッジが必要であり、通常は pnpm test:rust:e2e -- --suite <suite> または bash scripts/test-rust-e2e.sh --suite <suite> を通じて対象を指定します。
• 新規または変更された JSON-RPC サーフェスは、より焦点を絞った *_e2e.rs スイートがドメインを担当していない限り、通常は tests/json_rpc_e2e.rs を拡張する必要があります。
• フロントエンドのユーザーフローには、app/test/e2e/specs/*.spec.ts での Playwright E2E カバレッジが必要であり、対象を指定した Web E2E を pnpm --filter openhuman-app test:e2e:web:build および bash app/scripts/e2e-web-session.sh test/e2e/specs/<spec>.spec.ts でビルド/実行します。
• バックエンド呼び出しは最後までモックします。リポジトリのモックバックエンド（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. ベビーシットループ内で以降の修正コミットを行うたびに、再度プッシュします。ローカルコミットで止めないでください。

フェーズ 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 ティック、合計約 60 分間ループを継続します。
• 環境が永続的なウェイクアップをサポートしていない場合は、セッション内に留まり、sleep 270 を使った繰り返しポーリングを行います。
• 各ティックで、ユーザーに短い進捗アップデートを投稿します。
• ティックの合間には、受動的な待機よりも有用な作業を優先します。
  • 完了した失敗は、発生した時点でできるだけ早く調査する
  • レビューコメントと未解決のスレッドは直ちに調査する
  • リモートチェックがまだ保留中の間も、変更された領域に対して実施可能なローカル検証を先回りして実行する
  • 修正は準備ができ次第プッシュし、CI の全タイムラインの後ろにまとめて回さない

各ティック:

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 の場合、アクションを起こす前にマトリックス全体が完了するのを待たないでください:
   • 変更されたファイルと直近のコミット差分を調査する
   • 最も関連性の高いローカルマージゲートコマンドを先回りして実行する
   • ローカルで再現した失敗は直ちに修正する
   • 修正が検証され次第、コミットしてプッシュする
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 経由でレビュースレッドを調査します:
   • hasNextPage が false になるまでページネーションして reviewThreads をクエリする
8. 特に coderabbitai および coderabbitai[bot] からのボットフィードバックを調査しますが、人間による対応可能なレビューコメントも併せて確認します。
9. 対応可能なレビューコメントまたは未解決のレビュースレッドごとに:
   • 参照されているファイルと行を読む
   • 最小限の正しい修正を適用する
   • 対象を絞った検証を再実行する
   • コミットする
   • プッシュする
10. 不正確、古い、または範囲外のレビューフィードバックについては、既存のレビュースレッドに具体的な根拠を添えて返信します。無関係な新しいレビューを開かないでください。また、根拠が明確で、プラットフォームがサポートしている場合にのみ解決または却下してください。
11. レビュースレッドに対応した後、適切な場合は GitHub のレビュースレッド API を通じてそれを解決します。
12. 前回のティック以降に新しい issue レベルの CodeRabbit コメントが出現したかどうかを追跡し、新しいボットフィードバックが待機している間にループが終了しないようにします。
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 が実際に更新されるよう、必ずフォローアップコミットをプッシュしてください。
• main から呼び出された場合は、まずブランチを作成してから出荷してください。ユーザーに main からエージェントのコミットをクリーンアップさせないでください。
• gh pr checks --watch を一度確認するだけでは、十分なベビーシッティングとは言えません。スキルは終了条件が満たされるまで、CI とレビューの各サーフェスを能動的に再ポーリングする必要があります。
• スキルは、ブランチ名、CI の修正を開始するかどうか、明らかに対応可能な失敗に対処するかどうかといった定型的なワークフローの選択について、ユーザーに確認を求めるべきではありません。
• スキルは、ユーザーが能動的なベビーシッティングを望んでいるものと想定する必要があります。ブロックされるかグリーンになるまで、継続的に検査、修正、コミット、プッシュを行ってください。
• レビューの処理には以下を含める必要があります:
  • 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