Skip to content
cccskills
FreePublished on GitHub

plan-compare

複数の実装アプローチを並列チームで設計・議論し、比較して最適な計画を選ぶスキル。各アプローチに専門グループ(architect, critic, risk-analyst)が付き、グループ内で議論して計画を洗練する。

「どのアプローチがいいか比較したい」「複数の実装方法を検討したい」「計画を並べて比べたい」 「実装方針を複数出して」「アプローチを比較」「どっちがいいか調べて」と言われた時に使用。実装タスクで迷いがある時、設計の選択肢が複数ある時にも積極的に使う。

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md11.6 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Plan Compare

1つの実装タスクに対して複数の実装アプローチを並列で設計・議論し、 比較レポートで最適な計画を選択して実装に進むスキル。

重要: このスキルを読んだあなた(メインの Claude)が直接チームを作成し、エージェントを起動する。 サブエージェントに TeamCreate を委任してはいけない(サブエージェントは TeamCreate を使えない)。

Architecture

フラットチーム構成。あなたが TeamCreate で1つのチームを作り、 全エージェントをその中に spawn する。各グループは SendMessage で議論する。

あなた (team lead / coordinator)
  │
  │  TeamCreate("plan-compare-{slug}")
  │
  ├─ Phase 1: Explore agent でコードベース調査(チーム外、先行実行)
  │
  ├─ Phase 2: 全エージェントを一斉に spawn
  │   Group 1: plan-1-architect ←→ plan-1-critic ←→ plan-1-risk
  │   Group 2: plan-2-architect ←→ plan-2-critic ←→ plan-2-risk
  │   Group 3: plan-3-architect ←→ plan-3-critic ←→ plan-3-risk
  │
  ├─ Phase 3: 全グループ完了後、comparison agent で比較
  │
  └─ Phase 4: ユーザー選択 → 実装

Workflow

Phase 1: コードベース調査

チーム作成の 前に Explore エージェントでコードベースを調査する。 (Explore はチームに属さないスタンドアロン呼び出し)

Agent(subagent_type="Explore") で以下を調査:
- タスクに関連するファイル・モジュールの特定
- 現在の実装パターン・アーキテクチャ
- 依存関係・制約事項
- テストの状態

調査結果をもとに:

  1. 出力ディレクトリ .claude/plans/plan-compare-{task-slug}/ を作成する
  2. 調査結果を {output_dir}/research.md に保存する
  3. 実装可能なアプローチを N個 決定する

アプローチの数は以下を基準に判断する:

  • 明確に異なる技術選択がある → その数だけ(例: REST vs GraphQL vs tRPC = 3つ)
  • 段階的な複雑さの違い → 3つ(シンプル / バランス / 本格的)
  • 設計パターンの違い → その数だけ(最低2つ、最大5つ)

Phase 2: チーム作成とエージェント起動

あなた自身が 以下の手順を実行する。サブエージェントには委任しない。

Step 1: チーム作成

TeamCreate(team_name="plan-compare-{task-slug}")

Step 2: タスク作成

各グループ(N個)について、4つのタスクを作成する。 タスクの依存関係が正しくないと議論が成り立たないので注意。

Group {n} のタスク:

  TaskCreate: "plan-{n}-architect: {approach_name} の初期設計を提案"
    → TaskUpdate で owner を "plan-{n}-architect" に設定

  TaskCreate: "plan-{n}-critic: 設計をレビュー"
    → TaskUpdate で owner を "plan-{n}-critic"、addBlockedBy で上記タスクを指定

  TaskCreate: "plan-{n}-risk: リスク分析"
    → TaskUpdate で owner を "plan-{n}-risk"、addBlockedBy で architect のタスクを指定

  TaskCreate: "plan-{n}-architect: フィードバック反映 → 最終版作成"
    → TaskUpdate で owner を "plan-{n}-architect"、addBlockedBy で critic と risk のタスクを指定

3グループなら計12タスクを作成する。

Step 3: 全エージェントを一斉に spawn

1つのメッセージで全エージェントを並列起動する。 Agent ツールを N×3 回呼び出す(3グループなら9回)。

各エージェントの起動パラメータ:

Agent(
  subagent_type="pc-plan-architect",  // or pc-plan-critic, pc-plan-risk
  name="plan-{n}-architect",          // チーム内での名前
  team_name="plan-compare-{task-slug}",
  prompt="{下記のテンプレート}"
)

エージェントへのプロンプトテンプレート

architect 用:

## タスク
{ユーザーのタスク}

## コードベース調査結果
以下のファイルを読んでください: {output_dir}/research.md

## あなたの担当
- アプローチ名: {approach_name}
- アプローチ方針: {approach_description}
- あなたの役割: architect(設計担当)

## あなたのグループメンバー
- plan-{n}-architect: 設計担当(あなた)
- plan-{n}-critic: 批評担当
- plan-{n}-risk: リスク分析担当

## ワークフロー
1. TaskList でタスクを確認し、自分のタスクを in_progress にする
2. コードベースを調査し、担当アプローチの実装設計を具体化する
3. 設計案を SendMessage で plan-{n}-critic と plan-{n}-risk に送る
4. タスクを completed にする
5. TaskList で次のタスク(フィードバック反映)を確認する
6. critic と risk からのフィードバックを待ち、反映して最終版を作成する
7. 最終計画書を {output_dir}/plan-{n}-{approach_slug}.md に Write で出力する
8. タスクを completed にする

## 計画書フォーマット
# {アプローチ名}
## 概要
## 実装手順(ステップバイステップ、対象ファイル・変更内容を含む)
## 変更対象ファイル(テーブル形式)
## 技術的な詳細
## リスクと対策(critic/risk の指摘を踏まえて)
## 見送った代替案(議論で検討したが採用しなかった選択肢)

## 重要
- SendMessage は自分のグループメンバー(plan-{n}-critic, plan-{n}-risk)にだけ送ること
- 他のグループ(plan-{m}-*)には送らない

critic 用:

## タスク
{ユーザーのタスク}

## コードベース調査結果
以下のファイルを読んでください: {output_dir}/research.md

## あなたの担当
- アプローチ名: {approach_name}
- あなたの役割: critic(批評担当)

## あなたのグループメンバー
- plan-{n}-architect: 設計担当
- plan-{n}-critic: 批評担当(あなた)
- plan-{n}-risk: リスク分析担当

## ワークフロー
1. TaskList でタスクを確認し、architect のタスク完了を待つ
2. architect から SendMessage で設計案が届く
3. 自分のタスクを in_progress にする
4. 設計案を批判的に評価する(実現性、シンプルさ、保守性、テスト容易性)
5. 関連コードを自分でも Grep/Glob で裏取りする
6. フィードバックを SendMessage で plan-{n}-architect に送る
7. タスクを completed にする

## フィードバック形式
良い点 / 懸念点 / 改善提案 の3セクションで構造化する

## 重要
- SendMessage は自分のグループメンバーにだけ送ること
- 際限なく批判せず、1ラウンドで収束させる

risk 用:

## タスク
{ユーザーのタスク}

## コードベース調査結果
以下のファイルを読んでください: {output_dir}/research.md

## あなたの担当
- アプローチ名: {approach_name}
- あなたの役割: risk-analyst(リスク分析担当)

## あなたのグループメンバー
- plan-{n}-architect: 設計担当
- plan-{n}-critic: 批評担当
- plan-{n}-risk: リスク分析担当(あなた)

## ワークフロー
1. TaskList でタスクを確認し、architect のタスク完了を待つ
2. architect から SendMessage で設計案が届く
3. 自分のタスクを in_progress にする
4. 影響範囲を調査する(Grep で参照箇所、Glob で関連ファイル)
5. リスク分析を SendMessage で plan-{n}-architect に送る
6. タスクを completed にする

## リスク分析形式
影響範囲 / リスク一覧(高/中/低) / マイグレーション要件 / ロールバック計画

## 重要
- SendMessage は自分のグループメンバーにだけ送ること
- リスクには必ず対策案をセットで提示する

Step 4: 議論の監視

エージェントを起動したら、TaskList を定期的に確認して進捗を監視する。 全グループの最終タスク(architect のフィードバック反映)が completed になったら Phase 3 に進む。

Phase 3: 比較分析

全グループの計画書が完成したら:

  1. チームメンバー全員に shutdown_request を送る
  2. TeamDelete でチームを片付ける
  3. 比較エージェントを起動する(チーム外のスタンドアロン呼び出し)
Agent(subagent_type="general-purpose") で:
- 全プランファイル + research.md を読み込み
- 以下の観点で比較:
  - 実装の複雑さ(変更ファイル数・ステップ数)
  - 変更のリスク(破壊的変更の有無)
  - 保守性・拡張性
  - 実装コスト(工数の見積もり)
  - テスト容易性
  - 既存パターンとの整合性
- 比較マトリクスを作成
- 推奨アプローチとその理由を明記
- {output_dir}/comparison.md に出力

Phase 4: ユーザー選択と実装

  1. 比較レポートの要点をユーザーに提示する
  2. AskUserQuestion でどのプランで進めるか確認する
AskUserQuestion:
  question: "どのアプローチで実装しますか?"
  options: [各プランの名前 + 1行サマリー]
  1. ユーザーが選択したら: a. 選択されたプランの内容を Plan mode の plan ファイルにコピー b. EnterPlanMode で Plan mode に移行 c. プランの詳細を plan ファイルに展開(必要に応じて AskUserQuestion で不明点を確認) d. ExitPlanMode でユーザーの承認を得る e. 承認後、実装を開始(実装中も随時 AskUserQuestion で確認)

Output Directory

.claude/plans/plan-compare-{task-slug}/
  research.md                    ← コードベース調査結果
  plan-1-{approach-slug}.md      ← プラン 1
  plan-2-{approach-slug}.md      ← プラン 2
  plan-3-{approach-slug}.md      ← プラン 3
  comparison.md                  ← 比較レポート

Error Handling

  • グループの1つが失敗した場合: 他のグループの結果だけで比較を進める(最低2つあれば続行)
  • コードベース調査で十分な情報が得られない場合: AskUserQuestion でユーザーに追加情報を求める
  • 全グループが同じアプローチに収束した場合: その旨をユーザーに伝え、1つのプランとして扱う
  • エージェントが応答しない場合: 60秒待っても TaskList で進捗がなければ、そのグループをスキップ

Notes

  • 全エージェントは model: opus で起動する(CLAUDE.md のルール)
  • グループ内の通信は SendMessage で行い、グループ外には送信しない
  • エージェントは .claude/agents/ に定義: pc-plan-architect, pc-plan-critic, pc-plan-risk
  • TeamCreate はあなた(メイン Claude)が直接実行する。サブエージェントには委任しない。
  • Phase 1 の Explore と Phase 3 の比較はチーム外のスタンドアロン呼び出しで行う

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

This skill should be used when the user asks to "create a team", "spawn agents", "parallel execution", "delegate tasks to agents", "use a swarm", "team workflow", "split work across agents", "run tasks in parallel", or mentions wanting multiple agents to collaborate on a complex task.

The English summary is being prepared. Showing the original description.

sean-sunagaku/claude-code-plugin38Updated Jul 30, 2026

Agent Teams スキルを設計・構築するためのベストプラクティスガイド。 サブエージェント定義、SendMessage 通信プロトコル、タスク依存管理、 PostToolUse Hook によるログ、MCP ツール統合、コンテキストファイル設計を網羅。 7つの実績あるチームスキル(app-naming, ui-review, logo-design, persona-creation, skill-creator-team, ui-variations, aso-optimize)から抽出したパターン集。 Use when: Agent Teams を使ったスキルを新規作成したい、 既存のチームスキルの品質を改善したい、エージェント間通信のデバッグ、 チームスキルの設計パターンを知りたい。 Triggers: "agent team", "チームスキル", "エージェントチーム", "サブエージェント定義", "SendMessage パターン", "チーム設計", "エージェント間通信", "team skill", "swarm pattern"

The English summary is being prepared. Showing the original description.

sean-sunagaku/claude-code-plugin38Updated Jul 30, 2026

アプリ名・サービス名の命名を、5つの専門エージェントチームで多角的に評価・決定するスキル。 ブランディング、商標/法的リスク、デジタルプレゼンス(SEO/ASO/SNS)、国際展開(多言語/発音)の 4観点から候補を提案・調査・議論し、コンテキストファイルと議事録で次回セッションへ引き継ぐ。 Use when: アプリ名を決めたい、サービス名を変更したい、プロダクト名を検討したい、 ネーミングブレスト、名前の商標チェック、アプリ名のリネーム。 Triggers: "アプリ名", "サービス名", "プロダクト名", "ネーミング", "名前を決め", "リネーム", "rename", "app name", "naming", "ブランド名", "商標チェック"

The English summary is being prepared. Showing the original description.

sean-sunagaku/claude-code-plugin38Updated Jul 30, 2026

App Store プレビュー動画を Remotion (React) で生成する Agent Team スキル。 video-director が構成を設計し、script-writer がナレーション台本を作成し、 motion-designer が Remotion コードを実装し、preview-reviewer がコードレビューし、 frame-inspector がレンダリング結果を目視検証する。 Use when: App Store プレビュー動画を作りたい、アプリのプロモーション動画を作りたい、 Remotion で動画を生成したい。 Triggers: "プレビュー動画", "App Store 動画", "アプリ動画", "preview movie", "Remotion", "動画作成", "app preview"

The English summary is being prepared. Showing the original description.

sean-sunagaku/claude-code-plugin38Updated Jul 30, 2026

アプリのトーン&マナー(トンマナ)を8名のエージェントチームで設計するスキル。 ブランドアーキタイプ・パーソナリティ定義から、カラー・タイポグラフィ・ビジュアルスタイル・ トーン・オブ・ボイスまでを一貫設計し、Pencil (.pen) + Markdown で成果物を出力する。 「デザインテンション」(矛盾ペア)を核に、AIっぽくない独自のブランドアイデンティティを生成する。

The English summary is being prepared. Showing the original description.

sean-sunagaku/claude-code-plugin38Updated Jul 30, 2026

仕様書・要件定義からソフトウェアアーキテクチャを設計するスキル。 5人の専門エージェント(Architecture Lead・Module Designer・Dependency Analyst・ Platform Expert・Devil's Advocate)が協議しながら、 モジュール分割・依存関係・データフロー・インターフェース設計を行う。 成果物は構造化されたアーキテクチャ設計書(Markdown)。 Use when: 仕様書からどう設計するか迷っている時、モジュール分割の方針を決めたい時、 技術スタックに合ったアーキテクチャパターンを選びたい時、 設計書を作成したい時。 Triggers: "アーキテクチャ設計", "arch design", "仕様書から設計", "モジュール分割", "設計書を作りたい", "アーキテクチャを考えて", "コンポーネント設計", "依存関係を設計", "どう設計する", "design the architecture", "design from spec"

The English summary is being prepared. Showing the original description.

sean-sunagaku/claude-code-plugin38Updated Jul 30, 2026

See all skills by sean-sunagaku

Report a problem with this skill