Claude Code Superpowers入門｜AIに手順を飛ばさせない14のスキル

この記事でわかること

Claude Code が「動くけれど、頼んでいないことまでやる」本当の原因
Superpowers のスキルが、実体としては何なのか
インストール手順と、バージョン差分の追い方
14個のスキルを、いつ・どの順番で呼べばいいのか
サブエージェントに任せるべきか、同じセッションで進めるべきかの判断軸
バグ修正を3回往復してしまったときに、何をやめるべきか

対象は、Claude Code をすでに使っている方です。依頼を投げれば動くものは返ってくる。ただ、その品質が日によってばらつく ―― この記事はそこを抜けるための話です。

1. 「動くけれど、頼んでいないことまでやる」の正体

機能をひとつ追加してほしいと頼んだら、300行のコードが一気に返ってきました。動かしてみると、7割か8割は意図どおりです。残りの2割は、頼んでいない仕様が勝手に足されています。

「そこはテストのバグなので直してください」と伝えると、素直に直してくれます。そのついでに、動いていた箇所まで書き換わってしまいます。

こういう経験があるなら、モデル性能を疑うのは筋違いです。 Claude Code は勤勉すぎるのです。聞かない、検証しない、収束しない。指示を受けた瞬間から手が動き始めます。

Claude はテストを先に書くべきだと知っています。バグは根本原因を特定してから直すべきだと知っています。ただ、「とりあえず動かして見せて」という文脈では、その手順を飛ばします。知識がないのではなく、守らせる仕組みがないだけです。

この記事で扱う Superpowers は、Claude Code に能力を足すプラグインではありません。 手順を飛ばせなくするプラグインです。

同じ症状に、プランモードという別の角度からの対処もあります。まずは道具を増やさずに試したい方は、Claude Code プランモード入門を先に読むとこの記事の話がつながりやすくなります。

2. Superpowers とは何か ―― 能力ではなく規律を配るプラグイン

スキルの中身は、ただの Markdown ファイル

意外に思われるかもしれませんが、Superpowers に入っている14個のスキルは、 すべて SKILL.md という Markdown ファイル1枚です。プログラムでもツール呼び出しでもありません。

中に書かれているのは、こういう内容です。

この種類のタスクに当たったら、この順番で進めること。前の段階が終わっていないなら、次に進んではいけない。

つまり、自然言語で書かれた行動のルールです（Superpowers 本体は英語で書かれています）。それだけで Claude の振る舞いが変わります。

ここに、このプラグインの発想が詰まっています。AIコーディングに足りないのは能力ではなく規律であり、規律はテキストで配布できる。この一点です。

はじめに用語を整理しておきます。3つが混ざりやすい部分です。

用語	意味
プラグイン	配布の単位。Superpowers はこれ
スキル	ひとつの手順書。14個ある
`SKILL.md`	スキルの中身が書かれた Markdown ファイル

考え方としては、CLAUDE.md に近いものです。CLAUDE.md が「常に守るルール」を置く場所なら、スキルは「特定の場面で開く手順書」にあたります。役割分担についてはCLAUDE.mdは「4層」に分けると安定するもあわせて読んでみてください。

インストールと、いま追うべきバージョン

Claude Code なら、公式のプラグインマーケットプレイスから入ります。

/plugin install superpowers@claude-plugins-official

作者は Jesse Vincent 氏、リポジトリは obra/superpowers、ライセンス is MIT です。Claude Code 専用ではなく、Cursor や Codex、Gemini CLI を含む14の環境向けにインストール手順が用意されています。

ひとつ注意点があります。このプラグインは更新が速く、バージョンによってスキルの中身が変わります。 本記事は執筆時点の最新である v6.3.0（2026年8月12日） で確認した内容です。

日本語や中国語の紹介記事を読むときは、そこに書かれた挙動が古いバージョンのものである可能性を疑ってください。リポジトリの RELEASE-NOTES.md を見れば、どのバージョンで何が変わったかが追えます。この記事でも、以前のバージョンから変わった箇所には注記を入れていきます。

3. 全体像：14スキルは3つの役目に分かれる

詳細に入る前に、地図を渡します。

Visual Note 1: Superpowers 14スキルの役割マップ

14個は、使う場面で3つに分かれます。

工程を進めるスキル ―― 設計、計画、実装、収束。開発の流れそのもの
常に効いているスキル ―― テスト駆動開発、完了前の検証。工程を横断する
困ったときに割り込むスキル ―― デバッグ、コードレビュー依頼

ここで安心してほしいのは、14個を覚える必要はないという点です。入口はひとつだけで、あとは順番に引き継がれていきます。

このうち「工程を進めるスキル」は、設計 → 隔離ワークスペースの作成 → 計画 → 実装 → レビュー依頼 → 収束、という順に並びます。次の章から、この順番で 1工程ずつ見ていきます。

3つの役目がひとつの流れの中でどう噛み合うのかは、最後の章でまとめて見ます。

4. 設計：承認ゲートを越えるまで、コードは書かせない

最初の工程は brainstorming です。いちばん使われていて、いちばん浅く使われているスキルでもあります。

多くの人の使い方は、こうなっています。呼び出して、聞かれた質問に答えて、そのまま「じゃあ書いて」。

これだと、このスキルの本体を使えていません。

手順の重さはタスクに応じて縮む。承認だけは縮まない

SKILL.md の冒頭には、こう書かれています。

<HARD-GATE>
Do NOT invoke any implementation skill, write any code, scaffold any
project, or take any implementation action until you have told your
human partner what you intend and they have approved it. This applies
to EVERY task on EVERY path below — the ceremony scales with the task;
the approval gate never does.
</HARD-GATE>

要点は2つです。

1つ目。 「何をするつもりか」を人間に伝えて承認をもらうまで、コードを1行も書かせない。実装系のスキルも呼ばせない。プロジェクトの雛形も作らせない。 <HARD-GATE>、つまり動かせない関門という名前のとおり、提案ではなく禁止です。

2つ目。 最後の一文が重要です。「手順の重さはタスクに応じて変わる。承認ゲートは決して変わらない」。

v6.3.0 の brainstorming は、質問を始める前にタスクを3種類に分類します。

経路	対象	成果物
Spike	「できるかどうか」を調べたいだけの話	答え。書いたコードは使い捨て扱い
Bounded	すでにあるコードへの小さな変更。フラグの追加、1ファイルの修正	チャット上の短い設計だけ
Architectural	新規プロジェクト、新しいサブシステム、他が依存する仕組みの変更	設計書ファイル＋実装計画書

設定を1つ変えるだけなら、設計は2文で構いません。ドキュメントも作りません。ただし、その2文を見せて「はい」と言われるまでは着手できません。縮むのは成果物であって、承認ではありません。

バージョンに関する注記 本記事が参照した原記事は v5.1.0（2026年4月末）時点の内容で、「設定変更ひとつでも9ステップ全部を通せ」と書かれています。v6.3.0 ではここが変わり、タスクの大きさで手順が縮むようになりました。ただし「簡単に見えるタスクほど暗黙の前提が危ない」という考え方自体は現行版にも残っています。

判断に迷ったときのルールもあります。「迷ったら重い経路を選ぶ」というルールです。そして途中で想定より複雑だと分かったら経路を上げます。下げることはできません。

設計書まで書く経路の9ステップと、飛ばされやすいステップ

Architectural と判定された場合は、9ステップを順番に踏みます。

プロジェクトの現状を見る（ファイル、ドキュメント、直近のコミット）
見た方が早い論点が出てきたときだけ、ブラウザで開く補助画面を提案する
確認したいことを質問する（1回に1つだけ）
案を2〜3個出して、推奨とその理由を示す
設計を章に分けて提示し、章ごとに承認をもらう
設計書をファイルに書いて commit する
設計書を自分で点検する（TBD の残り、矛盾、範囲、曖昧さ）
人間に設計書を読んでもらう
計画作成のスキルに引き継ぐ

保存先は docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md と決まっています。

飛ばされるのは、太字にした6〜8です。

ステップ4か5まで進むと「だいたい決まったから、もう書いてもらおう」という気分になります。ここで止めると、設計が会話の中にしか存在しない状態になります。

そうなると、実装が進むうちに Claude の前提がずれていきます。半分まで作ったところで、最初に決めたインターフェースの形を忘れてしまいます。これはありがちな展開です。

設計書がファイルとして残っていれば、話が食い違ったときに立ち返る場所ができます。このスキルの価値は、質問に答えることではなく、あとから参照できる設計書が 1枚残ることにあります。

もうひとつ、この設計には一方通行の仕掛けがあります。brainstorming の終点は「計画作成スキルへの引き継ぎ」だけで、そこから直接実装に飛ぶ道がありません。設計 → 計画 → 実装の順番を、構造として強制しています。

5. 計画：ステップを2〜5分に刻み、「TBD」を残さない

設計が終わったら、実装に入る前に作業場を切り離します。これが using-git-worktrees です。git worktree は、同じリポジトリから独立した作業ディレクトリを作る git の機能です。ここで実装させれば、途中で作業を捨てても元のブランチは汚れません。置き場所はプロジェクト内の .worktrees/ です（v6.0.0 でホームディレクトリの下から変更されました）。

そのうえで、計画づくりの writing-plans に引き継がれます。仕事は1つで、 設計書を、1ステップずつ実行できるタスクリストに変換することです。

「テストを書く」と「失敗を確認する」を分ける理由

このスキルの核心は、ステップの粒度です。SKILL.md にはこう書かれています。

Each step is one action (2-5 minutes): （各ステップは1つのアクション。2〜5分）

続けて、実際の例が並んでいます。訳すとこうなります。

- [ ] Step 1: 失敗するテストを書く
- [ ] Step 2: 実行して、実際に失敗することを確認する
- [ ] Step 3: テストを通す最小限の実装を書く
- [ ] Step 4: テストを実行して、通ることを確認する
- [ ] Step 5: commit する

注目してほしいのは、Step 1 と Step 2 が別々になっている点です。「テストを書いて、失敗を確認する」ではありません。

分ける理由は、各ステップに明確な完了判定を持たせるためです。「やったけれど、これで終わったことになるのか分からない」という状態を作らせないためです。テストを書いたかどうかは見れば分かります。失敗したかどうかも実行すれば分かります。 1つにまとめると、この判定が曖昧になります。

もうひとつ、厳しいルールがあります。プレースホルダー禁止です。以下の書き方は「計画の失敗」と明記されていて、書き直しの対象になります。

「TBD」「TODO」「あとで実装」「詳細は後で埋める」
「適切なエラー処理を追加する」（どう処理するのか書いていない）
「上記のテストを書く」（テストコードそのものがない）
「Task 3 と同様」（参照で済ませず、コードを書き写す。実行者はタスクを順番どおりに読むとは限らない）
何をするかは書いてあるが、どうやるかが書いていないステップ

なぜここまで厳しいのか。実行段階に「TBD」が1つでも残っていると、Claude の選択肢は 2つしかありません。止まって質問するか、自分で発明するかです。前者は手が止まり、後者は冒頭で書いた「頼んでいない仕様」に戻ります。

自分のタスクしか見えない実行者に、隣の契約を渡す

v6.0.0 から、計画書に2つのブロックが加わりました。Next の章の話につながる部分です。

Global Constraints には、全タスクに共通する制約を1行ずつ書きます。バージョンの下限、使ってよい依存の範囲、命名や文言のルール、プラットフォーム要件。設計書からそのままの値をコピーすると決められています。要約や言い換えを許さない書き方です。

Interfaces はタスクごとに書きます。

Consumes: このタスクが前のタスクから使うもの（正確なシグネチャで）
Produces: 後のタスクが依存するもの（関数名、引数と戻り値の型）

SKILL.md にはその理由も書かされています。タスクを実行する担当者は 自分のタスクしか見えません。そのため、隣のタスクが使う名前と型を、このブロックで知る必要があります。

なぜ「自分のタスクしか見えない」のか。次の章の話です。

6. 実装：サブエージェントに任せるか、同じセッションで進めるか

計画ができると、実行方法を2つ提示されます。ここでの選択が、出来上がるコードの品質にはっきり影響します。

選ぶための3つの判断軸

Visual Note 3: 実装をどちらに任せるか・ 3つの判断軸で決める

subagent-driven-development は、タスクごとに新しいサブエージェントを立てます。

サブエージェントとは、親のセッションから独立したコンテキストを持つ実行役です。計画書と担当タスクだけを渡されて、まっさらな状態から始めます。前のタスクでどんな試行錯誤があったかは知りません。

executing-plans は、いま話しているセッションの中で全タスクを順番に実行します。会話の履歴は積み上がっていきます。

選ぶときの判断軸は3つです。

判断軸	サブエージェント方式	直列方式
使っているツールがサブエージェントに対応しているか	対応している	対応していない
タスク数	多い（4個以上）	少ない（1〜3個）
途中に手作業が混ざるか	混ざらない	環境変数の設定など、自分で操作する工程がある

Superpowers の文書は、サブエージェントが使える環境ならそちらを推奨しています。理由は、コンテキストが混ざらないことです。

原記事の著者は、この違いをこう書いています。8タスクある機能を直列方式で実行したとき、5タスク目あたりから Claude が前のタスクの修正を「まとめ直し」始め、すでに通っていたテストを壊してしまったそうです。サブエージェント方式に切り替えると、この現象がほぼ消えたと言います。これは著者ひとりの観測なので、そのまま一般化はできません。ただ、似た経験のある方は多いと思います。

なぜ独立したコンテキストだと品質が上がるのか。この背景は Claude Code コマンド整理術で扱っているコンテキストの話とそのまま重なります。

代償もあります。サブエージェント方式はタスクごとに計画書を読み直すので、呼び出しのコストは高くなります。それでも手戻り1回を避けられるなら十分に元は取れます ―― これは原記事の著者の見立てで、Superpowers のドキュメントに書かれているものではありません。

なお、この2つは混ぜられます。同じ計画の中で、大半のタスクはサブエージェントに任せ、手動の設定が必要なタスクだけ自分で実行する、という進め方ができます。

レビューはタスクごとに1回、最後にもう1回

サブエージェント方式では、タスクが終わるたびにレビューが入ります。

1タスクにつき、レビュー担当が1人。 その担当が差分を1回読んで、 2つの判定を返します。設計どおりか（仕様適合）と、コードとして妥当か（品質）です。指摘が出たら、1回の修正で両方に対応します。

そして全タスクが終わったあと、ブランチ全体を通したレビューが1回走ります。 こちらはより性能の高いモデルで実行するよう指定されています。

バージョンに関する注記 v5系では、仕様担当と品質担当の2人が別々にレビューする方式でした。 v6.0.0 でレビュー用のプロンプトが1本に統合され、いまは「1人が2つの判定を返す」形です。「2ラウンド審査」と書かれた解説を見かけたら、旧方式の説明です。

この変更には理由が公開されています。2人体制は費用が高く、しかも指摘をかわしやすかったという点です。実際の運用で、親エージェントがレビュー担当に「この指摘は無視していい」「軽微として扱って」と伝えてしまう例が観測され、そのまま欠陥が通っていたそうです。

いまは、指摘を抑え込むことと、深刻度を先に決めておくことが禁止されています。計画書自体が問題のある指示をしていた場合は、勝手に通さず人間に報告して判断を仰ぐ形になりました。

7. 詰まったとき：根本原因が分かるまで修正させない

この章で扱うのは、割り込みのスキルです。原記事の著者が「Superpowers の中でいちばん過小評価されている」と評しているのが、この systematic-debugging です。

普通のデバッグは、こういう往復になりがちです。

エラーが出る → Claude に貼る → 「Xかもしれません、ここを直してみましょう」
→ 直らない → また貼る → 「ではYかもしれません」→ 以下繰り返し

心当たりのある展開だと思います。これは Claude が悪いというより、根本原因を特定する義務がないから起きています。

4フェーズと、順序を守らせる鉄則

Visual Note 2: systematic-debugging ・ 4フェーズと3回失敗ルール

SKILL.md の冒頭に、大文字で書かれた一文があります。

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

根本原因の調査を先に済ませなければ、修正してはならない。続けて「Phase 1 が完了していないなら、修正を提案することはできない」とも書かれています。

4つのフェーズは、順番を飛ばせません。

Phase 1：根本原因の調査

エラーメッセージを最後まで読む（ざっと目を通すのではなく、全文を読む）
安定して再現する手順を作る
直近の git の変更を確認する
複数のコンポーネントが絡む場合は、それぞれの境界にログを仕込み、まず1回動かして証拠を集めてから、どこで壊れているかを判断する

Phase 2：パターンの分析

このフェーズが、いちばんすぐ真似できる部分です。

同じコードベースの中から、似ているけれど正しく動いているコードを探す
壊れているコードと1項目ずつ突き合わせる
そのとき、どんなに小さな差でも「これは関係ない」と決めつけない

「関係ないと思っていた差が原因だった」というのは、よくある結末です。このフェーズはそれを構造として防ぎます。

Phase 3：仮説をひとつ立てて検証

「Xが根本原因だと考える。理由はYだから」と、具体的に書き出す
最小の変更で検証する
外れていたら、変更を積み増さずに次の仮説へ移ります。

外れた変更を残したまま次を試すと、何が効いたのか分からなくなります。

Phase 4：修正の実装

まず、問題を再現するテストを書く
直すのは1箇所だけ
通ることを確認する

なお、原記事には「一般的なデバッグは平均2〜3時間、このスキルを使えば15〜30分」という数字が載っています。ただ、Superpowers 本体を確認したところ、この数値の記載は見つかりませんでした。出典が確認できないため、この記事では扱いません。

3回失敗したら、4回目ではなく設計を疑う

Phase 4 には、実用的な決まりがあります。

修正を3回試して直らなかったら、4回目は試しません。 手を止めて、「そもそもこの作り方自体に問題があるのではないか」を議論します。

これは多くのエンジニアの直感と逆です。3回外したあとは、焦って4回目、5回目に突っ込みたくなります。

しかし、根拠のない修正を1回足すごとに、コードには新しい不確実性が入ります。直ったとしても、なぜ直ったのか分かりませんし、時間も無駄に消費してしまいます。

このスキルには「よくある言い訳」の対照表も入っています。思い当たるものが多いので、4行だけ引用します。

言い訳	実際は
「この問題は単純だから、手順は不要」	単純なバグにも根本原因はある。単純な問題ほど手順は速く終わる
「緊急だから調査する時間がない」	当てずっぽうの往復より、系統的な調査の方が速い
「まず1回試してから調査する」	最初の修正でやり方が決まる。最初から正しくやる
「問題の場所はだいたい分かっている」	症状が見えていることは、根本原因が分かっていることではない

3つ目が特に効きます。1回目を当てずっぽうで直すと、そのあともずっと当てずっぽうを続けることになる、という指摘です。

8. 収束：ブランチを片付けるまでが1タスク

最後の工程が finishing-a-development-branch です。ワークフローの終点で、いちばん飛ばされます。

タスクが終わったら、そのまま commit して push したり、あるいは Claude に「マージしておいて」と頼んだりしがちです。結果として、テストを流していない、作業用のワークスペースが残っている、ブランチが処理されていない、という状態になってしまいます。

このスキルの流れは決まっています。

Step 1 でテストを検証します。失敗したら、そこで止まります。 先のステップには進みません。

Step 2 でベースブランチを判定し、Step 3 で選択肢を提示します。 提示されるのは、次の3つです。

1. ローカルで <base-branch> にマージする
2. push して Pull Request を作る
3. このまま残しておく（あとで自分で処理する）

ここに「破棄」は含まれません。作業を捨てるのは、人間が明示的にそう頼んだときだけです。しかもその場合、discard という文字列を手で入力しないと実行されません。うっかり選んでしまって作業が消える、ということが起きない設計です。

Step 4 で選択を実行し、Step 5 でワークスペースを片付けます。 1（マージ）と破棄の場合は片付け、2（PR）と3（保持）の場合は残します。 PR にはレビューのやり取りが続くので、作業場所が必要だからです。

バージョンに関する注記 原記事は4つの選択肢（マージ／PR／保持／破棄）として説明していますが、 v6.3.0 では破棄が選択肢から外れ、3択になっています。

9. 使い始めてから分かる、3つのつまずき

長い会話で、スキルの存在を忘れる

長時間セッションを続けていると、Claude が少しずつ元の振る舞いに戻ります。テストを飛ばす、バグを当てずっぽうで直す、設計を聞かずに書き始める。スキルを入れる前の状態です。

対処として、入口のスキル（using-superpowers）を呼び直して優先順位を再確立する方法が原記事で紹介されています。

ただし、これは公式に文書化されたリセット機能ではありません。SKILL.md を確認しましたが、そういう挙動の説明は書かれていませんでした。セッション開始時に読み込まれてスキルの優先順位を決める役目のスキルなので、呼び直せば効くだろう、という実践的な工夫として理解しておくのが正確です。

brainstorming を「質疑応答マシン」にしてしまう

このスキルが質問してくるのは、設計を作るためです。「曖昧な要望を整理してもらう相談相手」として使うこともできますが、そこで止めると意味が半分になります。

設計書と計画書に到達しないと、実装フェーズが参照できる設計が存在しません。第4章で書いたとおり、価値はファイルとして残る設計書の側にあります。

「初回は遅い」だけで判断してしまう

原記事の著者は、リファクタリングでこの流れを初めて通したとき、 9ステップに40分かかって「遅い」と感じたそうです。ただし、そのあとの実装ではほとんど手戻りが出ませんでした。

一方、設計を省いて直接書かせたときは、設計の30分は節約できたものの、そのあと3回直すことになり、合計では2時間ほど余計にかかったと書いています。

あくまで一例です。同じ時間配分になる保証はありません。ただ、判断すべき軸はここに表れています。

問題は「プロジェクトが大きいか小さいか」ではありません。 手戻りを受け入れられるかです。

そして、小さいタスクなら Bounded 経路で軽く回せます。重い手順をいつも全部通す必要はない、という点は第4章で見たとおりです。

10. よくある質問

小さなプロジェクトには手順が重すぎませんか？

v6.3.0 では、最初にタスクを3種類に分類します。小さな変更なら設計書も計画書も作りません。数文の設計をチャットで見せて、承認をもらうだけです。

迷ったときは重い経路を選ぶ、というルールもあります。途中で想定より複雑だと分かった場合は経路を上げられますが、下げることはできません。

「3回失敗したら止まる」は、それ以上直してはいけないという意味ですか？

修正の禁止ではありません。4回目に進む前に、設計レベルの問題ではないかを必ず議論するという意味です。

議論した結果、設計の問題ではなく別の方向を試すべきだと分かれば、続けて構いません。禁じられているのは、議論を挟まずに4回目へ突っ込むことです。

スキルは自分で作れますか？

作れます。writing-skills が、スキルの書き方そのものを扱うスキルです。

社内のコードレビュー規約やデプロイの制約をスキルにしておけば、プロジェクトを越えて同じ手順を配れます。個人用スキルの配置場所については、バージョンによって変わる部分があるため、公式ドキュメントで確認してください。

また、Superpowers にはタスク別に並行処理を行う dispatching-parallel-agents や、複数人のレビュー結果を処理する receiving-code-review など、合計14のスキルが含まれています。

全部通すと、機能ひとつにどれくらいかかりますか？

複雑さによります。原記事では、中規模の機能（4〜6タスク）で設計に30〜40分、計画に15〜20分という目安が挙げられています。これは著者の実測値で、実装時間はタスクの内容次第です。

11. 通しで見る：機能ひとつを作りきる流れ

ここまで見てきたものを、1枚に重ねます。

Visual Note 4: Superpowers ・機能ひとつを作りきる流れ

線が3種類あります。

本線は、設計から収束までの一方通行です。第4章から第8章で見てきた順番が、そのまま並んでいます。順番を入れ替える道はありません。

貫通しているのがテスト駆動開発です。実装フェーズのあいだ、ずっと効いています。

割り込みは2つです。途中でバグに当たったらデバッグのスキルが入り、「終わりました」と言う前に検証のスキルが入ります。どちらも工程では発動せず、事象で発動します。

そして、この6工程を最初から全部通す必要はありません。1つずつ足していけます。

設計の承認ゲートだけを入れてみる。慣れたら計画の粒度を刻んでみる。バグで往復し始めたらデバッグの4フェーズを入れる。それぞれ独立して効くので、順番に試して自分の現場に合うものだけ残す、という進め方ができます。

まとめ

Superpowers が解決しているのは、「Claude Code にできるか」という問題ではありません。大半のことはできます。

解決しているのは、Claude Code が手順を飛ばさないかという問題です。

そして、その手順は Markdown ファイル1枚で配れます。テストを先に書く、根本原因を特定してから直す、設計を承認してから着手する。どれも新しい発明ではありません。ただ、AIに守らせる手段がありませんでした。それをテキストで解決したのが、このプラグインの中身です。

明日からの一歩として、ひとつだけ提案します。

次に作る機能ひとつだけ、設計を見せて承認するまでコードを書かせない。

プラグインを入れなくても、この制約は課せます。「まず何をするつもりか、数文で説明してください。私が承認するまで書き始めないでください」と伝えるだけです。

それで冒頭の2割 ―― 頼んでいない仕様が混ざる部分が、どれくらい減るか。まずそこを確かめてみてください。

チームや業務に広げる段階まで来たら、AIコーディングのセキュリティ設計もあわせて読んでみてください。手順を配る話と、権限の境界を引く話は補完関係にあります。

出典

Superpowers 公式リポジトリ（Jesse Vincent、MIT ライセンス） https://github.com/obra/superpowers

本稿は v6.3.0（2026年8月12日公開） の SKILL.md および RELEASE-NOTES.md で内容を確認し、 brainstorming の3経路、レビュー方式、収束時の選択肢、ワークスペースの配置場所の4点について、現行バージョンの挙動に合わせて記述を更新しています。