cron-routine

name	cron-routine
description	Claude Code Routinesなどで一定の日時に起動して作業するためのスキル。おもに5時間の利用制限が解除されそうなタイミングで呼ばれる。作業内容は、 1. テストが落ちていないか確認 - 2. HIGH PRIORITY Issueの解消 - 3. PRメンテナンス - 4. Issue消化。暇ならコードレビュー。複数のIssueに対する並行作業禁止。

1. developブランチのバグを見つける

まず、GitHubのメインブランチのテストが通っているかどうか確認。 エラーがあれば、コードのバグを見つけ、bugラベルを付けてIssueを立てる。

注意: 最近マージされたPRが原因で新たにCIが壊れている場合もある。全CIジョブ（test・test-worker・test-client・lint系）を漏れなく確認すること。

2. HIGH PRIORITY Issueの解決を確認

HIGH PRIORITYタグのついたIssueは、他のPRのマージをブロックするものなので、まずはこれに取り組む。

実装毎に feature-implementer サブエージェントを呼び出し、Issue番号を伝えて作業してもらう。
方針をIssueコメントに残してから実装を行うようにさせる。

3. PRメンテナンス （develop追従・レビュー対処・WIP管理）

pr-maintainer サブエージェントを呼び出して、PRメンテナンスを行わせる。

pr-maintainer に結果を報告させ、問題があれば次ステップに反映する。
routine環境では人間はその場にいないので、 pr-maintainer から質問が飛んできたら、PR/Issueにコメントして続けさせる。

4. Issue消化

次に、1で見つけたバグを含め、GitHubで関連PRのないIssueを一覧し、優先度が高い(HIGH PRIORITY ラベルなど)、もしくは簡単そうなものから、Issueを解決していく。

実装毎に feature-implementer サブエージェントを呼び出し、Issue番号を伝えて作業してもらう。
方針をIssueコメントに残してから実装を行うようにさせる。

原則、1つのIssueにつき1つのPRを作ること。PRの変更量が大きくなりそうな場合、可能であれば変更を段階で分割し（しかしscope(client, worker, etc)で分割はしない）、新しくSub-issueを作成し、それに対してPRを作成するように計画変更する。

PRの編集がコンフリクトしそうな場合、優先度の高いPRのブランチをベースにして新しいPRを作成する。

• まずはbugラベルのついたバグ報告の修正を優先。 ただし、ブラウザ依存であると書き残されている場合は無視。
• 次にsecurityラベルのIssueを選ぶ。
• 最後にfeatureラベルのついたIssueに手を付ける。

Ex. コードレビュー

もし解決すべきIssueが一つもなかったら、既存の開いているPRのレビューと修正をする。
番号の若いPRから順に、pr-reviewerを呼び出しレビューをしてもらい、その結果をpr-patcherに渡して修正する。
前回のClaude Codeセッションの内容を取得し、番号の若いPRにレビューが偏らないようにする。

前回のセッションが途中で終わった場合

前回のルーティンセッションが何らかの理由で途中で停止した可能性を考える。
毎回のルーティンで、1は必ず行う。

注意

並行作業禁止

並列して作業を行わないようにすること。特に、同一のサブエージェントは複数呼んで作業させないこと。その理由は:

• Gitの仕様上、複数ブランチを同時に編集するのが困難
• Claude Proの5時間制限にヒットして作業内容が失われるのを防ぐ

急いでも仕方がないので、ゆっくり順番に着実に作業しよう。

なるべくサブエージェントを使う

あなたはオーケストレータであり、コードの実装はサブエージェントを呼び出して作業させるべき。サブエージェントに作業させることで、このオーケストレータセッションの履歴に余計なものを残さないようにし、思考をクリアに保てる。

/goal

ユーザーの指示を待つことなくIssueやレビューに次々と取り組むこと。
(ブラウザ依存バグを除く)全てのIssueに対してPRが作成された状態になれば完了。