planning-prompts

ソロ開発者向けに、効果的なプロジェクト計画と Claude から Claude へのメタプロンプティングを可能にします。実行可能な計画（プロンプトそのものである PLAN.md ファイル）、階層的な計画構造（Brief → Roadmap → Phase）、および多段階の調査・計画・実装ワークフローを作成します。

<quick_start> 新しいプロジェクトを開始する:

# Claude creates planning structure
mkdir -p .planning/phases
# Creates: BRIEF.md, ROADMAP.md, phase plans

ルーティング経由で呼び出す:

• "brief" / "new project" → BRIEF.md を作成
• "roadmap" / "phases" → ROADMAP.md を作成
• "plan phase" / "next phase" → フェーズの PLAN.md を作成
• "meta-prompt" / "research then plan" → プロンプトチェーンを作成

計画はプロンプトそのものです - PLAN.md は Claude が直接実行できます。 </quick_start>

<essential_principles>

あなたは ONE 人（ユーザー）と ONE 人の実装者（Claude）のために計画を立てています。 チームはありません。ステークホルダーはいません。儀式的な手続きはありません。調整のオーバーヘッドはありません。 ユーザーはビジョナリーでありプロダクトオーナーです。Claude はビルダーです。 PLAN.md はプロンプトに変換されるドキュメントではありません。 PLAN.md はプロンプトそのものです。これには以下が含まれます: - Objective（何を、なぜ） - Context（@file 参照） - Tasks（type、files、action、verify、done、checkpoints） - Verification（全体チェック） - Success criteria（測定可能） - Output（SUMMARY.md の仕様）

フェーズを計画するとき、あなたはそれを実行するプロンプトを書いています。

出力は人間向けではなく、Claude が消費するために構造化されています: - パース用の重厚な XML 構造 - メタデータブロック（confidence、dependencies、open_questions、assumptions） - 明示的な次のステップ - コンテキスト付きのコード例 - すべての実行で SUMMARY.md を生成し、人間が素早く目を通せるようにする 計画は、一貫した品質を維持するために、コンテキスト使用量のおよそ 50% 以内で完了する必要があります。

品質劣化の曲線:

• 0-30% コンテキスト: 最高品質（包括的、徹底的、不安なし）
• 30-50% コンテキスト: 良好な品質（集中でき、管理可能なプレッシャー）
• 50-70% コンテキスト: 品質の劣化（効率モード、圧縮）
• 70% 以上コンテキスト: 低品質（自己ロボトミー化、急ぎの作業）

2-3 タスクのルール: 各計画には最大 2-3 タスクを含めるべきです。

例:

• 01-01-PLAN.md - フェーズ 1、計画 1（2-3 タスク: データベーススキーマのみ）
• 01-02-PLAN.md - フェーズ 1、計画 2（2-3 タスク: データベースクライアントのセットアップ）
• 01-03-PLAN.md - フェーズ 1、計画 3（2-3 タスク: API ルート）

参照: reference/plans.md（スコープ見積もりのセクション）

Claude は CLI または API を持つすべてを自動化します。チェックポイントは手作業ではなく、検証と意思決定のためのものです。

チェックポイントの種類:

• checkpoint:human-verify - 人間が Claude の自動化された作業を確認する（視覚的チェック、UI 検証）
• checkpoint:decision - 人間が実装の選択を行う（認証プロバイダー、アーキテクチャ）

ほとんど不要: checkpoint:human-action - CLI/API が存在しないアクションのみ（メール確認リンク、2FA を用いた Web ログインを必要とするアカウント承認）

参照: reference/plans.md（チェックポイントのセクション）

計画は拘束衣ではなくガイドです。実行中、逸脱は自動的に処理されます:

1. バグを自動修正 - 壊れた動作 -> 即座に修正し、Summary に記録
2. 不足している重要項目を自動追加 - セキュリティ/正確性のギャップ -> 即座に追加し、記録
3. ブロッカーを自動修正 - 続行できない -> 即座に修正し、記録
4. アーキテクチャについて尋ねる - 主要な構造変更 -> 停止してユーザーに尋ねる
5. 改善点を記録 - あると嬉しいもの -> ISSUES.md に自動記録し、続行

エンタープライズプロセスはありません。承認ゲートはありません。数週間のタイムラインはありません。 計画 -> 実行 -> 出荷 -> 学習 -> 繰り返し。

マイルストーンは出荷されたバージョンを示します: v1.0 -> v1.1 -> v2.0

計画には以下を絶対に含めないでください： - チーム構成、役割、RACI マトリックス - ステークホルダー管理、調整会議 - スプリントのセレモニー、スタンドアップ、レトロスペクティブ - 数週間単位の見積もり、リソース割り当て - 変更管理、ガバナンスプロセス - ドキュメント作成自体を目的とするドキュメント

企業のプロジェクト管理ごっこのように感じられるものは、削除してください。

</essential_principles>

<context_scan> 現在の状態を把握するため、呼び出しのたびに実行してください：

# Check for planning structure
ls -la .planning/ 2>/dev/null
ls -la .prompts/ 2>/dev/null

# Find any continue-here files
find . -name ".continue-here*.md" -type f 2>/dev/null

# Check for existing artifacts
[ -f .planning/BRIEF.md ] && echo "BRIEF: exists"
[ -f .planning/ROADMAP.md ] && echo "ROADMAP: exists"

受付時の質問をする前に、調査結果を提示してください。 </context_scan>

調査結果に基づいて、状況に応じた選択肢を提示してください：

計画の構成が存在する場合：

Project: [from BRIEF or directory]
Brief: [exists/missing]
Roadmap: [X phases defined]
Current: [phase status]

What would you like to do?
1. Plan next phase
2. Execute current phase
3. Create handoff (stopping for now)
4. View/update roadmap
5. Create a meta-prompt (for Claude-to-Claude pipeline)
6. Something else

プロンプトの構成が存在する場合：

Found .prompts/ directory with [N] prompt folders.
Latest: {most recent folder}

What would you like to do?
1. Create new prompt (Research/Plan/Do/Refine)
2. Run existing prompt
3. View prompt chain
4. Something else

構成が見つからない場合：

No planning or prompt structure found.

What would you like to do?
1. Start new project (create brief + roadmap)
2. Create a meta-prompt chain (research -> plan -> implement)
3. Jump straight to phase planning
4. Get guidance on approach

先に進む前に、応答を待ってください。

| 意図 | 移動先 | |--------|-------| | "brief", "new project", "start project" | reference/plans.md（create-brief セクション） | | "roadmap", "phases", "structure" | reference/plans.md（create-roadmap セクション） | | "phase", "plan phase", "next phase" | reference/plans.md（plan-phase セクション） | | "meta-prompt", "prompt chain", "research then plan" | reference/meta-prompts.md | | "research prompt", "gather info" | reference/meta-prompts.md（research セクション） | | "plan prompt", "create approach" | reference/meta-prompts.md（plan セクション） | | "do prompt", "implement", "execute" | reference/meta-prompts.md（do セクション） | | "refine", "improve", "iterate" | reference/meta-prompts.md（refine セクション） | | "handoff", "pack up", "stopping" | reference/plans.md（handoff セクション） | | "resume", "continue" | reference/plans.md（resume セクション） | | "guidance", "help" | 説明を添えて、このメニューを再表示します |

リファレンスを読んだ後は、その指示に正確に従ってください。

<project_planning_hierarchy> プロジェクト計画の階層（各レベルは前のレベルを土台にします）：

BRIEF.md          -> Human vision (you read this)
    |
ROADMAP.md        -> Phase structure (overview)
    |
RESEARCH.md       -> Research prompt (optional, for unknowns)
    |
FINDINGS.md       -> Research output (if research done)
    |
PLAN.md           -> THE PROMPT (Claude executes this)
    |
SUMMARY.md        -> Outcome (existence = phase complete)

構成：

.planning/
├── BRIEF.md                    # Human vision
├── ROADMAP.md                  # Phase structure + tracking
└── phases/
    ├── 01-foundation/
    │   ├── 01-01-PLAN.md       # Plan 1: Database setup
    │   ├── 01-01-SUMMARY.md    # Outcome (exists = done)
    │   ├── 01-02-PLAN.md       # Plan 2: API routes
    │   └── 01-02-SUMMARY.md
    └── 02-auth/
        ├── 02-01-RESEARCH.md   # Research prompt (if needed)
        ├── 02-01-FINDINGS.md   # Research output
        └── 02-02-PLAN.md       # Implementation prompt

</project_planning_hierarchy>

<meta_prompt_hierarchy> メタプロンプトの階層（Claude から Claude へのパイプライン向け）：

.prompts/
├── 001-auth-research/
│   ├── completed/
│   │   └── 001-auth-research.md    # Prompt (archived after run)
│   ├── auth-research.md            # Full output (XML for Claude)
│   └── SUMMARY.md                  # Executive summary (markdown for human)
├── 002-auth-plan/
│   ├── completed/
│   │   └── 002-auth-plan.md
│   ├── auth-plan.md
│   └── SUMMARY.md
├── 003-auth-implement/
│   ├── completed/
│   │   └── 003-auth-implement.md
│   └── SUMMARY.md                  # Do prompts create code elsewhere

目的の種類：

• Research - 計画プロンプトが利用する情報を収集します
• Plan - 実装が利用するアプローチ／ロードマップを作成します
• Do - タスクを実行し、成果物を作成します
• Refine - 既存の調査または計画の出力を改善します </meta_prompt_hierarchy>

<workflow_patterns>

<research_plan_implement> 従来型の3段階ワークフロー：

1. 調査プロンプト -> 情報を収集し、構造化された調査結果を作成します
2. 計画プロンプト -> 調査結果を参照し、段階的なアプローチを作成します
3. 実行プロンプト -> 計画を参照し、各段階を実装します

各段階では：

• 次の段階で利用する出力を作成します
• 人が確認しやすい SUMMARY.md を作成します
• 完了後にプロンプトをアーカイブします
• メタデータ（確信度、依存関係、未解決の質問）を記録します

チェーンの検出： プロンプトを作成する際は、参照できる既存の調査ファイルや計画ファイルがないか確認してください。 </research_plan_implement>

<parallel_research> 複数の独立した調査領域があるトピックの場合：

Layer 1 (parallel): 001-api-research, 002-db-research, 003-ui-research
Layer 2 (depends on all): 004-architecture-plan
Layer 3 (depends on 004): 005-implement

実行方法： レイヤー内では並行して、レイヤー間では順番に実行します。 </parallel_research>

<iterative_refinement> 最初の調査や計画の改善が必要な場合：

001-auth-research        -> Initial research
002-auth-research-refine -> Deeper dive on specific finding
003-auth-plan            -> Plan based on refined research

改善プロンプトでは、バージョン履歴を保持し、変更を記録します。 </iterative_refinement>

</workflow_patterns>

<output_requirements>

<summary_md> 実行のたびに SUMMARY.md を作成します：

# {Topic} {Purpose} Summary

**{Substantive one-liner describing outcome}**

## Version
{v1 or "v2 (refined from v1)"}

## Key Findings
- {Most important finding or action}
- {Second key item}
- {Third key item}

## Files Created
{Only for Do prompts}
- `path/to/file.ts` - Description

## Decisions Needed
{Specific actionable decisions, or "None"}

## Blockers
{External impediments, or "None"}

## Next Step
{Concrete forward action}

---
*Confidence: {High|Medium|Low}*
*Full output: {filename.md}*

要約の一文には、具体的な内容を含めてください：

• 良い例：「jose ライブラリと httpOnly Cookie を使った JWT を推奨」
• 悪い例：「調査完了」 </summary_md>

<metadata_block> 調査および計画の出力には、以下を含めてください：

<metadata>
  <confidence level="{high|medium|low}">
    {Why this confidence level}
  </confidence>
  <dependencies>
    {What's needed to proceed}
  </dependencies>
  <open_questions>
    {What remains uncertain}
  </open_questions>
  <assumptions>
    {What was assumed}
  </assumptions>
</metadata>

</metadata_block>

</output_requirements>

<reference_index> すべて reference/ 内にあります：

リファレンス	内容
plans.md	プロジェクト計画：概要、ロードマップ、フェーズ、チェックポイント、スコープの見積もり、引き継ぎ
meta-prompts.md	Claude から Claude へのパイプライン：調査／計画／実行／改善のパターン、実行エンジン
</reference_index>
<success_criteria>
スキルが成功するのは、次の条件を満たしたときです:

• コンテキストスキャンがインテークの前に実行される
• 意図に基づいて適切なワークフローが選択される
• プランが実行可能なプロンプトになっている（別個のものではない）
• 階層が維持されている（ブリーフ -> ロードマップ -> フェーズ）
• メタプロンプトにメタデータと SUMMARY.md が含まれている
• チェーンの依存関係が検出され、尊重されている
• 品質管理によりリサーチのギャップが防止されている
• ハンドオフによって再開に必要な完全なコンテキストが保持されている
• コンテキストの制限が守られている（10% で自動ハンドオフ）
• すべての作業が文書化され、逸脱が記録されている

成果物サイドカーを出力する

最終ステップとして、~/.claude/skill-analytics/last-outcome-planning-prompts.json に書き込みます:

{"ts":"[UTC ISO8601]","skill":"planning-prompts","version":"1.0.0","variant":"default",
 "status":"[success|partial|error]","runtime_ms":[estimated ms from start],
 "metrics":{"plans_created":[n],"prompts_generated":[n],"chains_built":[n]},
 "error":null,"session_id":"[YYYY-MM-DD]"}

一部のステージが失敗しても結果が生成された場合は、ステータスに「partial」を使用します。出力がまったく生成されなかった場合にのみ「error」を使用します。 </success_criteria>