superpowers 入門教科書 — Claude Code をもっと強くする

はじめに

⚡ superpowers って何？

Claude Code を使っているあなたへ。実は、知らないだけでものすごく損をしているかもしれません。

「Claude Code で機能を作ろうとしたら、いきなりコードを書き始めて、気づいたら全然違う方向に進んでた…」
「バグを直そうとしたのに、直すたびに別のバグが出てくる…」
「コードは動いているけど、本当にこれでよかったのか不安…」

そんな経験、ありませんか？

Claude Code は非常に優秀なAIですが、「どんな順番で作業を進めるか」「何を確認してから次に進むか」という"作業の型"がないと、時間をかけた割に迷子になってしまうことがあります。

superpowers（スーパーパワーズ）は、そんな悩みを根本から解決する「作業の型セット」です。

superpowers を使うとこう変わる

迷わず進める

「次は何をすればいい？」と悩む時間がなくなります。スキルが自動でガイドしてくれます。

バグを根本から直せる

表面だけ直してまた壊れる、を繰り返さなくなります。原因を順番に掘り下げる方法を学べます。

コードの品質が上がる

テストを先に書く習慣（TDD）が身につき、「動いているけど怖い」コードから卒業できます。

何時間も自律で動ける

設計が固まれば、Claudeが数時間にわたって自動で実装を進めてくれます。

superpowers を使うと、Claude Code との作業が「行き当たりばったり」から「プロの開発フロー」に変わります。しかも、特別な操作は必要ありません。インストールされていれば、Claude が自動でスキルを使い始めます。

💡 ポイント

superpowers は「スキル（技術）の集まり」です。「機能を作りたいとき」「バグがあるとき」「作業が終わったとき」など、場面ごとに最適な進め方を Claude が自動で選んでくれます。

では、一緒に学んでいきましょう！

✅ はじめにのまとめ

superpowers は Claude Code の「作業の型セット」
迷い・バグ・品質・自律性の4つが改善される
インストールされていれば自動で動く

第 1 章

あなたの Claude Code、もっとすごくなれる

スキルが「自動で」動く仕組みと、全体のワークフローを理解しましょう。

📖 この章でわかること

superpowers のスキルとは何か
スキルはいつ・どうやって動くのか
開発のフルワークフロー（全体像）

スキルとは？

スキル（Skill）とは、「この場面ではこう進める」という手順書のようなものです。Claude が自動で読み込み、状況に合わせて使います。

たとえば、あなたが「新しい機能を追加したい」と言うと、Claude は brainstorming（ブレインストーミング） スキルを読み込み、いきなりコードを書く前に「何を作りたいか」を一緒に整理し始めます。

💡 ポイント

スキルを「呼び出す」操作は必要ありません。Claude が会話の流れを見て、自動で「今はこのスキルを使う時だ」と判断します。

全体ワークフロー

superpowers を使った開発は、以下のような流れで進みます。各ステップに対応するスキルがあり、それぞれの章で詳しく解説します。

brainstorming

「何を作るか」をじっくり整理する。いきなりコードを書かない。

↓

writing-plans

実装の計画書を作る。細かいタスクに分解する。

↓

executing-plans / subagent-driven-development

計画に沿って実装を進める。サブエージェントが並行して動く。

↓

test-driven-development

テストを先に書いてから実装する（TDD）。

↓

requesting-code-review

実装が終わったらコードレビューを依頼する。

↓

finishing-a-development-branch

作業完了。マージするか、PRを作るかを決める。

バグが出たときは、どのステップでも systematic-debugging（体系的デバッグ） スキルが割り込んで、原因を順番に調べる手順に切り替わります。

✅ 第1章のまとめ

スキルは Claude が自動で選んで使う「手順書」
開発はbrainstorming → 計画 → 実装 → テスト → レビュー → 完了の流れ
バグ発生時はいつでもデバッグスキルが動く

第 2 章

機能を作りたいとき

brainstorming スキルが、あなたの「ふわっとしたアイデア」を実装できる形に変えてくれます。

📖 この章でわかること

なぜいきなりコードを書いてはいけないのか
brainstorming スキルが何をしてくれるのか
実際の会話の流れ

よくある失敗パターン

「ユーザー登録機能を追加したい」と言ったら、Claude がいきなりコードを書き始めた。
できあがったものを見たら、「メール確認なし」「パスワードの強度チェックなし」「エラー表示もない」…全部作り直しになった。

これは Claude のせいではなく、「何を作るか」を最初に詰め切れていなかったのが原因です。

❌ superpowers なし

「機能を追加して」と言う → Claude がすぐにコードを書く → 完成してから「あ、これじゃない」と気づく

✅ superpowers あり

「機能を追加したい」と言う → Claude が質問しながら要件を整理 → OK が出てから実装開始

brainstorming スキルの動き方

brainstorming（ブレインストーミング）スキルは、新しい機能を作るとき・何かを変更するときに自動で動きます。Claude はコードを書く前に、以下のことをしてくれます。

質問で整理

「誰のための機能ですか？」「どんな状況で使いますか？」など、1回に1つずつ質問する。

↓

2〜3つの案を提示

「こういうアプローチがあります。おすすめはAです、なぜなら…」と選択肢を示す。

↓

設計書を作成

決定した内容を設計書ファイルとして保存。「これでいいですか？」と確認を取る。

↓

計画作成へ移行

承認されたら、次のスキル（writing-plans）に自動で引き継ぐ。

実際の会話例

あなた: ユーザーがメモを保存できる機能を追加したい

Claude: brainstorming スキルを使って要件を整理します。

質問① メモはどこに保存しますか？
  A) ブラウザのローカルストレージ（サーバー不要）
  B) データベース（複数デバイスで共有可能）

あなた: Aでいいです

Claude: 質問② メモを「削除」する機能も必要ですか？

あなた: はい

Claude: 設計をまとめます。

  【機能】ローカルストレージを使ったメモ保存・削除
  【対象】ブラウザを使う全ユーザー
  【動作】メモを入力→保存→一覧表示→削除

  この設計でよいでしょうか？

あなた: OK

Claude: 設計書を保存しました。実装計画を作成します。

💡 ポイント

質問は1度に1つしか来ません。「たくさん聞かれて疲れる」ということがないように設計されています。答えやすい選択肢形式が多いです。

✅ 第2章のまとめ

brainstorming スキルは機能追加・変更のたびに自動で動く
質問→選択肢提示→設計書作成→確認の順に進む
コードを書く前に「何を作るか」を固めてくれる

第 3 章

計画を立てるとき

writing-plans と executing-plans が、大きな作業を小さな一歩に変えてくれます。

📖 この章でわかること

writing-plans スキルが作る「実装計画書」とは何か
executing-plans / subagent-driven-development の違い
計画があると何が変わるか

「計画なし」の危険性

「大きな機能を作ろうとしたら、途中で何を作っているかわからなくなった。」
「30分後に振り返ったら、当初の目的から全然違う方向に進んでいた。」

大きな作業を一気にやろうとすると、このような迷子状態になりがちです。writing-plans（ライティング・プランズ）スキルは、作業を「2〜5分でできる小さなタスク」に分解した計画書を自動で作ってくれます。

writing-plans が作るもの

計画書には以下が含まれます：

# 実装計画書の例

Task 1: ログインフォームのHTMLを作成
  ファイル: src/login.html
  - [ ] テストを書く
  - [ ] テストが失敗することを確認する
  - [ ] HTMLを実装する
  - [ ] テストが通ることを確認する
  - [ ] コミットする

Task 2: バリデーション（入力チェック）の追加
  ファイル: src/login.js
  - [ ] テストを書く
  ...

💡 ポイント

各タスクには「どのファイルを触るか」「実際のコード」「確認コマンド」まで書かれています。迷う余地がないように、全部書いてあります。

計画の実行方法：2つの選択肢

🤖 subagent-driven-development（おすすめ）

タスクごとに新しいサブエージェント（助手）を起動して実装。それぞれのタスクをレビューしながら進む。より確実で品質が高い。

▶️ executing-plans

同じセッション内でタスクを順番に実行。チェックポイントで人間が確認しながら進む。シンプルなタスクに向いている。

どちらを使うかは Claude が提案してくれます。「どちらがいいですか？」と聞かれたら、迷ったらsubagent-driven-development（サブエージェント型）を選んでおけば間違いありません。

✅ 第3章のまとめ

writing-plans が大きな作業を小さなタスクに分解した計画書を作る
各タスクにはファイル・コード・確認手順が全部書かれている
実行はサブエージェント型（おすすめ）かインライン実行から選べる

第 4 章

バグに立ち向かうとき

systematic-debugging が「なんとなく直す」から「原因を特定して直す」に変えてくれます。

📖 この章でわかること

バグが「なかなか直らない」本当の理由
systematic-debugging の4フェーズ
verification-before-completion で「本当に直った」を確認する

「直ったと思ったら直ってなかった」問題

エラーが出た。とりあえず検索して、似たコードを見つけて貼り付けた。エラーは消えた。
でも翌日、全く別の場所で同じエラーが再発した…。

「症状（エラーメッセージ）」だけを見て直そうとすると、このような「もぐら叩き」になります。systematic-debugging（システマティック・デバッギング）スキルは、症状ではなく根本原因を特定する手順で進みます。

4つのフェーズ

フェーズ1: 状況を整理

「いつから起きているか」「何をしたら再現するか」を明確にする。

↓

フェーズ2: 仮説を立てる

「原因として考えられるもの」を2〜3個リストアップし、可能性が高い順に並べる。

↓

フェーズ3: 仮説を検証

最も可能性が高い仮説から順に、小さな実験で確認する。

↓

フェーズ4: 根本から修正

原因が特定できたら、そこを正しく直す。

「本当に直った」を確認する

修正が終わったら、verification-before-completion（ベリフィケーション・ビフォア・コンプリーション）スキルが動きます。「直った気がする」ではなく、実際にテストを実行した結果をもって「完了」とします。

💡 ポイント

「直しました！」と言うだけでなく、「テスト結果がこれです」という証拠を示してから完了にするのが superpowers のルールです。

✅ 第4章のまとめ

systematic-debugging は症状ではなく根本原因を特定する
整理→仮説→検証→修正の4フェーズで進む
完了前に verification-before-completion で証拠を確認する

第 5 章

テストを書くとき

test-driven-development が「動いているけど怖い」コードから卒業させてくれます。

📖 この章でわかること

TDD（テスト駆動開発）とは何か
RED → GREEN → REFACTOR のサイクル
テストを先に書くと何がうれしいのか

「動いているけど怖い」コードとは？

コードは動いている。でも、少し変更するたびに「壊れてないかな…」と不安になる。
実際、先月直したところを今日また壊してしまった。

テストが書かれていないコードは、変更するたびに「本当に動いているか」を手で確認しなければなりません。これが「怖い」の正体です。

TDD（Test-Driven Development、テスト駆動開発）は、コードを書く前にテストを書く開発手法です。test-driven-developmentスキルがこれを強制してくれます。

RED → GREEN → REFACTOR サイクル

RED: 失敗するテストを書く

まず「こう動いてほしい」というテストを書く。この時点では機能がないので失敗する。

↓

GREEN: テストが通る最小コードを書く

テストが通るだけの最小限のコードを書く。余計な機能は足さない。

↓

REFACTOR: きれいにする

テストが通ったままの状態でコードを整理・改善する。テストが守ってくれるので安心。

実際の流れ

# ステップ1: テストを書く（まだ実装なし）
def test_add():
    result = add(2, 3)
    assert result == 5

# テストを実行 → 失敗（RED）
$ pytest test_math.py
FAILED - NameError: name 'add' is not defined

# ステップ2: 最小限の実装
def add(a, b):
    return a + b

# テストを実行 → 成功（GREEN）
$ pytest test_math.py
PASSED ✓

💡 ポイント

テストを先に書くと「何を作ればいいか」が明確になります。また、テストが通った後は自信を持って変更できます。テストがあるコードは怖くないのです。

✅ 第5章のまとめ

TDD はコードの前にテストを書く開発手法
RED（失敗）→ GREEN（成功）→ REFACTOR（整理）のサイクルで進む
テストがあると変更しても「壊れたかどうか」がすぐわかる

第 6 章

コードレビューのとき

requesting-code-review と receiving-code-review が、レビューをより実りあるものにしてくれます。

📖 この章でわかること

コードレビューを依頼するときのスキル
レビューフィードバックを受け取るときのスキル
「とりあえず直す」を防ぐ考え方

レビューを依頼するとき：requesting-code-review

実装が終わったら、requesting-code-review（リクエスティング・コード・レビュー）スキルが動きます。

このスキルは、レビューを依頼する前に以下を自動でチェックします：

計画との照合

実装が当初の計画通りになっているか確認する。

↓

テストの確認

全テストが通っているか確認する。

↓

問題のレポート

重大な問題は「ブロッカー」として報告し、軽微な問題は別途報告する。

レビューを受け取るとき：receiving-code-review

レビューでフィードバックをもらったとき、receiving-code-review（リシービング・コード・レビュー）スキルが動きます。

💡 ポイント

このスキルの特徴は「フィードバックに盲目的に従わない」ことです。「なぜそうすべきか」を技術的に検証してから実装します。疑わしいアドバイスには、根拠を確認します。

❌ スキルなし

「この変数名を変えて」と言われたら、考えずにすぐ変える。後で「それは間違いだった」とわかる。

✅ スキルあり

「なぜその変数名の方がいいのか」を確認してから変える。理由がおかしければ「これはどういう意図ですか？」と聞く。

✅ 第6章のまとめ

requesting-code-review は依頼前に計画・テストを自動チェック
receiving-code-review はフィードバックを検証してから実装する
「言われたからやる」ではなく「理解してからやる」スタンス

第 7 章

作業が終わったとき

finishing-a-development-branch が、「完了」をきれいに締めくくってくれます。

📖 この章でわかること

finishing-a-development-branch スキルが何をするか
マージ・PR・破棄の選択肢
作業ブランチを安全に終わらせる方法

「終わったけどどうする？」問題

実装は完了した。テストも全部通った。
でも…このコード、mainブランチにマージしていいのか？PRを作るべきか？そのまま置いておくか？

作業が終わっても「どう締めくくるか」で迷うことがあります。finishing-a-development-branch（フィニッシング・ア・デベロップメント・ブランチ）スキルが、選択肢を整理してくれます。

3つの選択肢

マージ

そのまま main ブランチに取り込む。小さな変更や個人プロジェクトに向いている。

PR（プルリクエスト）を作成

他の人にレビューしてもらうためのリクエストを作る。チーム開発の標準的な流れ。

ブランチを破棄

「やっぱり使わない」「試作で終わり」のとき。作業を全部捨てる。

スキルはどの選択肢を選んでも、後処理（作業ブランチの削除、worktree のクリーンアップ）を安全に行います。

💡 ポイント

PR（プルリクエスト）とは「このコードをメインに取り込んでいいですか？」とレビューを依頼する仕組みです。チームで開発するときは、これが標準的なやり方です。

✅ 第7章のまとめ

finishing-a-development-branch が「どう締めるか」を整理してくれる
マージ・PR・破棄の3択から選べる
後処理まで安全に行ってくれる

まとめ

superpowers を使い続けるために

ここまで読んでいただきありがとうございました。次のステップへ進みましょう。

全スキルの早見表

brainstorming

機能を作りたいとき・設計を整理したいとき

writing-plans

実装計画書を作りたいとき

subagent-driven-development

サブエージェントに計画を実行させたいとき（おすすめ）

executing-plans

同じセッション内で計画を実行したいとき

test-driven-development

テストを書くとき（実装前に必ず）

systematic-debugging

バグが起きたとき

verification-before-completion

「本当に直ったか」を確認したいとき

requesting-code-review

レビューを依頼したいとき

receiving-code-review

レビューフィードバックを受け取ったとき

using-git-worktrees

新しい機能開発を始める前に安全な作業ブランチを作るとき

finishing-a-development-branch

作業が完了して締めくくりたいとき

dispatching-parallel-agents

2つ以上の独立したタスクを同時並行で進めたいとき

writing-skills

新しいスキルを自分で作りたい・既存スキルを編集したいとき

using-superpowers

セッション開始時に自動で動く、スキル全体の紹介役

アップデート方法

superpowers は定期的に新しいスキルや改善が追加されます。最新版にするには：

# Claude Code のターミナルで実行
/plugin update superpowers

コミュニティ

Discord

質問・情報共有・他のユーザーとの交流ができます。
discord.gg/35wsABTejz

GitHub Issues

バグ報告や機能要望はこちら。
github.com/obra/superpowers/issues

💡 最後のポイント

superpowers のスキルは自動で動きます。特別なコマンドを覚える必要はありません。Claude Code と普通に会話しているだけで、適切なスキルが選ばれます。あとは「信じて任せる」だけです。

🎓 この教科書のまとめ

superpowers は Claude Code の「作業の型セット」でインストールするだけで動く
brainstorming → 計画 → 実装 → テスト → レビュー → 完了の流れが自動で整う
バグは systematic-debugging で根本から直す
TDD でテストを先に書くことで「怖くないコード」になる
/plugin update superpowers でいつでも最新にできる

superpowers — Built by Jesse Vincent & Prime Radiant
github.com/obra/superpowers

藤川忠彦トップページへ戻る