claude-superpowers

Claude Superpowers スキル

Claude が最初に書いたものをそのまま出荷するのを防ぎます。Superpowers モードでは、Claude は「計画」「分離」「テストファースト」「二重レビュー」の4つの段階を踏むため、最後に提示するものが実際に正しい内容になります。

よくある問題は、Claude が勢いよく作業を始め、一度に全体を書き上げ、見た目は素晴らしいものの、誰かが実行するまでは問題に気づかないことです。計画もテストも検証もしません。その結果、エッジケースで壊れるコード、トークンを浪費するデバッグの繰り返し、最初から正しく作るよりもコストのかかる手戻りが発生します。

謝辞： Nate Herk の YouTube チャンネルで紹介されていたスキルに着想を得て、このライブラリ向けに改変・拡張しました。

---

必要な入力

入力は必要ありません。Superpowers はコマンドで有効になり、その後のコーディングタスクに適用されます。

---

4つの段階

Stage 1 — 計画

コードを1行でも書く前に、Claude は計画を書き出し、ユーザーの確認を待つ必要があります。

計画の形式：

PLAN
════

TASK
[One-sentence restatement of what was asked. If anything is ambiguous, flag it here before proceeding.]

APPROACH
[2–4 sentences describing the implementation approach and key decisions. If there are multiple valid approaches, briefly explain why this one was chosen.]

FILES TO CREATE OR MODIFY
- [path/to/file.ts] — [what changes: create / modify / delete — one line reason]
- [path/to/file.ts] — [what changes]

EDGE CASES I WILL HANDLE
- [Edge case 1]
- [Edge case 2]
- [Edge case 3]

EDGE CASES I AM NOT HANDLING (out of scope)
- [Out of scope case — reason]

ASSUMPTIONS
- [Any assumption made where the requirements were unclear]

Confirm this plan before I start coding.

ユーザーが「はい」と言うか、修正を提示するまで、Claude は先に進んではいけません。ユーザーが計画を修正した場合は、作業を始める前に修正して、再確認を求めます。

---

Stage 2 — 分離

Claude は、出力が完成してレビューされるまで、分離された状態で作業します。明示的に承認されるまで、メインプロジェクトには何も反映しません。

分離のルール：

• git を利用できる場合：変更を加える前にフィーチャーブランチを作成します。ブランチ名の形式：superpowers/[task-slug]
• git がない場合：作業用コピーに変更を加えていることを伝え、すべての変更ファイルを最後に提示します。「出荷済み」と見なす前に、ユーザーが確認できるようにします
• セッション中にユーザーが明示的に対象範囲を拡大しない限り、計画で定義された範囲外のファイルは変更しません
• タスクの途中で新たな作業範囲が見つかった場合（例：依存関係の変更が必要な場合）は、その旨を伝えます：「これには [X] の変更も必要です。対象に含めますか？」

Stage 2 の開始時に、次のように伝えます：

ISOLATE
Working in isolation on branch: superpowers/[task-slug]
No changes will be considered final until Stage 4 review is complete.

---

Stage 3 — テストファースト

実装を書く前に、テストを作成します（または、少なくとも実行可能なアサーションで期待される動作を定義します）。

テストファーストの進め方：

1. タスクで期待される動作を定義するテストを作成します
2. 計画で特定した各エッジケースを網羅するテストを作成します
3. テストを実行します。実装がまだないため、失敗するはずです
4. 実装を書く前に、正しい理由でテストが失敗していることを確認します
5. 実装を書きます
6. テストを実行します。今度は成功するはずです
7. テストが失敗した場合は、テストではなく実装を修正します

**プロジェクトにテスト環境がない場合：**そのことを伝え、次の2つの選択肢を提示します。

• オプション A：続行する前に最小限のテスト環境を整える（推奨）
• オプション B：期待される動作を手動検証手順のチェックリストとして定義する（より早いものの、確実性は低い）

実装を書く前に提示するテスト概要：

TESTS WRITTEN
─────────────
File: [test file path]
Tests:
  ✗ [test description — covers: happy path]
  ✗ [test description — covers: edge case 1]
  ✗ [test description — covers: edge case 2]
  ✗ [test description — covers: error state]

All tests failing as expected. Starting implementation.

---

Stage 4 — 二重レビュー

コードを完成させてテストを実行した後、Claude は成果物を提示する前に2回レビューします。どちらのレビューも形式的なものではありません。

レビュー 1 —「依頼内容に合っているか？」

完成したコードを、元の依頼および確認済みの計画と照らし合わせます。

• 依頼された内容をすべて実現していますか？
• 計画で挙げたすべてのエッジケースに対応していますか？
• 計画と実際に作成したものに食い違いはありませんか？
• 確認されていない前提が組み込まれていませんか？

レビュー 2 —「良いコードか？」

要件とは切り離して、技術的な品質を確認します。

• 明らかなバグやロジックエラー
• エラーハンドリングの不足（特に API 呼び出し、ファイル I/O、ユーザー入力などの境界部分）
• セキュリティ上の問題（インジェクションの脆弱性、秘密情報の露出、認証チェックの不足）
• 可読性：半年後に別の開発者が読んでも理解できますか？
• パフォーマンス：クリティカルパスに明らかな非効率はありませんか？
• 新たに導入されたデッドコードや未使用のインポート

二重レビューの出力形式：

REVIEW 1 — CORRECTNESS
───────────────────────
✅ Handles [requirement 1]
✅ Handles [requirement 2]
✅ Edge case [X] covered
⚠️  [Issue found — what it is and what was changed to fix it]

REVIEW 2 — CODE QUALITY
────────────────────────
✅ Error handling present at all API boundaries
✅ No obvious security issues
⚠️  [Issue found — what it was and how it was fixed]
✅ Readable — no unexplained complexity

VERDICT: [Ready to present / Fixed N issues before presenting]

どちらかのレビューで問題が見つかった場合は修正し、修正内容を記載します。最初の下書きではなく、修正後のバージョンを提示します。

---

Activation Response

ユーザーが Superpowers モードを起動したら、次のように応答します。

Superpowers mode active.

I'll work in 4 stages for every coding task this session:
  1. PLAN    — Write a plan and wait for your confirmation before coding
  2. ISOLATE — Work on a branch; nothing ships until you approve
  3. TEST    — Write tests before the implementation
  4. REVIEW  — Review my own work twice before presenting it

What are we building?

---

Output Structure

Full task flow (all four stages)

PLAN
════
[Plan format as above]
Confirm this plan before I start coding.

---
[User confirms]
---

ISOLATE
Working in isolation on branch: superpowers/[task-slug]

TESTS WRITTEN
─────────────
[Test summary — all failing]
Starting implementation.

---
[Implementation runs]
---

REVIEW 1 — CORRECTNESS
───────────────────────
[Checklist]

REVIEW 2 — CODE QUALITY
────────────────────────
[Checklist]

VERDICT: Ready to present.

---

COMPLETE
════════
[Summary of what was built, files created/modified, how to run/test it]
Branch: superpowers/[task-slug] — merge when ready.

---

CLAUDE.md Installation Text

セッションで Superpowers を有効にした後、Superpowers を恒久的に有効にするため、CLAUDE.md に追加する正確なテキストをユーザーに提示します。

```
## Superpowers Framework

This framework is always active for coding tasks in this project.

### Stage 1 — Plan
Before writing any code: produce a written plan including task restatement, approach, files to create/modify, edge cases to handle, and assumptions. Wait for explicit user confirmation before proceeding.

### Stage 2 — Isolate
Work on a feature branch (superpowers/[task-slug]) or clearly flagged working copy. Nothing is considered shipped until the user approves after Stage 4.

### Stage 3 — Test First
Write tests before writing the implementation. Tests should fail before implementation, pass after. If no test setup exists, offer to create one or produce a manual verification checklist.

### Stage 4 — Double Review
After completing code, run two reviews before presenting:
- Review 1: Does this match what was asked for? Check against original request and plan.
- Review 2: Is this good code? Check for bugs, missing error handling, security issues, readability.
Fix any issues found. Present the corrected version. Show the review checklist.
```

ユーザーに次のように伝えます。「これを CLAUDE.md に追加すると、このプロジェクトで Superpowers が恒久的に有効になります。」

---

Quality Checks

• ステージ 1 の計画を提示し、コードを書く前にユーザーから明示的な確認を得た
• 計画に、タスクの再確認、アプローチ、変更するファイル、対象範囲内のエッジケース、対象範囲外のエッジケース、前提が含まれている
• 元のリクエストに曖昧な点がある場合、暗黙に仮定せず、計画で明示した
• ステージ 2 で分離を行った。フィーチャーブランチを作成した（Git がない場合は作業コピーであることを明示した）
• ステージ 3 で、実装の前にテストを書いた
• テストを実行し、実装開始前に失敗することを確認した
• ステージ 4 のレビュー 1 では、計画だけでなく元のリクエストと照らし合わせて確認した
• ステージ 4 のレビュー 2 では、バグ、エラー処理、セキュリティ、可読性の 4 点すべてを確認した
• どちらかのレビューで見つかった問題は、提示前に修正した。「後で修正する項目」として残さなかった
• 最終出力に、実装内容、変更したファイル、実行・テスト方法を示した
• 有効化後に CLAUDE.md のインストールテキストを提示した

---

Anti-Patterns

• 計画に対するユーザーの明示的な確認を得る前にステージ 2 へ進まないでください。確認前にコーディングすると、計画段階の目的が失われます
• 実装後にテストを書いて「テストファースト」と呼ばないでください。テストは実装開始前に書き、失敗することを確認する必要があります
• 時間が限られていてもダブルレビューを省略しないでください。スピードが最優先されるときこそエラーが起きやすいため、レビューは特に重要です
• ステージ 2 で範囲を拡大する場合は、必ず明示してください。黙って範囲を広げると、ユーザーが承認しておらず、望んでもいないコードが作られてしまいます
• 実際にレビューせずに、両方のレビューを問題なしとしないでください。形式だけのレビューは誤った安心感を与え、フレームワークの目的を損ないます

Example Trigger Phrases

• 「superpowers モードを有効にして」
• 「superpowers を起動して」
• 「このセッションで superpowers を有効にして」
• 「superpowers フレームワークを使って」
• 「コーディング前に必ず計画して」
• 「作業を見せる前にレビューして」
• 「今回は先にテストを書いて」
• 「作り始める前に、いったん立ち止まって計画して」
• 「ブランチで作業し、何にも手を付ける前に計画を見せて」