superpowers

Superpowers

コーディングエージェントの開発への取り組み方を変え、「すぐにコードを書く」というアンチパターンを防ぐ、体系的なソフトウェア開発フレームワークです。

このスキルを使う場面

• 複雑な機能開発
• 複数ファイルにまたがるリファクタリング
• テスト駆動開発
• コードレビュープロセス
• 体系的なデバッグ
• AI とのチームコラボレーション

基本理念

従来の AI コーディング：

User: "Add auth to the app"
AI: *immediately writes 500 lines of code*

Superpowers のアプローチ：

User: "Add auth to the app"
AI: "Let me understand requirements first..."
   → Questions → Design → Plan → Execute → Review

基本的なワークフロー

フェーズ 1：理解

1. Ask clarifying questions
2. Explore existing codebase
3. Understand constraints
4. Validate assumptions

フェーズ 2：設計

1. Create isolated workspace (git branch)
2. Break work into 2-5 minute tasks
3. Define exact specifications
4. Get approval before coding

フェーズ 3：実行

1. RED: Write failing test
2. GREEN: Minimum code to pass
3. REFACTOR: Clean up
4. Review before next task

フェーズ 4：レビュー

1. Specification compliance check
2. Code quality review
3. Integration verification
4. Branch completion decision

主な原則

1. コードを書く前に設計する

以下を理解せずにコードを書いてはいけません。

• どのような問題を解決するのか？
• 制約は何か？
• 既存のコードにどのように適合するのか？
• どのようなエッジケースがあるのか？

2. 小さく、焦点を絞ったタスク

各タスクは次の条件を満たす必要があります。

• 2～5 分で完了できる
• 単一の責務を担う
• 独立してテストできる
• 成功基準が明確である

3. テストファースト開発

RED → GREEN → REFACTOR

• まずテストを書く
• テストを通すための最小限のコードを書く
• その後、整理する
• このサイクルを決して省略しない

4. アドホックではなく、体系的に

┌─────────────────────────────────────┐
│ Systematic          vs.    Ad-hoc  │
├─────────────────────────────────────┤
│ Plan then execute   │ Jump in      │
│ Verify with tests   │ Hope it works│
│ Review each step    │ Review at end│
│ Evidence-based      │ Assumption   │
└─────────────────────────────────────┘

5. 仮定よりも証拠を重視する

• コードが動くと決めつけず、検証する
• 理解したと決めつけず、確認する
• 完了したと決めつけず、証明する

スキルライブラリ

テスト

• ユニットテストのパターン
• 統合テスト
• テストカバレッジ分析
• モックの戦略

デバッグ

1. Reproduce the issue
2. Isolate the cause
3. Root cause analysis
4. Verify the fix
5. Prevent regression

コラボレーション

• ブレインストーミング：選択肢を探る
• 計画：アプローチを組み立てる
• 並行実行：複数のエージェントを活用する
• レビュー：品質のチェックポイント

メタスキル

• フレームワークの拡張
• カスタムスキルの作成
• ワークフローの最適化

使用方法

機能の開発を始める

I want to add user authentication.

Help me think through:
1. What auth mechanism?
2. Session vs JWT?
3. Where to store credentials?
4. What existing code to modify?

開発中

I'm implementing the login endpoint.

Current state:
- User model exists
- Password hashing ready

Next: Create POST /login endpoint

Tests first, then implementation.

コードレビュー

Review my changes:
[paste diff]

Check against:
- Original spec
- Test coverage
- Code quality
- Security concerns

例：機能の追加

1. 調査

User: "Add forgot password feature"

Agent: "Before we start, let me understand:
1. How should the reset link be delivered? (email?)
2. What's the token expiry? (1 hour?)
3. Should we rate limit attempts?
4. Any existing email infrastructure?"

2. 計画

Tasks:
1. Create password_reset_tokens table
2. Add POST /forgot-password endpoint
3. Add POST /reset-password endpoint
4. Create email template
5. Add rate limiting middleware

3. 実行（タスク 1）

## Task: Create password_reset_tokens table

### Test (RED)
- Test migration creates table
- Test table has correct columns

### Implementation (GREEN)
- Create migration file
- Define schema

### Verify
- Run migration
- Check table exists

4. レビュー

## Task 1 Complete

✓ Migration runs successfully
✓ Table has: id, user_id, token, expires_at
✓ Foreign key constraint works

Ready for Task 2?

ベストプラクティス

1. 急がない：ミスを減らせば、結果的に速くなります
2. 質問する：実装前に不明点を明確にします
3. 小さく進める：検証やデバッグが容易になります
4. すべてテストする：証拠が信頼につながります
5. 頻繁にレビューする：問題を早期に発見できます

統合

以下で利用できます。

• Claude Code：マーケットプレイス経由
• Codex：プラグインのインストール
• OpenCode：直接統合

避けるべきアンチパターン

• 要件を理解せずにコードを書く
• 「時間を節約するため」にテストを省略する
• 複数の関心事を含む大規模な PR
• 検証せずにコードが動くと思い込む
• 証拠を示さずに完了を宣言する