mcpField
P
planning-implementation

planning-implementation

github.com/neekolasエージェントワークフロー140 回インストール32 週間前に更新
リポジトリ

planning-implementation について

planning-implementation は、アーキテクチャ文書を依存関係順の JSON タスクグラフに変換するエージェントスキルです。自律的に作業する担当者向けに、単独で理解できるタスクと検証可能な受け入れ基準を作成します。

主な機能

  1. 01実装タスクをすべて抽出
  2. 02連番のタスク ID を生成
  3. 03並列作業向けに依存関係を整理
  4. 04対象ファイルと参照ファイルを指定
  5. 05受け入れ基準と検証方法を記述
  6. 06JSON 出力を検証

活用シーン

  1. 01アーキテクチャ計画を担当者単位のタスクに分割
  2. 02並行して実装するコーディングエージェントの準備
  3. 03全体文書なしで検証できる実装タスクの作成

インストール

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

$npx skills add https://github.com/neekolas/claude-skills --skill planning-implementation

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

詳細

実装計画

概要

アーキテクチャドキュメントからすべての実装タスクを抽出し、構造化された JSON タスクグラフにします。出力は、自律型エージェントワーカー向けのサイズに調整されたタスクの DAG です。各タスクは自己完結しており、依存関係の順序が定められ、アーキテクチャ全体にアクセスしなくても検証できる必要があります。

計画を始める前に

  1. 既存の状態を確認する：dark-factory list --job $JOB --status pending --include-content を実行して、グラフ内に残っているタスクを確認します
  2. コードベースを調査する：ドキュメントの各セクションに関連するファイルを確認する探索エージェントをバックグラウンドで起動します。タスクを作成する前に、既存のパターン、型、統合ポイントを把握します
  3. 依存関係を調査する：アーキテクチャで言及されていて、詳しく知らないライブラリ、フレームワーク、ツールがあれば、ウェブ検索で調査します

出力スキーマ

指定された出力パスに有効な JSON を書き込みます：

{
  "project": "<project name>",
  "tasks": [
    {
      "id": "T001",
      "title": "Short task title",
      "description": "Detailed description of what to implement",
      "dependencies": ["T000"],
      "files": ["src/path/to/file.ts"],
      "acceptance_criteria": "Specific, verifiable criteria",
      "verification_steps": ["cargo build", "bun test"],
      "context_files": ["specs/ARCHITECTURE.md"],
      "estimated_complexity": "low|medium|high",
      "implementation_details": "Markdown with ### headers"
    }
  ]
}
  • ID は連番にします：T001、T002、...
  • 依存関係には、リスト内の有効なタスク ID を指定する必要があります
  • ドキュメントに記載されたタスクをすべて抽出します。省略したり、統合したりしないでください

タスクの規模

各タスクは人間の開発者が1～3時間で作業できる規模とし、定型コードや生成コードの場合を除き、500 LOC 未満にします。これを超える場合は分割してください。

フィールドガイド

dependencies
  • 並列性を最大化できるように整理します。あるタスクに着手できない、またはその受け入れ基準を検証できないのが、依存タスクの完了後に限られる場合にのみ依存関係を追加します
  • 不必要な直列の依存関係は避けます
files

このタスクで直接追加、変更、または削除するファイルです。

context_files

エージェントが作業を始める前に読むべき、コードベース内のその他のファイルです。アーキテクチャのドキュメントをコンテキストファイルとして指定するよりも、関連する内容をimplementation_detailsに含めることを優先してください。ワーカーが見られるのはタスクのみです。

acceptance_criteria

検証において最も重要なフィールドです：

  • アーキテクチャドキュメントに記載のないエッジケースも含め、自動テストが必要なすべてのケースを列挙します
  • 自動テストが不可能な場合は、作業を検証するためにエージェントが実行できる手順を記述します
  • 証明すべき動作を具体的に記述します
  • 具体的なテスト用フィクスチャと検証ケースを含めます
verification_steps

実行する具体的なコマンドを記述します。例：bun test、cargo build、bun run typecheck など。

implementation_details

**最も価値のあるフィールドです。**コードベースを一度も見たことがないシニア開発者に説明するように記述します：

  • アーキテクチャドキュメントの具体的なセクション、パターン、コード例をインラインで記載します
  • 関数シグネチャ、構造体や型の定義、トレイト実装、API の形状を含めます
  • 統合ポイントを含めます。既存のモジュールや関数のうち、このコードが接続するものを記載します
  • エッジケース、エラー処理要件、既知の注意点を含めます
  • ドキュメントに例がある場合は、期待されるパターンを示すコードスニペットを含めます
  • Markdown の見出しで書式を整えます：### Pattern、### Integration Points、### Edge Cases
  • 自己完結させます。ワーカーが見られるのはタスクのみで、アーキテクチャ全体ではありません

複雑さに応じて詳細度を調整します：

複雑さ単語数
低約50～100
中約100～200
高約200～400

検証

**重要：**出力ファイルを書き込んだ後、読み戻して、有効な JSON として解析でき、スキーマに適合することを検証します。解析できない場合は修正して、再度書き込みます。ファイルに有効な JSON が含まれるまで完了してはいけません。

コメント

Markdown 対応