PRスキル集 · tstack

PRを作って「council」と言うだけ。別々の会社の3つのAIが納得するまで、エージェントが自分で直し続けます

Claude CodeやCodexでPRを作ってから「council」と呼ぶと、会社の異なる3つのAIがコードを読むだけの立場で10点満点の採点をします。自分のエージェントは指摘を直して再びレビューを受け、ラウンドごとの点数はPRの説明に表として残ります。councilは、Theoが公開したPRスキル集tstackに入っています。公開から2日で、ほかの開発者が自分のリポジトリで使い、マージまで進んだPRを集めました。PRにtstackという名前はありませんが、残された点数表の形式で見分けられます。

2026年10月26日·事例 3件

T3 Codeの画面。「Consult council to make sure this is safe. Merge it once they're happy.」という依頼の下で「Council: PR #31 safety (Opus) / (Muse) / (Sol) Running」の3行が動き、エージェントが3つとも安全だと言ったらマージすると答えている場面 — Theoがcouncilを初めて紹介したXの投稿に添えた画面です。出典: Theo Browne X

Theo Browne — I wrote a "council" skill …, 2026-10-23(10月26日時点で表示180,540 · ブックマーク1,714 · 返信412)

t3dotgg/tstack — The agent skills I use every day(10月26日時点でスター103個)

tstack council SKILL.md

10月23日、登録者57万人の開発系YouTuberで、T3 CodeとT3 Chatを作った会社のCEOでもあるTheo BrowneがXに投稿しました。"I wrote a \"council\" skill that makes my agent argue with Opus 5.5, Muse Wonder Full and GPT-6.1 Sol before it is allowed to merge"(マージを許す前に、自分のエージェントをOpus 5.5、Muse Wonder Full、GPT-6.1 Solと議論させるcouncilスキルを書いた)。10月26日までに表示18万回、ブックマーク1,714件が付きました。返信には"Give me the council skill please"(そのスキルください)や"Have you released this council skill publicly?"(公開しましたか?)が並びました。

翌日、Theoは毎日使っているスキルをtstackというリポジトリで公開しました。リポジトリのスターは10月25日の38個から26日には103個に増えました。そして公開から2日で、ほかの開発者が自分のリポジトリでcouncilを回し、マージまで進んだPRが出てきました。

tstackにはPRスキルが9つ入っています。councilのほかに、CIやレビューボットを通るPRを見守って本当の指摘だけを直すbabysit、人がマージできる状態で止まるfull stop、誰も見ていなくてもマージまで持っていくfull sendがあり、スキル同士が互いを呼び出して使います。Claude CodeとCodexで動きます。

councilは、会社の異なる3つのAIを委員に据えます。委員はコードを読むだけで10点満点の点数をつけ、直す作業は自分のエージェントが担当して、3つが納得するまで再レビューを受けます。レビューを重ねるあいだにPRが膨らまないよう抑えるのもエージェントの役目で、ラウンドごとの点数はPRの説明に表として残ります。

Reference 01Bitwardenの保管庫をバックアップするツールvault-mirrorを作るNikita Maximilian Grimm · GitHub

バックアップツールのエラー表示が、何を確認し、どのオプションを渡せばいいかまで教えてくれるようになりました

PRにtstackという名前は書かれていませんが、残された点数表の形式は10月25日にtstack councilに加わったものと同じです。このPRが直したのは、設定や復旧の途中でエラーが起きたときにターミナルに出る案内です。バックアップフォルダーがないときのエラーは、次のように変わりました。

変更前: error: opening backups/run.lock for recovery; copy BACKUPS_DIR to a writable directory or retain run.lock when copying backups: No such file or directory (os error 2)
変更後: error: no backup directory at backups; check BACKUPS_DIR or pass --env-file vault-mirror.env: No such file or directory (os error 2)

今では、バックアップフォルダーがないという事実と一緒に、確認すべき設定(BACKUPS_DIR)と渡すオプション(--env-file)をすぐに示します。警告とエラーは別々に出るようにし、ヘルプは単語単位で改行するように直しました。

委員はClaude Opus 5.5とGPT 6.1 Solで始まり、4ラウンド目からGPT 6 Astraが加わりました。標準の「会社の異なる3つ」とは違い、GPTが2つ入った構成です。Opusの点数は8 → 9.5 → 10と上がったあと、5ラウンド目で8.5に下がりました。そのときNikitaが、レビューの範囲をターミナル表示の品質とドキュメントにまで広げたためです。7ラウンド目で、3つの委員がすべての項目に10点をつけました。

繰り返しは約59分で終わりました(決めておいた上限は150分でした)。委員は読むだけで、指摘を確かめて直したのはリードエージェントです。256個のテストが実際に走り、23個のCIを通過して10月26日にマージされました。

ターミナル出力の変更前後の比較。上の「BEFORE Hard wrapping; no corrective action」では通知失敗の警告が行末で切れ、下の「AFTER Clear continuation and next action」では「Check NOTIFY_SUCCESS_URL and the notification service.」まで整って続いている — 通知失敗の警告です。以前は行末で切れていましたが、今は「Check NOTIFY_SUCCESS_URL and the notification service.」(通知先と通知サービスを確認してください)という次にやることまで付きます。PRに添えられた画像は、ターミナル出力を描き直したものです。

ヘルプ画面の変更前後の比較。「Safety explanations split at the edge」ではオプションの説明が単語の途中で切れ、「Whole words and aligned continuations」では単語単位で改行され、続く行もそろっている — ヘルプのオプション説明です。単語の途中で切れていた行が単語単位で改行されるようになり、続く行もそろいます。

Reference 02Hermesエージェント用のiPhoneアプリhermexを作るUzair Ansar · GitHub

アップデート後に止まったiPhoneアプリのチャット画面を、3社のAIによる5ラウンドのレビューを経てエージェントが直しました

hermexは、Hermesエージェントと会話するためのiPhoneアプリです。ホスト側のhermes-agentが0.22.3に上がってから、ホストがBot Chatを新しいものに置き換えると、アプリのチャット画面が"The conversation identity changed. Check this bot in Desktop."(会話の識別子が変わりました。デスクトップでこのボットを確認してください)で止まっていました。このPRで、アプリは新しいBot Chatに追従し、変わったことを知らせる案内を表示するようになりました。

委員はClaude Opus 5.5、GPT-6.1 Sol、Gemini 4 Argonで、3社のモデルがそろって委員になりました。5ラウンドのあいだに、Opusは8 → 9、GPT Solは6 → 8、Geminiは6.5 → 10と点数を上げました。

点数以外の検証も付いています。指定したテスト234個がすべて通り、文字列カタログのキー2,489個をすべて確認しました。iPhone 17向けのビルドを実際のHermesホストにつなぎ、もともと動いていた経路がそのまま動くかも確かめています。6個のCIを通過して10月26日にマージされました。

Reference 03開発元の公式デモ · tstackを作ったTheo Browneが、自社製品T3 Codeに出したPR

コードを書く前から3つのAIに何を削るかを聞いたら、スレッドを開くときに読み込むデータが85%減りました

Theoは自社製品T3 CodeのPRで、コードを書く前からcouncilを呼びました。原文はこの段階を「round 0」と書いていて、何を減らすかはこのときcouncilが決めました。councilは、スレッド本文のデータはスレッドを開くときに受け取る量の1〜8%だと見て、折りたたまれた行をあとから読み込む方式はプロトコルを増やすほどの価値がないと判断しました。

Theoが示した計測では、実データのコピー(スレッド325件)でスレッド7件を開いたときに受け取ったデータが、合計8,528KBから1,296KBへと85%減りました。サブスレッドが71件付いたスレッド1件は、3,046KBから293KBになりました。3つの委員(Claude Opus 5.5、Muse Wonder Full、GPT-6.1 Sol)の点数は4ラウンドのあいだに7〜8点から9〜9.5点に上がり、PRは10月25日にマージされました。

冒頭の画面は、Theoが別のPR(#31)でcouncilを呼んだ場面です。1行の依頼で3つの委員が同時にレビューを始め、エージェントは3つとも安全だと言ったときだけマージすると答えています。

Theoが冒頭の画面で送った依頼

Consult council to make sure this is safe. Merge it once they're happy.

マージを自分でするなら、最後の文を外します。

みんなの反応

よかったという声

“Declined as scope creep after the bar was met: recolouring Python's annotation `:` / `->` cyan to match TS.”
基準を満たしたあとは範囲の広がりとして見送り: Pythonの型注釈の`:` / `->`をTSに合わせてシアンに塗り直すこと。
自分のVS Codeテーマをcouncilのデザインレビュー4ラウンドで直したPRの本文に残った一文です。
Abraham Prince · GitHubgithub.com
“Why not adding gemini with no weight in the decision just to make fun of his decision 😂”
Geminiも判断には影響させずに入れて、その判断を笑いものにするのはどう 😂
Theoが"I hate how much I like this idea."(このアイデアをこんなに気に入ってしまうのが悔しい)と返し、自分のcouncilに、点数に数えないゲスト委員としてGeminiを入れました。このゲスト席は、公開されたtstackにはありません。
Jonathan Delaire · Xx.com
“一个 AI code review 小习惯：别只让一个模型审。”
AIコードレビューの小さな習慣：1つのモデルだけにレビューさせないこと。
Theoのcouncilを紹介した投稿です。
zZ · Xx.com

物足りなかったという声

“Scores are subjective overall quality within scope; they do not replace verification.”
点数は範囲内での全体的な品質を主観的に評価したもので、検証の代わりにはならない。
councilを7ラウンド回してマージした自分のPRに書いた言葉です。
Nikita Maximilian Grimm · GitHubgithub.com
“Claude Opus and Gemini were satisfied by round 5. GPT Sol's last two findings were left out of scope, each a multi-step edge chain”
Claude OpusとGeminiは5ラウンド目で納得した。GPT Solが最後に挙げた2つの指摘は範囲外として残した。どちらも複数の段階を経て起きる境界ケースだ。
GPT Solは8点で止まり、PRはそのままマージされました。
Uzair Ansar · GitHubgithub.com
“Gemini Pro was not reached: its provider is disabled in T3 Code, and the council does not substitute seats.”
Gemini Proには届かなかった。T3 Codeでそのプロバイダーが無効になっており、councilは空いた席を別のモデルで埋めない。
そのため、4ラウンドを通して委員は2つだけでした。
Abraham Prince · GitHubgithub.com
“In your council skill, do reviewers see each other's findings, or review independently first? For multi-model reviews, we're interested in whether sequential critique catches more real bugs or just amplifies the first plausible false positive.”
councilスキルでは、レビュアーはお互いの指摘を見るのでしょうか、それともまずそれぞれ独立にレビューするのでしょうか。複数モデルのレビューで、順番に批評させると本物のバグをより多く見つけられるのか、それとも最初に出たもっともらしい誤検知を増幅するだけなのかに関心があります。
Nex41 · Xx.com

はじめ方

Claude CodeかCodexに、下の依頼を貼り付けるだけです。GitHub CLI(gh)にログインしている必要があり、委員を3つともそろえるには、ほかの会社のモデルを呼び出せる環境(T3 Codeや各社のAPI)が必要です。

はじめの依頼
https://www.working-ref.com/ja/reference/tstack-council-2026-10 の記事を読んで、https://github.com/t3dotgg/tstack のスキルをこの環境にインストールして。まずghにログインできているか、council委員として呼べるモデルが何かを確認して教えて。そのあと、私のリポジトリでcouncilを試す価値がありそうな作業を3つ提案して。私が1つ選んだらすぐ始めて、選ぶものがなければ今のブランチの変更でPRを作って、まずcouncilのレビューを受けて。マージは自分でするから、マージの直前で止めて。

このリファレンスを共有

毎週1回・無料

このリファレンスは役に立ちましたか？

毎週あふれるAIニュースから
BEST 3つだけ、受信箱へ

Work Smarter with AI

購読完了次号から受信箱でお会いしましょう。