エージェント界隈で何かが「増える」話はよく見かけますが、「測った上で削った」話はほとんど見かけません。今回はその珍しいほうです。
obra/superpowers の v5.0.6（2026年3月24日）で、brainstorming スキルからサブエージェントによるレビューループが削除されました。リリースノートによれば、計画やスペックのレビューに別エージェントを起動する方式は実行時間を約25分増やす一方、5バージョン × 各5試行の回帰テストで品質スコアに差が出なかったとのことです。代わりに入ったのは、同じエージェントがその場で自分の成果物を見直すチェックリストでした。
最初に立場を書いておきます。私たちは Skillselion という独立系のエージェントスキル・MCPサーバーのカタログを運営しています。Anthropic、OpenAI、Cursor、Claude、Claude Code、Codex のいずれとも資本・提携関係はありません。この記事は Brainstorming スキルのページ に載せているディープダイブ（SKILL.md を節ごとに引用して読む連載）から起こしたものです。ただし、そのディープダイブは2026年8月20日に v6.3.0 を対象に書いたもので、その後 v6.4.1（リリースノートの日付は2026年9月18日）で承認ゲートが書き換わりました。ページ上のディープダイブは改訂前の文言のままなので、本記事の引用はすべて現行ファイル（コミット 8ca22db）から取り直しています。
なお、引用は原文が英語なので英語のまま載せ、日本語で要点を添えます。
v5.0.6 で何が消えたのか
The subagent review loop (dispatching a fresh agent to review plans/specs) doubled execution time (~25 min overhead) without measurably improving plan quality. Regression testing across 5 versions with 5 trials each showed identical quality scores regardless of whether the review loop ran.
Source: RELEASE-NOTES.md, v5.0.6（2026年9月27日に確認）
研究として見れば小さな規模の実験です。それでもこの分野の相場からすると異例に丁寧で、しかも「いかにも効きそうな設計」のほうが負けています。作者が自分のワークフローに回帰テストを回して、結果に従って手の込んだ側を捨てた、という点がこの記事の主題です。
代わりに何が入ったのか
同じターン内で、同じエージェントが自分の書いたスペックを読み直すチェックリストです。
After writing the spec document, look at it with fresh eyes:
Source: skills/brainstorming/SKILL.md 247行目（2026年9月27日に確認）
項目は4つで、TBD などのプレースホルダー検出、セクション間の矛盾チェック、スコープの確認、曖昧さの確認です。4項目とも、エージェントが自分の文章に答える質問の形です。特に効くのは後半の2つです。
Is this focused enough for a single implementation plan, or does it need decomposition?
Could any requirement be interpreted two different ways? If so, pick one and make it explicit.
Source: skills/brainstorming/SKILL.md 251行目と252行目（2026年9月27日に確認）
そしてコストを決めているのが、チェックリスト直後の一文です。
Fix any issues inline. No need to re-review [...]
Source: skills/brainstorming/SKILL.md 254行目（2026年9月27日に確認）
再レビューなし、反復上限なし、収束ループなし。旧設計にあったサブエージェント起動と3回までの反復は両方とも消えました。リリースノートは削ったコストと同じ単位で効果も書いていて、"Self-review catches 3-5 real bugs per run in ~30s instead of ~25 min, with comparable defect rates to the subagent approach" となっています。
消えなかったのは何か
人間の承認です。ファイル冒頭近くの HARD-GATE ブロックに置かれています。
Before taking any implementation action, including invoking an implementation skill, writing product code, scaffolding, installing product dependencies, or creating an external project, complete the selected path's prerequisites:
A reply approves the stage actually presented. Approval of an idea or feature scope does not approve artifacts that do not exist yet.
Source: skills/brainstorming/SKILL.md, hard gate（2026年9月27日に確認）
承認ゲートはすべてのパスにかかりますが、何を承認するかはパスごとに決まっています。Spike は問いと試す内容、Bounded はチャット上の短い設計、Architectural は書面のスペックとその後の実装計画です。なお v6.4.1（2026年9月18日）より前、このブロックには「承認ゲートはタスクの重さで変わらない」と書かれていましたが、現在は重いパスほど承認の段階が増え、返答が承認するのは実際に提示された段階だけだと明記されています。この1ファイルの中に、性質の違う2種類のルールが同居していることになります。片方は計測で効果なしと判定されて消え、もう片方は人間の判断を守るものなので、そのまま残りました。自分のツールについてこの区別がつく状態は、正直あまり見かけません。
なぜパスは上にしか動かないのか
このスキルは最初の質問より前に、依頼を Spike（実現可能性の確認で、コードは捨てる前提）、Bounded（リポジトリに既にある流れへの限定的な変更）、Architectural（新規サブシステムやインターフェース変更）のどれかに分類します。分類は宣言させる決まりで、利用者が上書きできます。
Bounded には形容詞ではなく判定条件が付いています。"If there is no existing flow to change, the task is not bounded."
Source: skills/brainstorming/SKILL.md 74行目から75行目（2026年9月27日に確認）
新規機能を「頭の中で形が見えているから小さい」と判断してしまう事故を、この1文が塞いでいます。
パス間の移動は片方向だけです。
When in doubt between two paths, take the heavier one. The ratchet is one-way: hidden complexity discovered mid-task upgrades the path [...] Nothing downgrades mid-task.
Source: skills/brainstorming/SKILL.md, path selection（2026年9月27日に確認）
降格を許すと、詰まったエージェントは必ず降格の理由を見つけます。軽いパスこそが作業を始めてよい場所だからです。選択肢を消せば動機も消えます。
小さな変更なら承認は要らないのでは
そう考えたくなるところは、スキル側がアンチパターンとして名指しで潰しています。
Every path ends with your human partner approving the required design before implementation. A bounded change may need only two sentences in chat. A new todo-list project is architectural and requires the written spec and planning handoffs.
Source: skills/brainstorming/SKILL.md 92行目から95行目（2026年9月27日に確認）
チャットに2文書いて返事をもらう、それで承認として成立します。縮むのは成果物のほうで、ゲートは縮みません。設定ファイルの1行修正のつもりが3ファイル書き換わっていた、という経験がある人には効きどころが分かると思います。
サブエージェントを否定しているのか
していません。ここは都合よくまとめないでおきます。同じパックには subagent-driven-development スキル があり、私たちのカタログでは2026年9月7日時点で197,517インストールです。作者はサブエージェント自体をやめたわけではありません。こちらは承認済みの計画をタスク単位で実行する役割で、v5.0.6 が削ったのは実装前の計画やスペックを採点するサブエージェントです。同じ単語ですが仕事が違います。
持ち帰る価値があるのは手順のほうで、レビュー工程に時間を計り、いちばん安い代替と比べて、結果に従うという習慣です。
数字で見る brainstorming
- brainstorming: 353,451インストール（2026年9月7日時点）。
- 同じパックの次点:
systematic-debuggingが250,011、writing-plans の個別ページ が241,042、using-superpowersが236,937。 - リポジトリ本体: 2026年9月27日時点で GitHub スター292,010、フォーク26,133、MITライセンス。
インストール数の出典は Skillselion カタログの各スキルページ（2026年9月7日時点のデータ）、スターとフォーク数は2026年9月27日の GitHub API です。
まとめて見るなら obra/superpowers のパック一覧 が早く、個別には Systematic Debugging スキル と Test Driven Development スキル も同じ系統の作りです。周辺を広く見たい場合は テストとレビュー向けスキルのカテゴリ と 開発ツール向けスキルの厳選リスト をどうぞ。
FAQ
これは Anthropic 公式のスキルですか
いいえ。obra/superpowers はコミュニティ製の MIT ライセンスのリポジトリです。Skillselion も独立したカタログで、Anthropic とも他のベンダーとも提携していません。
計画のレビュー自体が無意味だという話ですか
無意味と判定されたのは特定の実装方式だけです。置き換わったチェックリストもレビューには違いなく、同じエージェントが4項目で自己点検します。計測が削ったのは2体目のエージェントと25分であって、確認する行為そのものではありません。
軽い依頼でも毎回スペックを書かされますか
いいえ。いちばん軽い Spike パスでは、何を試すかを2、3文で提示して合意を取ればそのまま進みます。スペックファイルや実装計画のドキュメントは重いパスの持ち物です。
全文はどこで読めますか
brainstorming の個別ページ のディープダイブ欄に、節ごとの読み解きを載せています（2026年8月20日に v6.3.0 を対象に書いたもので、ゲートの文言は改訂前のままです。最新の文言は上の GitHub リンクで確認できます）。手順ベースの解説は Claude Code スキルのガイド集、公開後にスキルがどれだけ保守され続けるかは エージェントスキルのメンテナンス実態調査 にまとめてあります。
最終更新: 2026年9月27日。本文の引用はすべて、コミット 8ca22db 時点の obra/superpowers の原文と文字単位で突き合わせて一致を確認しました。skills/brainstorming を最後に変更したのは v6.4.1 のリリースコミット 5bf4e78（UTC 2026年9月19日。リリースノート上の日付は2026年9月18日）です。インストール数は各所に記した日付時点の Skillselion カタログの値です。