plan-writing

計画作成

出典: obra/superpowers

概要

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

タスク分解の原則

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

• 各タスクは 2〜5 分で完了するべきです
• 1 つのタスクにつき 1 つの明確な成果
• 独立して検証可能

2. 明確な検証

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

3. 論理的な順序

• 依存関係を特定する
• 可能な場合は並行作業
• クリティカルパスを明示する
• フェーズ X: 検証は常に最後です

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

• 計画ファイルはプロジェクトルートに {task-slug}.md として保存します
• 名前はタスクから導出します（例: 「add auth」→ auth-feature.md）
• .claude/、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]

これだけです。 フェーズもサブセクションも、本当に必要な場合を除いて不要です。 最小限に保ってください。複雑さは必要なときにだけ追加します。

注意事項

[重要な考慮事項があれば記載]

---

## Best Practices (Quick Reference)

1. **Start with goal** - What are we building/fixing?
2. **Max 10 tasks** - If more, break into multiple plans
3. **Each task verifiable** - Clear "done" criteria
4. **Project-specific** - No copy-paste templates
5. **Update as you go** - Mark `[x]` when complete

---

## When to Use

- New project from scratch
- Adding a feature
- Fixing a bug (if complex)
- Refactoring multiple files