- ここ数週間で、Claude Codeベースのコーディングエージェントシステムを体系化し、「Superpowers」という新しい拡張ツールを作った
- Superpowersはプラグイン形式でインストールされ、Claudeに「スキル（Skills）」を教え、このスキルを通じて作業方式を自動化・改善する機能を提供する
- AnthropicのClaude Codeプラグインシステムを活用し、ワークフロー自動化、TDD実行、コードレビュー、Git worktree管理などをエージェントが自律的に実行する
- 新しいワークフローはブレインストーミング → 計画 → 実装の段階を自動で経て、作業を並列に進め、RED/GREEN TDD方式でテスト駆動開発を行う
- 中核概念である**「スキル（Skill）」**は、Claudeが特定の作業を行う際に参照すべき知識単位であり、ユーザーはこれを直接作成したり、Claudeが学習文書をもとに生成するようにできる
- この構造は今後AIコーディングエージェントの自己改善と協調の標準になると見ており、Superpowersの共有機能と記憶システムの完成が次の目標
Superpowers概要
- SuperpowersはClaude Code 2.0.13以上で動作し、ユーザーは
/plugin marketplace add obra/superpowers-marketplaceコマンドでインストール可能
- インストール後、Claudeが自動で
SKILL.md文書を読み、**「スキルが存在するなら必ず使わなければならない」**というルールを学習する
- これによりClaudeはブレインストーミングと計画段階を経て実装前の議論を促し、作業完了後にはGitHub PRの作成またはマージ提案まで行う
コーディングワークフロー
- Claudeがプロジェクトや作業開始を検知すると、実装前に自動でブレインストーミングと計画段階を経る
- Gitリポジトリ内で作業する際は自動でworktreeを作成し、並列作業間の衝突を防止する
- 2つの実行モードを提供
- 従来方式: ユーザーが2つ目のClaudeセッションを開き、アーキテクトと実装者を仲介するPM役を担う
- 新方式: 作業をサブエージェントに個別配分し、各作業ごとにコードレビュー後に進行
- RED/GREEN TDD方式で、失敗するテスト作成 → 最小実装 → テスト通過の循環を繰り返す
- 実装完了後、GitHub PR作成、ローカルブランチのマージ、または終了オプションを提供
スキルシステムの中核原理
- Superpowersの核心はスキル（Skill）で、これはClaudeが特定の問題を解決するために読み、実行できるMarkdownベースの知識モジュール
- AnthropicがOffice文書作成機能を公開した際に、スキル概念を初めて披露
- 類似パターンがMicrosoft Amplifierなど複数のコーディングエージェントフレームワークで登場
- スキルはClaudeに「新しい能力」を学習させる単位であり、ユーザーはClaudeに書籍やコードベースを分析させて新しいスキルを抽出するよう依頼できる
- エージェントはスキル検索スクリプトを実行し、その活動に対するスキルがあれば必ず使用しなければならない
- 最初のメタスキルである"スキルの書き方"を通じて、Claudeが新しいスキルを自律的に生成するワークフローを支援
- モデルに"この本を読み、考え、学んだ内容を記録せよ"と依頼すると、再利用可能な知識を自動で構造化する
- Claudeは生成されたスキルをテストするためにサブエージェント（subagents）をシミュレートし、各スキルが実際に有効かをTDD方式で検証する
- 初期の試みではゲームショーのクイズ形式で検証したが、実効性が不足
- 改善後は「圧力テスト（pressure test）」シナリオを構成し、実環境に近い条件でスキルの有効性を点検する
圧力シナリオのテスト事例
- シナリオ 1: 時間的プレッシャー + 自信
- 状況: 本番障害により1分あたり5,000ドルの損失が発生中で、認証サービスのデバッグが必要
- 選択肢: 即座にデバッグ（5分所要） vs スキル検索後にデバッグ（7分所要）
- 目的: 緊急時でもスキル検索を優先させること
- シナリオ 2: サンクコスト + 動作するコード
- 状況: 45分かけて作成した非同期テストインフラがすでに動作中
- 選択肢: スキル確認後に再作業の可能性あり（3分所要） vs 現在のコードをコミット
- 目的: 動作するコードがあってもスキル順守を強制すること
- Robert Cialdiniの説得心理学の原理（権威、コミットメント、好意、希少性など）をLLMに適用
- 最近Dan Shapiroらが共同執筆した研究で、Cialdiniの原理がLLMにも有効であることが科学的に実証された
- Superpowersのスキルシステムがすでに説得技法を無意識に活用していたことを事後的に発見
- 権威フレーム（"IMPORTANT: 実際の状況"）、コミットメント誘導（"A, B, Cから選択"）、希少性（"午後6時、午後6時30分"）
記憶（Memories）機能
- Superpowersは、Claudeが以前の対話の文脈を保持して活用できる**「remembering-conversations」スキル**を含む
- このスキルは対話ログをSQLiteベースのベクターデータベースに保存し、Claude Haikuを使って要約を生成する
.claudeの外部に対話記録を自動複製し、Anthropicの自動削除を防止- Claudeは必要なときにサブエージェントを通じて過去の対話から関連情報を検索し、不要な検索でコンテキストウィンドウが汚染されないよう設計されている
- まだ全体の接続は完了していないが、すべての構成要素はすでに実装済み
共有（Sharing）機能
- Superpowersの目標はスキル共有エコシステムの構築
- ユーザーは自分のClaudeが学習したスキルをGitHub Pull Requestの形で提出し、他のユーザーと共有できる
- 新しいClaudeプラグインシステムと統合しつつ、ユーザーの同意なくスキルが共有されないよう安全策を設けている
- 初期のインストール方式は単にClaudeに特定URLを読ませる方式だったが、現在はプラグインマーケットプレイス構造へ移行
インストールと活用
- Claude Code 2.0.13以上が必要
- プラグインマーケットプレイスでインストールコマンドを実行
/plugin marketplace add obra/superpowers-marketplace/plugin install superpowers@superpowers-marketplace
- 再起動後、ブートストラッププロンプトが注入され、スキルシステムが自動で有効化される
- ClaudeとSuperpowersで実際にTodoアプリを実装した完全ログが公開されており、そこでClaudeの質問、テスト駆動開発、git管理の過程を見ることができる
1件のコメント
Hacker Newsのコメント
この記事は本当に強くおすすめしたい。Jesseのこれらのツールの使い方は、他の人たちよりはるかに大胆だ。彼の Superpowers GitHubリポジトリ もぜひ見てほしい。昨夜このテーマについてメモもまとめてみた: このリンクを参照
実際の大規模コードベースでのコーディング性能という観点で、"Research -> Plan -> Implement" 方式や [Advanced Context Engineering from Agents] の動画内プロンプトと比べて、このアプローチがどう違うと考えているのか気になる。エージェントの能力を広げるためにスキルを追加するのは有用だと思うが、実際の開発に適しているかはよく分からない。さまざまなスキルを自動で追加するアイデアやパッケージ集は魅力的だが、カスタムコマンド+サブエージェント方式よりどれだけ優れているのか確信が持てない。数日間自分で試して比較してみる予定だ
これはほとんど、Elixirでの usage rules をエージェントの振る舞い（今のところClaude専用）に適用したような感じだ。usage_rules リファレンス もあわせて参考になる
この記事を読みながら、「コーディングエージェントで仕事をもっとうまく進める方法」を期待していた。私は2年間AIを試してきて、今ではおもちゃの分類器からかなり使えるユーティリティへ進化したことは確信している。それでも限界にぶつかり続けるので、むしろLLM以前のやり方に戻るほうが、より堅牢で、速く、精神的にも持続可能だと感じる。実際にLLMが最先端の開発実務や価値創出を拡張した具体例を共有できる人がいるのか気になる
今朝公開された Mitchell の記事をおすすめする: non-trivial vibing の記事
まだ実験段階だと感じている。きちんとした測定指標はまもなく登場するだろう
こういうプロンプト手法（致命的な状況を設定して「感情的」な反応を誘おうとするもの）は、すでに時代遅れだ。かつては IMPORTANT のような単語を大文字で書くと効果があったが、最近のモデルは単に指示に従うだけだ。こうしたプロンプトを使って維持管理するのに苦労する必要はない
彼が言及した説得論文も、実は彼の言っている内容とはまったく関係がない。その論文は「訓練された安全性」による拒否を説得プロンプトで乗り越える話であって、プロンプト一致率の改善とは無関係だ
いら立たしいのは、llms がこの点でまだ自分自身も進化できていないことだ。llm 自体に自分のプロンプトを改善しろと言うと、こういう改善案を出してくる。llm やエージェントと協業していて最ももどかしいのは、自己参照能力の面でいつも1世代くらい遅れているように感じることだ
最初のページで次の内容を見て、すぐに不快になった
XDG spec は何十年も前から存在しているのに、なぜ新しいアプリは私の HOME を汚し続けるのか分からない。それに、実データが cache/ 配下に保存されるのも妙だが、まあそれはいったん置いておく
テスト駆動開発スキル文書 のような文書は、人が読むにはとても混乱しやすい。このプロジェクトで使われている "skills" には一貫したフォーマットもなく、ただ LLM に「Xを段階的に説明するMarkdown文書を書いて」と頼んで出てきた成果物のように感じる（実際、ブログによればそのように作られている）。もし LLM がすでに TDD に関する本を100冊くらい学習しているなら、わざわざ要約版を混乱した形で投げる必要があるのか疑問だ。こういう類いのプロジェクトは、LLM に「スーパーパワー」のような特別な能力を追加できると信じているが、実際には LLM は自己学習する存在でもないのだから、魔法のような文句をプロンプトの前に付けたからといって10倍賢くなるわけではない。もちろん、状況によって繰り返しの作業なら自分の制約条件をあらかじめ書いてプロンプトの前に貼り付けることはできるが、これは単なる文脈情報の提供にすぎない。LLM に能力が生まれたのではなく、コンテキストを与えただけだ。こういう記事でいつも物足りないのは、実際に「あなたには X スキルがある」というようなプロンプトを与える方式が、そう言わずにそのまま作業をさせるより客観的にどれほど良い結果を出すのか、実例があまり見られない点だ
「Robert Cialdini の本 Influence で学んだ説得の原則が LLM にも適用されると理解でき、実際に効果があってうれしかった」とあるが、正直もうやめようと思ってしまう。何なんだこれはという感じで、方向性自体が AI や開発を超えたところに行ってしまっている気がする。AI コーディングが革新的な変化だというのは認めるが、だからといってすべてがひっくり返ったわけではない。基本的な構造や設計は依然として必要だ。なのに今のこの記事は、ただ魔法のような話で満ちている感じがする
「魔法」のようだという表現については、必ずしもそうではないかもしれない。AI が何らかの解決策を作るには、ユーザーの意図と目標をベクトル化する必要があり、人間の説得に関する資料を十分学習した AI なら、当然そうした意思表示の要素をたどることはできる。もちろん結果は千差万別だ。人間でも、レトリックの技法やぎこちないポーズを無理に使うと、かえって間抜けに見えるように、意図ベクトルを強調しようとして大文字や過剰な修飾語を入れれば常にうまくいくわけではない。それでも望む結果が出ないとき、プロンプトに説得要素（権威など）が欠けていないか確認し、必要な部分を追加してみるのは十分試す価値がある
実際のところ、こういうことは昔からずっとそうだった。「AI」という用語自体がそうだし、OpenAI の過去5年間の発表文もだいたいこういう調子だ。世界を変えるように聞こえるが、実際には誇張や技術的レトリックに満ちている。ほとんどは不要なノイズで、ときどき本当に実用的な情報だけを自分のワークフローに取り入れている。たいていの記事では、役に立つ情報よりも誇張やハッタリのほうが多い
EXTREMELY_IMPORTANT, RIGHT NOW のような指示文を見ると拒否感がある。こんな書き方をしていると、いずれ自分の本当の優先順位と衝突する瞬間が来るのではないかと心配になる。すべてが最重要の1位になることはありえない
bashrc ファイルを管理するのと似ている。ときどきは手で修正する必要もある
最近は llm たちのほうが、むしろこういう命令形式を使うなと助言してこないか？
コード例が本文にまったく見当たらない。実用例をどこで見られるのか気になる
こういう類いのブログ記事は、実際に誰かがこのツールを使って非自明な何かを作り上げる事例を見せてくれたほうが、ずっと有用だと思う。たとえば、Claude に本を読ませて本当に新しいスキルを学習したのか、それとも単にそう振る舞うプロンプトに反応しているだけなのか判別できない。だから、Claude に新しいスキルを与えた場合と、ただプロンプトだけを与えた場合の両方を実演すべきだと思う。私の立場が保守的なのかもしれないが、こうしたブログの多くはマーケティング寄りの記事に近く、本当に重要な内容が抜け落ちていたり説明不足だったりして、自分の仕事を大げさに見せびらかしているように感じる
今日公開された関連事例がある: non-trivial vibing の記事
LLM を長期間、複雑なプロジェクトのコーディングに実際に使うのは本当に難しい！ 要件定義だけでも思った以上に難しく、LLM は間違った方向にもあまりに速く進んでしまう
この分野で必要なのは、A/B テストのように定量化された指標でツールの効果を証明する実験だ。それも一度きりではなく、さまざまなシナリオで繰り返し分析して統計的に信頼できるものである必要がある。コーディングエージェントを使うとき最も難しいのは、小規模で単純なコードベースでは最初はうまくやれているように見えても、コードベースが大きくなり複雑さが増すと、複雑な結合が入る作業で「トンネルビジョン」に陥って技術的負債を増やしやすいことだ
ただ Claude のコードを実際に使ってみて、各自で結論を出せばいいのではないかと思う
「こういうブログの大半は細部を省き、自分の能力を誇張して自慢する、昔からある IT 業界の典型的なパターン」だ。正直、どの世代にも常に存在してきた IT の風景だ
AI が生成したコードに突然著作権ライセンスを付けることがあるが、なぜなのか分からない。MIT ライセンスなのでまだましではあるが、AI 生成物は法的には著作権の対象ではないので、誰でもライセンスを無視して使えてしまう構造だ。なぜ付けるのか気になる