plan-writing

計画の作成

ソース：obra/superpowers

概要

このスキルは、作業を明確で実行可能なタスクに分解し、検証基準を定めるためのフレームワークを提供します。

タスク分解の原則

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

• 各タスクは2～5分で完了できるようにします
• タスクごとに明確な成果を1つ設定します
• 個別に検証できるようにします

2. 明確な検証

• 完了したことをどのように確認できますか？
• 何を確認・テストできますか？
• 期待される出力は何ですか？

3. 論理的な順序

• 依存関係を特定します
• 可能な場合は並行して作業します
• クリティカルパスを明示します
• 各タスクの完了時に検証し、その後、最終的な受け入れ確認を実施します。

4. プロジェクトルートでの動的な命名

• 計画ファイルは、PROJECT ROOTに{task-slug}.mdとして保存します
• タスクから名前を導きます（例：「認証を追加」→ auth-feature.md）
• 別の場所を指定するリポジトリやユーザーの規約がある場合はそれに従い、既存の提供済み計画があれば保持します。

計画の原則（テンプレートではありません！）

🔴 固定テンプレートは使用しないでください。計画はタスクごとに異なります。

原則1：短くする

❌ 誤り	✅ 正しい例
サブタスクのさらに下にサブタスクがある50個のタスク	明確なタスクを最大5～10個
あらゆる細かな手順を列挙する	実行可能な項目だけに絞る
冗長な説明	タスクごとに1行

ルール： 計画が1ページを超えるなら長すぎます。簡潔にしましょう。

---

原則2：一般論ではなく、具体的にする

❌ 誤り	✅ 正しい例
「プロジェクトをセットアップする」	「npx create-next-appを実行する」
「認証を追加する」	「next-authをインストールし、/api/auth/[...nextauth].tsを作成する」
「UIのスタイルを整える」	「Header.tsxにTailwindクラスを追加する」

ルール： 各タスクには、明確で検証可能な成果を設定します。

---

原則3：プロジェクトの種類に応じた動的な内容

新規プロジェクトの場合：

• どの技術スタックを使いますか？（まず決定します）
• MVPは何ですか？（最小限の機能）
• ファイル構成はどうしますか？

機能追加の場合：

• どのファイルに変更が必要ですか？
• どの依存関係が必要ですか？
• 動作をどう検証しますか？

バグ修正の場合：

• 根本原因は何ですか？
• どのファイル・行を変更しますか？
• 修正をどうテストしますか？

---

原則4：スクリプトはプロジェクト固有

🔴 スクリプトコマンドをコピーして貼り付けないでください。プロジェクトの種類に応じて選びます。

プロジェクトの種類	関連するスクリプト
フロントエンド／React	ux_audit.py、accessibility_checker.py
バックエンド／API	api_validator.py、security_scan.py
モバイル	mobile_audit.py
データベース	schema_validator.py
フルスタック	変更した内容に応じて上記を組み合わせる

誤り： すべての計画にすべてのスクリプトを追加する
正しい例： このタスクに関連し、既存であることを確認したスクリプトだけを使う。上記の名前は例示であり、同梱される前提条件ではありません

---

原則5：検証はシンプルにする

❌ 誤り	✅ 正しい例
「コンポーネントが正しく動作することを検証する」	「npm run devを実行し、ボタンをクリックしてトーストを確認する」
「APIをテストする」	「curl localhost:3000/api/usersを実行し、200が返ることを確認する」
「スタイルを確認する」	「ブラウザーを開き、ダークモードの切り替えが機能することを確認する」

---

計画の構成（柔軟で、固定ではありません！）

# [Task Name]

## Goal
One sentence: What are we building/fixing?

## Tasks
- [ ] Task 1: [Specific action] → Verify: [How to check]
- [ ] Task 2: [Specific action] → Verify: [How to check]
- [ ] Task 3: [Specific action] → Verify: [How to check]

## Done When
- [ ] [Main success criteria]

以上です。 本当に必要な場合を除き、フェーズやサブセクションは設けません。 最小限に保ち、必要な場合にのみ複雑さを加えます。

重要な考慮事項は、任意のメモとして記録できます。

---

ベストプラクティス（クイックリファレンス）

1. 目標から始める - 何を作成・修正しますか？
2. タスクは最大10個 - それ以上になる場合は、複数の計画に分けます
3. 各タスクを検証可能にする - 明確な「完了」基準を設けます
4. プロジェクト固有にする - テンプレートをコピーして使い回しません
5. 作業に合わせて更新する - 完了したら[x]を付けます

---

使用する場面

• ゼロから新しいプロジェクトを始める場合
• 機能を追加する場合
• バグを修正する場合（複雑な場合）
• 複数のファイルをリファクタリングする場合

制限事項

• このスキルは、タスクが上記の範囲に明確に該当する場合にのみ使用してください。
• 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりにしないでください。
• 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認を求めてください。