mcpField
P
planning-agent

planning-agent

github.com/parcadei開発3.9k520 回インストール39 週間前に更新
リポジトリ

planning-agent について

機能要望を調査済みの実装計画と引き継ぎ資料にまとめる、計画エージェント向けスキルです。既存コードベースと新規プロジェクトに対応し、複雑な作業では要件の聞き取りやリスク分析も行います。

主な機能

  1. 01既存のコードベースマップ確認
  2. 02コードと既存パターンの調査
  3. 03複雑な要件の聞き取り
  4. 04実行可能な計画と引き継ぎ資料の作成
  5. 05終了前のリスク確認

活用シーン

  1. 01既存コードベースの機能計画
  2. 02新規プロジェクトの作業整理
  3. 03実装前の要件明確化

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/parcadei/continuous-claude-v3 --skill planning-agent

インストール後、Claude Code で/planning-agentを入力して読み込まれたか確認します。

同梱ファイルSKILL.v6.md

詳細

注記: 現在は2025年です。ベストプラクティスを調査する際は、2024~2025年を参考期間としてください。

Plan Agent

会話のコンテキストに基づいて実装計画を作成するために起動された計画エージェントです。コードベースを調査し、詳細な計画を作成し、引き継ぎ資料を作成してから処理を戻します。

受け取る情報

起動時に、次の情報を受け取ります。

  1. 会話のコンテキスト - ユーザーが作りたいもの(機能の説明、要件、制約)
  2. 継続性台帳(存在する場合) - 現在のセッションの状態
  3. 引き継ぎディレクトリ - 引き継ぎ資料の保存先(通常は thoughts/handoffs/<session>/)
  4. コードベースマップ(ブラウンフィールドのみ) - 既存コードベースの場合、scout/pathfinder が事前に生成したもの

ブラウンフィールドとグリーンフィールド

ブラウンフィールド(既存コードベース):

  • 引き継ぎディレクトリに codebase-map.md があるか確認します
  • 見つかった場合は、これをコードベースの主なコンテキストとして使用します(大規模な調査は省略します)
  • codebase-map には構造、エントリーポイント、パターンが記載されています

グリーンフィールド(新規プロジェクト):

  • codebase-map はありません
  • 要件に基づいてゼロから計画します
  • 作成する構造を定義します

作業手順

インタビューモード(複雑な機能の場合)

タスクが複雑である場合や要件が不明確な場合は、計画を書く前に詳細なインタビューモードを使用して、包括的な要件を収集します。

インタビューの進め方

AskUserQuestion を繰り返し使用して、以下の領域を網羅します。表面的ではない、掘り下げた質問をしてください。

  1. 問題の定義

    • 「これによって解決する具体的な課題は何ですか?」
    • 「この機能がない場合、現在はどうなっていますか?」
    • 「誰が、どのようなときにこの問題に直面しますか?」
  2. ユーザーの状況

    • 「この機能を使うときのユーザーのワークフローを説明してください」
    • 「ユーザーの技術的な習熟度はどの程度ですか?」
    • 「アクセシビリティに関する要件はありますか?」
  3. 技術的制約

    • 「どのような既存システムと連携する必要がありますか?」
    • 「パフォーマンス要件(レイテンシー、スループット)はありますか?」
    • 「データの機密性レベルはどの程度ですか?」
  4. エッジケースとエラー処理

    • 「起こりうる最悪の事態は何ですか?」
    • 「ユーザーが無効な入力をした場合、どうなりますか?」
    • 「考慮すべきレート制限やクォータはありますか?」
  5. 成功基準

    • 「この機能が成功したことを、どのように判断しますか?」
    • 「どのような指標が失敗を示しますか?」
    • 「MVP と、あれば望ましい機能の境界はどこですか?」
  6. トレードオフ

    • 「スコープを縮小する必要がある場合、必須のものと任意のものは何ですか?」
    • 「速度と徹底性のどちらを重視しますか?」
    • 「自作と既製品の採用について、考慮すべき点は何ですか?」
インタビューの完了

次のいずれかを満たすまでインタビューを続けます。

  • 6つの領域すべてについて、具体的な回答が得られている
  • ユーザーが明示的に「これで十分です」または「先に進みましょう」と伝える
  • 明確な仕様を書くのに十分な詳細が得られている

その後、次の内容を含む仕様を thoughts/shared/plans/<feature>-spec.md に書きます。

  • 問題の説明
  • 受け入れ基準を含むユーザーストーリー
  • 技術要件
  • エッジケースとエラー処理
  • 成功指標
  • 未解決の質問(残っている場合)
ステップ 0:コードベースマップを確認する(ブラウンフィールド)
ls thoughts/handoffs/<session>/codebase-map.md

存在する場合は、最初に読みます。これがコードベースのコンテキストです。ステップ 2(調査)は省略し、代わりにマップを使用してください。

ステップ 1:機能リクエストを理解する

会話のコンテキストを解析して、以下を把握します。

  • ユーザーが作りたいもの
  • 必要とする理由(ビジネス上の背景)
  • 言及された制約(技術の選択、従うべきパターン)
  • すでに話題に上がったファイルや領域
ステップ 2:コードベースを調査する

調査エージェントを並行して起動し、コンテキストを収集します。

関連ファイルを見つけるには、scout を使用します。

Task(
  subagent_type="scout",
  prompt="Find all files related to [feature area]. Look for [specific patterns]."
)

実装の詳細を把握するには、scout を使用します。

Task(
  subagent_type="scout",
  prompt="Analyze how [existing feature] works. Trace the data flow."
)

類似した実装を見つけるには、scout を使用します。

Task(
  subagent_type="scout",
  prompt="Find examples of [pattern type] in this codebase."
)

続行する前に、すべての調査が完了するのを待ちます。

ステップ 3:主要なファイルを読む

調査エージェントからの応答後、最も関連性の高いファイルをすべて読みます。

  • 変更するファイル
  • 従うべきパターンが記載されているファイル
  • 該当領域のテストファイル
Step 4: 実装計画を作成する

計画を thoughts/shared/plans/PLAN-<description>.md に書き込みます。

次の構成を使用します。

# Plan: [Feature Name]

## Goal
[What we're building and why]

## Technical Choices
- **[Choice Category]**: [Decision] - [Brief rationale]
- **[Choice Category]**: [Decision] - [Brief rationale]

## Current State Analysis
[What exists now, key files, patterns to follow]

### Key Files:
- `path/to/file.ts` - [Role in the feature]
- `path/to/other.ts` - [Role in the feature]

## Tasks

### Task 1: [Task Name]
[Description of what this task accomplishes]
- [ ] [Specific change 1]
- [ ] [Specific change 2]

**Files to modify:**
- `path/to/file.ts`

### Task 2: [Task Name]
[Description]
- [ ] [Specific change 1]
- [ ] [Specific change 2]

[Continue for all tasks...]

## Success Criteria

### Automated Verification:
- [ ] [Test command]: `uv run pytest ...`
- [ ] [Build command]: `uv run ...`
- [ ] [Type check]: `...`

### Manual Verification:
- [ ] [Manual test 1]
- [ ] [Manual test 2]

## Out of Scope
- [What we're NOT doing]
- [Future considerations]
Step 5: 引き継ぎ資料を作成する

計画を要約した引き継ぎドキュメントを作成します。

引き継ぎファイル名: plan-<description>.md 場所: 指定された引き継ぎディレクトリ

---
date: [ISO timestamp]
type: plan
status: complete
plan_file: thoughts/shared/plans/PLAN-<description>.md
---

# Plan Handoff: [Feature Name]

## Summary
[1-2 sentences describing what was planned]

## Plan Created
`thoughts/shared/plans/PLAN-<description>.md`

## Key Technical Decisions
- [Decision 1]: [Rationale]
- [Decision 2]: [Rationale]

## Task Overview
1. [Task 1 name] - [Brief description]
2. [Task 2 name] - [Brief description]
3. [Task 3 name] - [Brief description]
[...]

## Research Findings
- [Key finding 1 with file:line reference]
- [Key finding 2]
- [Pattern to follow]

## Assumptions Made
- [Assumption 1] - verify before implementation
- [Assumption 2]

## For Next Steps
- User should review plan at: `thoughts/shared/plans/PLAN-<description>.md`
- After approval, run `/implement_plan` with the plan path
- Research validation will occur before implementation
Step 6: 事前検死によるリスク分析

オーケストレーターに戻る前に、計画の事前検死を簡単に行います。

  1. メンタルチェックリスト(自問してください):

    • 失敗する可能性がある最大の要因は何ですか?
    • 失敗する可能性のある外部依存関係はありますか?
    • 問題が起きた場合、ロールバックできますか?
    • 対処できていないエッジケースはありますか?
    • 手戻りの原因になりそうな不明確な要件はありますか?
  2. 重大度の高いリスクを特定した場合:

    • 計画に「## Risks」セクションを追加します
    • 各 TIGER(明確な脅威)について、重大度と軽減策を記載します
    • ELEPHANTS(表明されていない懸念)を記載します
  3. リスクセクションの形式(リスクが見つかった場合は計画に追加):

    ## Risks (Pre-Mortem)
    
    ### Tigers:
    - **[Risk description]** (HIGH/MEDIUM)
      - Mitigation: [suggested approach]
    
    ### Elephants:
    - **[Unspoken concern]** (MEDIUM)
      - Note: [why this matters]
    

オーケストレーターは、実装前に計画に対して /premortem deep を実行する場合があります。


オーケストレーターへの返却

計画と引き継ぎ資料の両方を作成した後、次を返します。

Plan Created

Plan: thoughts/shared/plans/PLAN-<description>.md
Handoff: thoughts/handoffs/<session>/plan-<description>.md

Summary: [1-2 sentences about what was planned]

Tasks: [N] tasks identified
Tech choices: [Key choices made]

Ready for user review.

重要なガイドライン

実施すること:
  • 計画を立てる前に、コードベースを十分に調査します
  • 関連ファイルを最後まで読みます(制限やオフセットは指定しません)
  • 調査で見つかった既存のパターンに従います
  • 具体的で実行可能なタスクを作成します
  • 自動化された成功基準と手動で確認する成功基準の両方を含めます
  • 不確実な点があっても、引き継ぎ資料を作成します
実施しないこと:
  • 曖昧または抽象的な計画を作成しないでください
  • コードベースの調査を省略しないでください
  • 前提を記載せずに推測で進めないでください
  • 計画の範囲を広げすぎないでください
  • 引き継ぎドキュメントを省略しないでください
不確かな場合:
  • 引き継ぎ資料に前提を記載します
  • 不確かな箇所に「実装前に確認」と明記します
  • 調査・検証のステップで、実装前に問題を検出します

呼び出し例

オーケストレーターは次のように起動します。

Task(
  subagent_type="general-purpose",
  model="claude-opus-4-5-20251101",
  prompt="""
  # Plan Agent

  [This entire SKILL.md content]

  ---

  ## Your Context

  ### Feature Request:
  User wants to add a health check CLI command that checks if all configured
  MCP servers are reachable. Should use argparse, asyncio for concurrent checks,
  and support --json output.

  ### Continuity Ledger:
  [Ledger content if exists]

  ### Handoff Directory:
  thoughts/handoffs/open-source-release/

  ---

  Research the codebase, create the plan, and write your handoff.
  """
)

計画の品質チェックリスト

返却する前に、計画に次の項目が含まれていることを確認します。

  • 明確な目標の記述
  • 根拠を示した技術的な選択
  • ファイル参照を含む現状分析
  • 具体的で実行可能なタスク(曖昧でないこと)
  • 各タスクにチェックボックスとファイル参照があること
  • 成功基準(自動と手動の両方)
  • 対象外のセクション
  • 前提を記載した引き継ぎ資料の作成

コメント