「話題のSkill検証」では、実物のコードやドキュメントを取得し、動かさずに読み込んだうえで内容を報告します。今回はSuperpowersを取り上げます。
Superpowersとは何か
Superpowersはhttps://github.com/obra/superpowersで公開されているリポジトリです。作者はJesse Vincent氏で、同氏が所属するPrime Radiantが開発しています。GitHub上のリポジトリ説明は「An agentic skills framework & software development methodology that works.」で、Claude Code、Codex、Cursor、Gemini CLIなど複数のコーディングエージェントに対応するプラグインとして配布されています。
編集部でGitHub APIから直接取得した数値では、スター数は26万を超え、フォーク数も2万を超えていました。この規模の反響が実際に集まっている点は確認できましたが、なぜここまで広まったのかについては、リポジトリの記述だけから断定できる材料がないため、本記事では踏み込みません。
中身を読んでわかったこと
リポジトリのskills/ディレクトリには14個のSkillが並んでいました。brainstorming、using-git-worktrees、writing-plans、subagent-driven-development、executing-plans、test-driven-development、requesting-code-review、receiving-code-review、finishing-a-development-branch、systematic-debugging、verification-before-completion、dispatching-parallel-agents、writing-skills、using-superpowersの14種類です。
README.mdが説明する基本フローは次の順番で進みます。brainstormingが要件を対話で引き出し、using-git-worktreesが作業用のブランチを用意し、writing-plansが2分から5分単位の細かいタスクに分解し、subagent-driven-developmentまたはexecuting-plansがタスクごとにサブエージェントを起動し、test-driven-developmentがRED-GREEN-REFACTORの手順を強制し、requesting-code-reviewとreceiving-code-reviewがタスク間のレビューを担い、finishing-a-development-branchが完了時のマージ判断を行います。ひとつのSkillが一機能ではなく、開発プロセス全体を一つの流れとして設計している点が特徴です。
実際のSKILL.mdを読むと、書き方に共通する型がありました。まずusing-superpowersは、Skillが少しでも当てはまる可能性があれば必ず使うよう指示しています。原文は次のとおりです。
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
（Skillが当てはまるなら、使うかどうかの選択権はない。必ず使わなければならない、という意味です。)
systematic-debuggingとtest-driven-developmentも、同じ強さの言い切りを冒頭に置いています。
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
（根本原因の調査より先に修正してはならない、というデバッグの絶対原則です。)
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
（失敗するテストを先に書かない限り、本番コードを書いてはならない、というTDDの絶対原則です。)
当メディアのSkill大全第3章では、Skillに持たせるべき要素として完了条件、判断基準、やらないことの3点を挙げています。Superpowersの各SKILL.mdを見ると、この3点は別々の節としてではなく、絶対原則（Iron Law）、言い訳と現実を対にした表、危険信号（Red Flags）という3つの仕掛けに姿を変えて組み込まれていました。絶対原則が完了条件とやらないことを兼ね、言い訳の表と危険信号が判断基準の役割を果たす構成です。
うまいと感じた設計
もっとも感心したのは、test-driven-developmentやsystematic-debuggingに置かれている「言い訳と現実」の対応表です。「もう手動テスト済みだから」「今回だけは例外」といった、エージェントが実際に口にしそうな言い訳を先回りして列挙し、それぞれに反論を用意しています。判断基準を抽象的なルールとしてではなく、想定される抜け道への個別の反論として書く方法は、実運用で規律が崩れる場面を具体的に想像しないと書けない内容でした。
writing-skills自体がTDDの考え方をSkill執筆に転用している点も一貫しています。Skillを書く前に、そのSkillなしでエージェントがどう失敗するかを先に観察し、その失敗の言い方をそのまま言い訳の表に反映させる手順が明記されていました。Skillの正しさを検証してから配布するという発想は、当メディアが繰り返し伝えてきた「検証してから公開する」という原則と重なります。
他のSkillを参照する際の書き方も丁寧でした。@によるファイル強制読み込みを避け、Skill名と「REQUIRED BACKGROUND」のような明示的なマーカーで必須度合いを伝える方式を採用しています。理由として、@参照は必要になる前からコンテキストを消費してしまうと明記されていました。参照の要否を曖昧にしないための具体的な工夫です。
疑問が残った点
絶対原則という書き方の強さが、そのまま柔軟性の乏しさにもなっている点は気になりました。「例外なし」「これは違う」という理由づけをすべて言い訳として却下する設計は、規律を守らせる場面では効きますが、本当に例外的な状況に直面したときにエージェントが立ち止まりにくくなる可能性があります。3回目の修正が失敗したら設計を疑うという基準はある一方、それ以外の場面で原則から外れてよい条件はほとんど書かれていません。
using-superpowersは、単純な質問や確認作業に対してもSkillの確認を挟むよう求めています。簡単な作業でもSkillを起動する前提のため、タスクの規模に関わらず毎回同じ確認手順が挟まる設計です。軽い作業まで一律に同じ重さの手順を通す点は、効率と厳密さのどちらを優先するかで評価が分かれそうです。
もう一点、README.mdにはPrime Radiantのロゴ画像を通じた利用状況の把握について記載がありました。プロジェクトやプロンプトの内容は送信しないとされていますが、既定で有効になっており、環境変数での明示的なオプトアウトが必要な仕様です。この点は導入前に把握しておく価値があります。
導入を検討する人へ
今回の記事はリポジトリの構成とSKILL.mdの書き方を精読した結果であり、実際にエージェントへ組み込んで動かした検証ではありません。実運用でどう振る舞うかは、別の記事で改めて報告する予定です。
そのうえで言えるのは、14個のSkillを一括で導入する前に、自分たちの開発フローのどこに問題があるかを先に特定したほうがよいということです。デバッグが場当たり的になりがちならsystematic-debuggingだけ、テストを書かずに進めがちならtest-driven-developmentだけを取り込むほうが、全体の厳格な運用ルールに合わせて開発プロセスそのものを作り直すより、はじめの負担は小さくなります。