mcpField
C
codely-plan-create-subagents

codely-plan-create-subagents

github.com/codelytvエージェントワークフロー296225 回インストール1 日前に更新
リポジトリ

codely-plan-create-subagents について

実装計画を作成するスキルで、コードベースの調査をサブエージェントに委任します。フェーズと公開契約への合意後に日付付きの計画ファイルを保存し、実装を自動で始めずに次の選択肢を提示します。

主な機能

  1. 01計画作成前にガイドラインを確認
  2. 02コードベース調査をサブエージェントに委任
  3. 03フェーズと公開契約を定義
  4. 04計画ファイル作成前に承認を取得
  5. 05日付付きディレクトリに計画を保存
  6. 06次の操作を選べる形で提示

活用シーン

  1. 01複数のコード領域にまたがる変更の計画
  2. 02独立したコンポーネントの並行調査の調整
  3. 03コーディング前の実装フェーズと契約の合意

インストール

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

$npx skills add https://github.com/codelytv/agent-harness --skill codely-plan-create-subagents

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

同梱ファイルresources/plan-guidelines.md

詳細

🧠 プランの作成方法

プランの構成、各セクション、およびそれらを作成する際のルールは、resources/plan-guidelines.md で定義されています。何かを提案する前に読んでください。

  1. 指定されていない場合は、プランを作成するタスクをユーザーに尋ねます。

  2. 🔍 サブエージェントを使ったコードベースの調査 の説明に従い、サブエージェントを使ってコードベースを調査します。自分でコードベースを調査せず、委任してください。

  3. ガイドラインに従ってタスクのフェーズを定義し、フェーズ数をユーザーに選んでもらいます。

  4. ガイドラインに従って、各フェーズのタスクで作成・変更・削除するパブリックコントラクトを明記します。

  5. プランをユーザーに提案し、承認を得ます。重要：検討する具体的なコントラクトと実装フェーズについてユーザーが同意するまで、プランファイルの作成を開始しないでください。

  6. 現在の日付とタスクの説明に基づく意味のある名前を付けて、.agents/plans のサブフォルダー内に新しいファイルとしてプランを保存します。構成は次のとおりです：.agents/plans/{plan-name}/{plan-name}-plan.md。例：.agents/plans/2026_01_16-create_embeddable_changelog_widget/2026_01_16-create_embeddable_changelog_widget-plan.md。

  7. 次のステップを提案します

    • プランファイルを作成したら、次に何をしたいかユーザーに尋ねます：
      • 何もしない。
      • /codely-git-conventional-commit スキルを実行して、プランファイルをリポジトリにコミットする。プランファイルのみの変更は docs タイプとして扱います。
      • /codely-plan-phase-implement @plan-file-path スキルを実行して、プランを実装する。
      • プランファイルをコミットしてから、フェーズ 1 のみを実装する。

    重要

    ユーザーが「コミットして実装」と依頼した場合は、最初にプランファイルをコミットし、その後、フェーズ 1 のみを実装します。一度にすべてのフェーズを実装してはいけません。/codely-plan-phase-implement は呼び出しごとに 1 つのフェーズを処理します。

🔍 サブエージェントを使ったコードベースの調査

コードベースを自分で読むのではなく、サブエージェントに調査を委任して、プランに必要なコンテキスト（関連ファイル、既存の規約、現在の動作、影響を受けるコントラクト）を収集します。メインエージェントは推論とプランの作成に集中します。

  • 既存の調査用サブエージェントがあれば再利用します。
  • サブエージェントには、より低コストのモデルを使います。ツールで上書きできる場合は、同じファミリーの軽量かつ高速なモデルを選んでください。たとえば、Opus、Fable、Sonnet を使うセッションでは、調査用サブエージェントに Haiku を起動します。
  • タスクに応じて、起動するサブエージェントの数を決めます。範囲が小さく限定された変更なら 1 つでよい場合がありますが、複数の限定されたコンテキスト、レイヤー、画面に関わるタスクでは、調査領域ごとに 1 つずつ起動します。最大 4 つです。
  • 独立したサブエージェントは、調査が順次進行しないよう、1 回のバッチで並行して起動します。
  • 各サブエージェントには、範囲を限定した独立した調査を割り当てます。例：アーキテクチャ、フロントエンド、バックエンド、異なる機能、別々のリポジトリなど。
  • ファイル全体を大量に出力するのではなく、具体的なファイルパス、関連する既存のコントラクト、従うべき規約を報告するよう依頼します。
  • プランを提案する前に、サブエージェントの報告を自分で統合します。コントラクトや規約の確認がまだ必要な場合に限り、該当するファイルを直接読みます。

🗃️ フロントマター

プランファイルには、次のフロントマターを含めます。

---
name: "{ plan_name }"
description: "{ plan_description }"
created_at: "{ current_date }"

created_by:
  tool: "{ tool }"
  model:
    name: "{ model.name }"
    version: "{ model.version }"
    reasoning_effort: "{ model.reasoning_effort }"
---
  • current_date：現在の日付。ISO 8601 RFC 3339 形式（YYYY-MM-DDTHH:MM:SSZ）で記述します。
  • created_by.tool：変更に使用した AI コーディングツールの名前（例：Claude Code、Cursor、Copilot、Codex）
  • created_by.model.name：変更に使用したモデルの名前（例：Claude Opus、Cursor Composer、OpenAI GPT）
  • created_by.model.version：変更に使用したモデルのバージョン（例：4.6、1.5、5.4）
  • created_by.model.reasoning_effort：変更に使用したモデルの推論レベル（例：low、medium、high）

コメント

Markdown 対応