codex-plugin-cc

I gave Claude Code a crew. Codex and Gemini found a race in the plugin that runs them. > TL;DR crewmate is a Claude Code plugin that lets Claude hand a task to OpenAI Codex or Google Gemini, keep working, and watch every step land in the conversation. It installs with 2 commands and has 0 dependencies. When I asked it to review its own code, both models found the same race condition, one I had decided was too rare to matter. If Codex is the only other model you use, OpenAI's own plugin is the better choice; more on that below. > > Code | [Try it](#try-it) !A real crewmate run: I ask Codex whether sumTo in calc.js is correct; progress lines stream in (started, two shell commands, the answer) and the job ends "done in 15s". --- "Ask the other model" You know the move. Claude wrote something you're unsure about, so you open another terminal and paste it into Codex or Gemini. You wait, copy the answer back, and paste it into Claude. The second opinion is often worth it. The copy-paste isn't. I wanted Claude to make that hand-off itself, and I wanted three things from it: - See progress while the other model works, not just a final blob. - Nothing to babysit: no server or extra terminal to keep running. - Know how it really ended: done, failed, timed out, or canceled, and why. What it does - Hand off and keep working. Each job runs in the background. Claude carries on, and the answer is waiting when the job ends, even if you closed the session. - Live progress in the chat. Every file read, command and note shows up as it happens. - Clear endings. A job ends done, failed, timeout or canceled, with the reason and any tools the other model was denied. - Read-only unless you say so. The other model can read your code. Add --write and it can edit the folder; only one writing job runs at a time. - Follow-ups. --resume continues the last conversation with that model. - Zero-context critique. /crewmate:critique sends a design doc or a diff to both models at once, and neither sees your conversation. !How it works: Claude Code calls crewmate, which starts a background runner per job. One runner drives Codex, the other drives Gemini. Each job's progress and answer are saved under ~/.crewmate, and watch --brief streams them back to Claude. That last one is the command I use most. A reviewer who hasn't seen your reasoning finds the gaps you filled in mentally, and two different models find different gaps. !A real critique of a diff: Codex and Gemini start together, failed steps show in red as they happen, each posts a progress summary, and both finish with "done" (Codex in 33 s, Gemini in 75 s). Claude decides when to use it You don't need a slash command. I asked Claude in plain words: "I want a second opinion from a different model than you: does add.js handle string inputs safely? Get Gemini's view, then tell me where you agree or disagree." Claude picked up crewmate on its own: Skill crewmate Bash crewmate ask gemini --detach <<'PROMPT' … PROMPT Bash crewmate watch --brief gemini-mvxp4oxz-o0o6 Bash crewmate result gemini-mvxp4oxz-o0o6 It wrote Gemini's brief, watched the job, checked the answer itself, and told me where the two agreed. An agent orchestrating a bigger task can hand work to Codex or Gemini the same way, without waiting for you. The bug two models agreed on Late in the build, I ran /crewmate:critique on crewmate's own lock: the code that stops two writing jobs from editing your files at once. Codex and Gemini both flagged the same race. !The race: jobs A and B both see an old, abandoned lock. A deletes it and takes the lock. B, still acting on what it saw, deletes A's new lock and takes it too, so two jobs edit your files at once. The fix runs check-and-take under a short lock of its own. I had decided that race was too rare to matter, and written that down in my plan. Codex quoted the line back at me. It's fixed now. That's the second opinion I built crewmate to get. What it won't do - Gemini can't run shell commands in read-only jobs; it reads files instead. With --write it can edit files, but still no shell. - If your Gemini (agy) settings allow writes or commands, crewmate refuses read-only Gemini jobs rather than pretend they're read-only. - macOS is what I've tested on. Linux should work; Windows isn't supported yet. Why not just OpenAI's plugin? If Codex is the only other model you use, install codex-plugin-cc: it's built on Codex's own app server and has extras like a hand-off into a native Codex session. crewmate is for having both Codex and Gemini behind one install. Try it 1. Install (in Claude Code): /plugin marketplace add aashish-g03/crewmate /plugin install crewmate@crewmate /crewmate:setup /crewmate:setup checks everything and tells you exactly what's missing. You need Node 20+ and at least one of these, installed and signed in: npm i -g @openai/codex && codex login # Codex curl -fsSL https://antigravity.google/cli/install.sh | bash && agy # Gemini (Antigravity CLI) 2. Use it: /crewmate:ask gemini Read src/ and list any exported functions nothing uses /crewmate:critique --diff Or just ask Claude: "get a second opinion from Codex on this migration." Next on my list: more models behind the same commands, and falling back to another model when one runs out of quota. If you try it, tell me where the second opinion surprised you. --- AI disclosure: I built crewmate with Claude Code as the implementer, working from a design and plan I directed and approved, with Codex, Gemini and fresh Claude reviewers checking the work. This post was drafted with Claude and edited by me. Every terminal frame is real output.

在 Claude Code 写代码，想让 Codex 审，还得切？ codex-plugin-cc 是 OpenAI 官方插件：把 Codex 接进 Claude Code，审代码、交办任务，不用换。 用两个 agent 的话，调两个模型比来回切省事。 先审哪类代码，新功能还是老代码？ #AI编程 #开源 @grok openai/codex-plugin-cc

Claude com Codex grátis? Três respostas da Veky Claude + Codex: o plugin oficial aceita conta ChatGPT Free, e o uso entra nos limites do Codex. O Claude Code tem requisitos próprios. O ARTEMIS publicado é para Android. No projeto Veky, o orbe usa Three.js no app e Remotion nos vídeos. Três perguntas recebidas; sem ranking de frequência. Fontes: openai/codex-plugin-cc google/artemis Conteúdo gerado por IA. Siga @oiveky. #codex #claudecode #artemis #inteligenciaartificial

@miaferrariii openai/codex-plugin-cc there is a plugin for this

@k8adev Usa ele dentro do claude openai/codex-plugin-cc. Dessa forma o claude orquestra ele, e você consegue usar os modelos da openai para fazer coisas específicas. Por exemplo, agora tou rodando um batch de avaliações em 250 questões, não queria gastar minha cota do claude para isso, to usando o codex dentro do claude com o astra no lugar

AIにコードレビューさせたら2時間止まらなかった話 ― 型が守るのは形であって正しさではない Claude Code で開発していて、レビューを Codex などの別の AI にさせている人向けの話です。 「指摘を直しても直しても次の指摘が来る」を経験した人は、たぶん同じ穴にはまっています。 後半は、この記事を書きながら Claude と交わした対話です。素人の私が一番ぎくっとしたのはそこでした。 何をしていたか 個人で iOS アプリ（タイマーに音楽を添えて「いまからこれをする」を 1 タップで始めるアプリ）を作っています。 開発はほぼ全部 AI で、分担はこうです。 Claude Code: 設計と実装、テスト、コミット Codex: 第三者の目。主な仕事は、実装後に「壊れる場面を探す」レビュー 私: 実機で触る。どの指摘を直すか決める Codex は公式プラグイン（openai/codex-plugin-cc）の /codex:adversarial-review で呼びます。「この変更が出荷できない最強の理由を探せ」という設定のレビューです。 何が起きたか 1 か月分の作業を main に戻す前に、Codex に全体を見せました。指摘 3 件。筋が通っていたので 3 件とも直しました。ここまでは普通です。 直したあと、もう一度見せます。直した箇所に新しい指摘が 1 件。直す。見せる。3 件。直す。1 件。直す。1 件。 時刻 何をしたか 18:14 1 回目のレビュー（3 件） 18:27 3 件を修正 18:32 2 回目（1 件） 19:18 3 回目（3 件） 19:41 4 回目（1 件） 20:00 5 回目（1 件） 20:05 私が「打ち切り」と言い、残りを残存リスクとして記録 20:12 最終レビュー（5 回目への修正に焦点を絞り、残りは裁定済みの残存リスクとして）。approve （時刻は、各回の記録をコミットした時刻です。） 2 回目以降の指摘は 全部同じ一点でした。同じ判定に 4 回手を入れ、止まったのは私が止めたからです。 その一点 このアプリには「3 分ごとに次の曲へ進む」機能があります。曲が変わったとき、自然に終わったのか、使う人がロック画面で「次へ」を押したのかを区別しないといけません。 ところが Apple の音楽再生の仕組み（MusicKit）は、なぜ曲が変わったかを教えてくれません。 だからアプリは「残り 0.5 秒以内に変わったなら自然に終わったんだろう」と 推定 します。 推定には必ず外れる場面があります。再生の確認が 0.7 秒遅れたら。曲が 2 秒しかなかったら。曲が始まった直後に割り込み（電話など）が入って 60 秒後に戻ったら。 Codex はそういう場面を見つけるのが仕事で、推定を含むコードには 必ず 見つかります。直せば、外れる場面が別の場所へ移るだけ。 実は 2 回目の時点で Claude 自身が「猶予を 1.5 秒にしても 0.5 秒にしても推定のままになる」と書いていました。 そこで 3 回目の前に、判定を「曲が変わってからの時計」から「曲の再生位置」に切り替えました。マージ前のレビューの最中に、設計ごと変えたのです。 それでも推定は消えません。再生位置の読みがいつ届くか、届いた値を信じてよいかは、やはりアプリが推し量るしかない。3〜5 回目の指摘は、その新しい判定の縁に出ました。 なぜ止まらなかったか レビュー側は「approve しない」ようにできている プラグインが Codex に渡すプロンプト（原文）にこうあります。 Use needs-attention if there is any material risk worth blocking on. Use approve only if you cannot support any substantive adversarial finding from the provided context. 指摘を 1 つでも支えられるなら approve しない。 推定を含むコードは原理的に指摘を支えられるので、受け取る側が何も決めずに approve を待つ運用は終わりません。バグではなく、明文で書かれた設計です。 （同じプロンプトには「証拠の無い推測は含めない」「安全なら指摘なしで返す」という抑える側の指示もあります。それでも推定の縁は「証拠のある指摘」になります。） 実際、この日の最後に approve が出たのは、私が「残存リスクとして引き受ける」と決めて記録に残し、焦点を 5 回目への修正の回帰に絞ってからでした。 重さの欄では見分けられなかった 5 回分の指摘は、重さの欄が全部 [medium] でした。本文には「2 秒の曲で再生確認が 1.7 秒遅れたら」のような数値も入っていましたが、書く位置も書き方も指摘ごとにまちまちで、どれが本当に起きる場面で、どれが作り物に近い場面なのか、並べて見分けられませんでした。 （Codex は指摘ごとに確信度 0〜1 も返しています。出力の型（JSON スキーマ）で必須の欄です。ただ、プラグインが人向けの文章に組み立てるときにこの欄を拾わず、画面には出ません。意図して出さないのか、出し忘れなのか、コードに理由は書かれていません。スクリプトを --json 付きで直接呼べば見えます。見えても役に立たなかったと思う理由は後半で。） 受け取る側に「止まる条件」が無かった Codex は「見つける」役で、止まる役ではない。 止まる条件を持っていなかったのは 受け取る側でした。 こうした 翌日、Claude Code への常設指示（AGENTS.md）に足した規則です。 1. 直す前に仕分ける。 指摘ごとに Claude が案を出し、私が決め、表に残す。仕分けの無い修正コミットは作らない。 仕分け どういうとき 直す 本物の不具合で、1 手（定数・ガード・分岐 1 つ）で直る 残す 推定や OS の制約の縁で、直しても外れる場面が移るだけ。残存リスクとして記録し、不具合が出たとき見るログの行を書く 捨てる 前提が作り物（この使い方では起きない曲の長さ・遅れ・操作の間隔）。理由を一行 2. 同じ一点に 2 回重なったら、3 回目は修正ではなく設計の問い。 「この判定は推定のままでよいか、外れたときの害は何か」を私に出して止まる。 3. マージ前レビューで設計を変えない。 10 月 20 日はこれを破り、設計を変えた先でまた指摘を 3 回もらいました。1 手で直らない指摘はマージ後の別の仕事にする。マージを止めるか残存リスクとして通すかは私が選ぶ。 4. 再レビューは修正差分に限定し、裁定済みの残存リスクを渡す。 「これは決めたので再提起しないで」と焦点に書く。 5. Codex に「起きる条件」を数値で書かせる。 最初は「確信度も 0〜1 で本文に書かせる」としていましたが、後半の対話を経て外しました。焦点の定型文はこうです。 各指摘の本文は次の順で書く。 (a) 前提: 起きるのに必要な条件を数値で（曲の長さ、遅れの秒数、操作の間隔、設定値）。 (b) 結論がコードに無い遅れや順序の仮定に依存するなら「仮定した経路」と明記する。 (c) 何が起きるか。 (d) 害: 使用者に見える結果を一文で。 裁定済みの残存リスク（再提起しない）: <一覧> 今回の焦点: <…> 要は (a) です。10 月 20 日の指摘にも数値は混じっていましたが、先頭に同じ形で揃えれば並べて比べられます。「2 秒の曲で確認が 1.7 秒遅れたら」と書いてあれば、素人の私でも「そんな曲、自分のプレイリストにある?」と確かめられます。確信度の数と違って、人が確かめられる記述です。 6. Codex の approve は実機の代わりにならない。 音や割り込みに触れる修正は、approve でも実機で触るまで「確認できなかった」と報告させる。 工程はフックで縛る 上の規則 1〜6 は、いまのところ文章だけです。仕分けや「2 回で止まる」は判断なので、機械では縛れません。 機械で縛れるのは工程の順番です。Claude Code の フック（ツール実行の前後に走るスクリプト）で、コード（Swift やプロジェクト設定）を含むコミットは、テストとレビューの記録が いまのコードに対して 無いと git commit を止め、Codex の記録が無いと main への git merge を止めるようにしました。記録は各工程が終わると自動で付きます。 止めるときはフックが JSON を返すだけです。 { "hookSpecificOutput": { "hookEventName": "PreToolUse", "permissionDecision": "deny", "permissionDecisionReason": "コミットのゲートで止めました: sim-test をいまのコードで流していません ..." } } 理由は Claude に見えるので、自分で工程を踏み直します。 抜け道は残しました。私が「ゲートを飛ばして」と言ったときだけ、コマンドの頭に環境変数を付けて通せて、ログに残ります。抜け道の無いゲートは、いずれ外されます。 書きながら分かったこと（Claude との対話） この記事の下書きを Claude と直しているときの対話を、短く整えて載せます（事実はあとで確かめ直しています）。最初の下書きには「プラグインが確信度を捨てている」という節がありました。 私: 確信度に数学的な絶対値がないなら、そもそも確信度っておかしいね。気分だよね。 Claude: ほぼそのとおりです。あの数は計算の結果ではなく、モデルが本文と同じ仕組みで、たとえば「0.7」という文字を生成しているだけです。このプラグインで「0.7 の指摘は 10 回中 7 回当たる」と確かめた資料は見当たらず、LLM が言葉で言う確信度は高めに出やすいという研究もあります。だから「確信度が表示されない」は論点として弱い。人が確かめられるのは、起きる条件の数値のほうです。 私: プログラムって論理的だと思ってたけど、こんなところでこういうアバウトな方針決定がされていて、うまく動いているのがすごいね。 Claude: 硬い部分と柔らかい部分に分かれています。スキーマは 0〜1 の数が無ければ出力を受け取らないし、フックは記録が無ければコミットを拒む。ここは本当に論理的です。でもその型の中身、「0.7」も「medium」も「2 秒の曲で 1.7 秒遅れたら」も、モデルがそれらしく生成したものです。型が守るのは「形が揃っていること」だけで、「中身が正しいこと」は守れない。うまく動いて見えるのは、硬い部分をどこに置くかを人が決めているからです。 私: 「型が守るのは形」って、ぎくっとした。でも私がプログラムするときも、形が揃っていたから出てきているだけで、その値が文脈の中で正しいかは別のところで確かめ直しているね。 Claude: その通りです。コンパイラは「Int のところに Int が入っているか」は見ても、「その Int が残り秒数として正しいか」は見ない。だからテストや実機で確かめ直す。同じ構造が一段上にもあっただけです。Codex の出力もフックも、形は揃っているけれど中身は保証しない。10 月 20 日に欠けていたのは、その「別のところ」、つまり仕分けの表と実機とあなたの裁定を、どこに置くか決めていなかったことでした。 ネットの情報と合っているか 記事にする前に、この対処が私の思いつきで終わっていないか Claude に調べてもらいました。 合っていたこと。 「終わりを先に決める、往復に上限を置く、残りは人が引き受ける」は、同じ結論の記事や提案がいくつもありました。 「バグを探せ」には終了条件が無いので、有能なレビュアーは必ず何か見つける。先に done を決めろ（DEV Community） 往復は PR あたり 3 回までを試し、超えたら人が「残存リスクを受け入れる／要件を詰める／分割する／明示的に続ける」から選ぶ、という提案（GitHub issue。2026-10-21 時点で未採用の試行案） 同じ種類の欠陥が 2 回却下されたら実装を止める（Greg Shevchenko） LLM が言葉で表す確信度は、高めに出やすい（Xiong et al., Can LLMs Express Their Uncertainty?, ICLR 2024） 数字（2 回、3 回）は慣習で規格ではありません。フックの書き方は公式リファレンス、approve の条件と確信度が印字されない件は、GitHub の main のプロンプト・render.mjs・スキーマで確認しました（いずれも 2026-10-21 確認）。 その後 翌日、残存リスクとして置いた判定を実機で確かめました。曲の自然終了（リピート設定で同じ曲が頭から鳴り直す）、3 分の境界、曲末直前の「次へ」の 3 つは通りました。 ただ、推定が外れうる経路（リピートが外れて別の曲が現れたときの自然終了）は、この日も一度も起きていません。残存リスクは残存リスクのままです。 実機で 2 つ気づいたことがありましたが、どちらも仕分け表で「残す」にしました。害が無いか、原因が分からないまま直さない方がよいものだったからです。レビューの往復は起きていません。 まとめ 敵対的レビューは「見つける」道具で、「終わり」を告げる道具ではない。 受け取る側が何も決めずに approve を待つ運用は、設計上終わらない 止まる条件はレビューされる側が持つ。 仕分け（直す／残す／捨てる）を人が決めて記録する。同じ一点に 2 回重なったら、3 回目は「このままでよいか」という問い 推定を含むコードは、直しても外れる場面が移るだけ。 残存リスクとして記録し、ログの手がかりを書いておく方が前に進む 確信度は気分、起きる条件は確かめられる。 指摘には「起きるのに必要な条件を数値で」書かせる。それなら素人でも確かめられる 型が守るのは形であって正しさではない。 スキーマもフックもコンパイラも、形しか見ていない。正しさを確かめる「別のところ」をどこに置くかは人が決める 工程はフックで止める。抜け道は残してログに記録する。 判断の規則は文章のまま、人が持つ 2 時間の往復は、この記事と仕組みになりました。次からは 2 回で止める決まりです。

@rezoundous I use it only with openai/codex-plugin-cc and in combination with an opus agent for code review before pushes. Had good results so far but Opus is carrying hard. Feel like I'm the one limiting this model, not the other way around.

設計・実装・複数AIレビューを1文で回す dev-orchestra を公開してみた はじめに 前回は、dev-orchestra を作った経緯を書きました。今回は、これが何をするもので、どんな人に向いているのかを紹介します。 - GitHub: istb16/dev-orchestra（MIT、1.0.0） - 動く場所: Claude Code / Codex / Antigravity のプラグインとして この連載では、このあと Claude Code・Codex・Antigravity それぞれでの使い方や、設定の詳しい話を順に書いていきます。この記事はその入口です。 > dev-orchestra は GitHub で公開しています（MIT ライセンス）。役に立ちそうと思ったら、スターを付けてもらえるとうれしいです。 > > → istb16/dev-orchestra 一言でいうと 1 文の依頼から、設計 → 実装 → テスト → 複数の AI による独立したレビュー → 指摘の仕分け → 修正 → 再テストまでを回すプラグインです。 この issue を設定済みのワークフローで実装して と話しかけると、dev-orchestra が依頼に必要な工程だけを選んで、順番に AI へ割り振ります。 !1文の依頼から最終報告までの流れ。設計（読み取り専用）、あなたによる承認、実装、テストのあと、差分を凍結して複数のレビュアーが並列・読み取り専用・互いの結果を見ずにレビューし、重複を統合してトリアージする。採用した指摘だけを修正し、再テストして最終報告する | 工程 | 担当 | ポイント | | --- | --- | --- | | 設計 | architect | 調べて計画を書く。読み取り専用で、あなたが承認するまで実装に進まない | | 実装 | implementer | 計画からコードとテストを書く | | レビュー | reviewers | 2 つ以上の AI が、凍結した同じ差分を、互いの結果を見ずに読む | | トリアージ | orchestrator | 重複をまとめ、指摘を採用・却下・重複に仕分ける | | 修正 | review_fixer | 採用した指摘だけを直す | typo の修正なら編集だけ、スキーマの変更なら全部、というように、動く工程は依頼の大きさで変わります。 なぜ別の AI にレビューさせるのか AI は、自分が書いたコードのレビューが苦手です。バグを生んだ思い込みを、レビューするときもそのまま持っているからです。 互いの意見を知らない状態で同じ差分を見た別々の AI は、ときどき意見が食い違います。その食い違いが、本物のバグのありかになります。 もう 1 つ大事なのが、レビュー結果をそのまま修正に回さないことです。複数の AI の指摘は重複しますし、的外れなものも混ざります。全部を「直して」と渡すと、要らない変更が量産されます。そこで dev-orchestra は、指摘を機械的にまとめたうえでトリアージし、採用したものだけを修正役に渡します。 公式の codex-plugin-cc との違い 「Claude Code から Codex にレビューさせる」だけなら、OpenAI 公式の codex-plugin-cc があります。手軽さでは向こうが上なので、違いを正直に並べます。 | | codex-plugin-cc | dev-orchestra | | --- | --- | --- | | 提供 | OpenAI 公式 | 個人の OSS | | 動く場所 | Claude Code | Claude Code / Codex / Antigravity | | レビューする AI | Codex | 2 つ以上を並列（Claude / Codex / 自作。Antigravity は限定対応） | | 扱う範囲 | レビューと、Codex への作業の委任 | 設計からレビュー・修正・再テストまで通しで | | 指摘の扱い | 結果を Claude Code に返す。任意の review gate を有効にすると、問題があれば Claude に対応させる | 重複統合 → トリアージ → 採用分だけ修正 | | 始めやすさ | スラッシュコマンドですぐ使える | 最初にプリセットを選ぶ | | 便利な機能 | バックグラウンド実行、狙いを指定する批判的レビュー、Codex への会話の引き継ぎ | 計画の承認、レビューの往復の上限、トークンの記録 | 公式プラグインの review gate は、/codex:setup --enable-review-gate で有効にできます。Claude が応答を終えようとすると Codex がレビューし、問題が見つかれば終了を止めて、Claude に先に直させます。自動でレビューして直させるだけなら、これでも十分です。 > README には、review gate は往復が続いて利用枠を使い切るおそれがある、という注意があります。 違いは、レビュアーの数と指摘の扱いです。review gate のレビュアーは Codex 1 つです。dev-orchestra は複数のレビュアーの指摘を突き合わせ、重複をまとめてトリアージし、採用したものだけを直します。 使い分けの目安はこうです。 - Claude Code での作業に、Codex のセカンドオピニオンを 1 つ足したい → codex-plugin-cc - 開発の流れ全体を、複数の AI で回したい → dev-orchestra 対応している CLI dev-orchestra は、手元に入っている AI の CLI をそのまま使います。API キーは要りません（各 CLI のログインを使います）。 | | Claude Code | Codex | Antigravity | | --- | --- | --- | --- | | プラグインとして入れる | ○ | ○ | ○（リンクで導入、再起動が必要） | | 実装・修正の役 | ○ | ○ | ○（テストを走らせるには設定が要る） | | 設計・レビューの役 | ○ 読み取り専用を CLI が強制 | ○ 読み取り専用のサンドボックス | △ 読み取り専用を強制できないので、警告付きの限定対応 | | 設計の続きから再開 | ○ | ○ | × | Claude Code と Codex は全部の役をこなせます。 Antigravity は実装・修正向けで、設計やレビューに置くこともできますが、ファイルを書き換えられる状態で動くことになります。くわしい違いは、それぞれの使い方の回で書きます。 Claude Code だけでも使う意味はあるか 「複数の AI」と言われると、Claude Code しか使っていない人には関係なさそうに見えます。でも、Claude Code だけでも使う意味はあります。 !Claude Code だけの構成と、Claude Code と Codex の構成の比較。レビュアーは例として2つずつ描いていて、実際の人数と役割はプリセットで決まる（Claude Code だけの standard では4人）。どちらも別プロセスでのレビュー、CLIによる読み取り専用の強制、トリアージは同じ。Claude Code だけでは同じ系列なので思い込みが似やすく、Codex を足すとベンダーが違うので思い込みも違うが、コードが2社に送られる | Claude Code だけでも得られること | なぜ効くか | | --- | --- | | レビュアーは別プロセスで、実装したときの会話を持ち込まない | 「さっき自分でこう決めた」という前提なしにコードを読める | | 読み取り専用を CLI が強制する | 「書き換えないで」とお願いするだけでは守られないことがある | | 役割ごとにモデルを分けられる | 設計は強いモデル、安く済ませたいレビューは軽いモデル、と費用をかけ分けられる | | トリアージで採用した指摘だけを直す | 要らない修正が入らない | | 必要な工程だけ動き、記録が .ai/ に残る | 小さな依頼は軽く、大きな依頼は計画やレビューを後から読み返せる | プリセットを選ぶと、そのマシンに入っている CLI に合わせて構成が決まります。Claude Code しか入っていなければ、レビュアーも Claude だけで組まれます。 とはいえ、いちばん効くのは別ベンダーの AI を混ぜたときです。同じ系列のモデルどうしは、思い込みも似やすいからです。Codex も使える人は、ぜひ 2 社構成で試してみてください。 メリットとデメリット | メリット | デメリット | | --- | --- | | 自分では気づけないバグが見つかる | 実行時間とトークン消費が増える（AI を何度も呼ぶため） | | 運び屋の作業（コピペと待機）がなくなる | 指摘のトリアージは要る（オーケストレーターがやるが、最後に確認するのはあなた） | | 要らない修正が入らない | レビュアーが読んだコードが、登録した各ベンダーに送られる（差分だけとは限らない） | | 計画やレビューの記録が残る | 最初にプリセットを選ぶなど、導入の手間が少しある | 特に 3 つ目のデメリットは気にしておいてください。Claude と Codex でレビューすれば、コードは Anthropic と OpenAI の両方に送られます。 送られるのは差分だけではありません。レビュアーは差分のまわりを調べるために、リポジトリ内のファイルを読めます。読み取り専用でも、Claude でも Codex でも、.env のようなファイルまで読めます。しかも Claude の場合は、自分で書いた permissions.deny もレビュアーには効きません。理由と対策（ルールを managed settings に移す）は、次の Claude Code の回で書きます。 外に出せないコードを扱うなら、ローカル LLM だけでレビューを組むこともできます。ただしそのときは、Claude Code などのクラウドの AI から dev-orchestra を呼ばないでください。呼び出し元の AI 自身がコードを読むので、そこからクラウドに出ていきます。ターミナルから直接実行し、--only でレビュアーをローカル LLM に絞ります。くわしくは以前の記事に書きました。 > トークンの消費を抑える仕組み（小さな変更はレビュアーを減らす、2 回目のレビューは修正分だけ、など）は入っていますが、1 つの AI で済ませるよりは確実に増えます。まずは小さな依頼から試すのがおすすめです。 使い方 インストールは Claude Code なら 2 行です。 claude plugin marketplace add istb16/dev-orchestra claude plugin install dev-orchestra@dev-orchestra Codex や Antigravity での入れ方、初期設定、各コマンドの説明は、GitHub のドキュメントにまとめています。最新の情報はこちらが正です。 - README（日本語） — インストール、初期セットアップ、使い方 - ワークフロー — 各工程で何をするか、ワークフローの例 - 設定 — プリセット、モデル、レビュアーの組み方 まとめ - dev-orchestra は、1 文の依頼から設計・実装・複数 AI のレビュー・修正までを回すプラグイン - レビュアーは凍結した同じ差分を、読み取り専用で、互いを見ずに読む。指摘はトリアージして採用分だけ直す - Codex のセカンドオピニオンを 1 つ足すなら公式の codex-plugin-cc、開発の流れ全体を回すなら dev-orchestra - Claude Code と Codex は全部の役、Antigravity は実装・修正向け（設計・レビューは限定対応） - Claude Code だけでも、別プロセスのレビューとトリアージで意味がある。いちばん効くのは別ベンダーを混ぜたとき - デメリットは時間とトークン、そしてコードが各ベンダーに送られること。レビュアーは差分以外のファイルも読める - 機密のコードは、ターミナルから直接、ローカル LLM だけでレビューする 次回からは、Claude Code・Codex・Antigravity それぞれで実際に使ってみます。 GitHub: istb16/dev-orchestra（スターを付けてもらえると励みになります） この連載の記事は、「dev-orchestra」の一覧でまとめて読めます。 > この記事は tk3.biz のブログ からの転載です。

我居然才发现，Codex 官方给 Claude 做的插件这么好用？？？ openai/codex-plugin-cc GPT-6 Astra 写代码感觉太过度设计，但它的工程能力和 debug 是真的强，拿来 review 无敌： 1、/codex:review Claude 写完，Astra 审你还没提交的改动，问题按严重程度排好，带文件和行号。想审整个分支也行。 2、/codex:adversarial-review 专门质疑方案的，后面还能跟一句重点，比如"重点看并发和回滚"，最后直接给结论：能不能上线。 3、/codex:rescue 把活丢给 Codex 干。需求明确的固定功能、Claude 卡住的 bug，直接甩过去，它改完还会自己跑一遍验证。 当然，不止这几个，其他也都挺好用，插件 3 月就出了，我居然现在才用上😂

I just starred openai/codex-plugin-cc on GitHub: openai/codex-plugin-cc