CALL ME STUPID
戻る

Orca を中心にした最近の開発スタイル

前置き

本業ではバックエンド(Rails)・Web フロントエンド・モバイル向けアプリなどのリポジトリをさわっている．

1 つの要望が複数リポジトリにまたがるのと，並行して他人の PR レビューも回ってくる．
ここ 1〜2 ヶ月くらいで，このへんを Orca を中心にほぼ AI agent に回してもらう形に落ち着いてきたので，忘れないうちに書いておく．

前回の記事で Herdr を使ってると書いたけど，仕事のほうはいまは Orca が中心になっている．

Orca を中心にする

Orca は worktree 単位でエージェント(Claude Code / Codex)のセッションを並べて管理できるやつ．
自分が気に入っているのはこのへん．

要するに「チケット 1 つ = worktree 1 つ = エージェント 1 体」で並べておける．
並行して 3〜4 本動いていても，サイドバー見れば何がどこまで進んでるかわかる．
worktree にはコメントが付けられるので，エージェントに 設計中 → 実装中 → レビュー待ち と自分で書き換えさせている．

開発: Jira から worktree を切ったら勝手に始まる

Orca で Jira チケットから worktree を作って Claude Code を起動すると，Claude Code の SessionStart hook が orca worktree current --json を叩いて「これは Jira 由来の worktree か」を判定する．
そうなら，チケットのキーと URL を添えて「jira-feature skill を起動せよ」とセッション冒頭に差し込む．

Orca 自体には Jira の内容をエージェントに渡す仕組みがないので，そこを hook で埋めている感じ．

あとは skill のほうでフェーズを固定している．

Phase 0  準備     Jira 本文・コメント・リンク先(Slack/Notion/PR)を読む
                  リポジトリの関連コードを Explore サブエージェント並列で調査
Phase 1  設計     要約 + 論点 + 最初の質問 → 質疑のたびに設計 doc を更新
Phase 2  承認     「ok」で status: approved を書いて実装計画を作る
Phase 3  実装     フロント側の worktree は親セッションが裏で作る
Phase 4  PR       repo ごとに作成．本文にデプロイ順を書く
Phase 5  並列     (a) 動作確認 → サブエージェントに委譲
                  (b) codex-review + CodeRabbit 収集
Phase 6  報告     結果を Artifact にまとめて，ok なら Slack に共有
Phase 7  指摘対応 採否を決めて修正 → push → 再収集

人間がやることは，設計の質疑に答える・承認する・レビュー指摘の採否を決める・Slack 投稿に ok を出す，だけ．
それ以外では止まらないように書いてある．

worktree を開いた時点で「チケットの要約・設計上の論点(推奨案つき)・最初の質問」が出ているので，こっちはそれに答えていくだけでいい．
質疑のたびに設計 doc が更新されて Inkdrop に同期されるので，あとから読み返すのも楽．

細かい工夫

レビュー(自分の PR): Codex と CodeRabbit を集めて採否だけ決める

PR を出したら，Phase 5(b) で 2 系統のレビューを集める．

集めた指摘は Claude Code が 自分でコードを読んで検証してから，docs/reviews/ の 1 本の md に repo ごとにまとめる．
各指摘には「問題」「失敗シナリオ」「修正方針」「採否案」を必ず書かせている．

ここで大事にしているのは，Codex の出力をそのまま貼らせないこと．
Codex は同僚であって権威ではない．Claude 側に「同意/異議とその根拠」を書かせると，わりと的外れな指摘がちゃんと落ちる．
あと，説明と採否の選択肢を同じターンに出させない．説明だけのターンで一度止めさせて，読んでから番号で採否を返す．
これをやらないと，説明がスクロールで流れて選択肢だけ見て決めることになるので．

レビュー(他人の PR): Automation で勝手にレビューが走る

他人の PR のレビューも Orca に寄せている．

Orca の Automation で定期的にスイープを回していて，

  1. review-requested:@me の PR(と，自分がレビュー済みで新しく push された PR)を列挙
  2. 起動済みかどうかを (repo, PR 番号, head SHA) で判定
  3. 未起動なら PR の head をチェックアウトしたレビュー専用 worktree を作って，新しい Claude Code を起動して初期プロンプトを渡す

スイープ担当のセッションは引き渡したら終わり．レビュー自体はしない．
dependabot の PR とリリース PR は別扱いで除外している．

起動されたレビュー agent は code-review skill でレビューして docs/reviews/<日付>-pr-<番号>.md に書き，そのあと review-comment-judge skill で 各指摘を「投稿 / 保留 / 見送り」に振り分けて PR に投稿する．

review-comment-judge

これは，自分が過去にレビュー文書を読んで「これは投稿」「これは見送り」と指示していたログから規則を抜き出したもの．
たとえば見送りの例．

逆に Major/Medium は，再現か一次資料・最新の head との照合・PR 本文や Jira との突合・既存コメントとの重複チェック，を全部通ったものだけ投稿する．通らなければ保留．
文面も自分の文体に寄せてあって，絵文字や「AI によると」みたいなのは書かない．

Approve と Request changes は絶対に付けない．投稿は COMMENT だけで，Approve は自分で押す．
なので朝来たら，自分は保留になった項目だけ読んで投稿するか決めて，Approve を押す，くらいになっている． 将来的にここも人間の判断は不要になるかもしれないが今のところはまだ見るようにしている．

横断調査: CodeGraphContext

「この機能ってバックエンドとフロントでどうつながってるんだっけ」系の調査は，全リポジトリを CodeGraphContext でインデックスして MCP 経由で引けるようにしている．
CodeGraphContext だけだと GraphQL などは引けないので，ラップしてコード以外にも Schema を引けるようなラッパー MCP を作った．

ドキュメントの置き場

設計・メモ・レビュー結果は全部リポジトリの docs/ 配下に日付つきファイル名で書かせて，PostToolUse hook で Inkdrop に同期している．

エージェントのセッションは消えるけど，doc は Inkdrop に残る．
スマホ/タブレットからも読めるので，移動中にレビュー文書読んで判断する，みたいなこともできる．

やってみて

前の記事
ThinkPad X13 に Omarchy を入れた