plan-writing

計画の作成

出典：obra/superpowers

概要

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

タスク分解の原則

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

• 各タスクの所要時間は2〜5分にします
• 各タスクの成果は1つに絞ります
• 個別に検証できるようにします

2. 明確な検証

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

3. 論理的な順序

• 依存関係を明らかにします
• 可能な場合は並行して作業します
• クリティカルパスを明示します
• フェーズX：検証は必ず最後にします

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

• 計画ファイルはプロジェクトルートに {task-slug}.md として保存します
• タスクに基づいて名前を決めます（例：「add auth」→ auth-feature.md）
• .agents/、docs/、一時フォルダーの中には絶対に保存しません

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

🔴 固定テンプレートはありません。各計画はタスクに合わせて作成します。

原則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]

## Notes
[Any important considerations]

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

---

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

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

---

使用する場面

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