mcpField
D
decision-mapping

decision-mapping

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

decision-mapping について

decision-mappingは、未決事項のあるアイデアを簡潔なMarkdownの意思決定マップにまとめ、複数のセッションで解決するエージェントスキルです。調査、プロトタイプ作成、対話を順序付きチケットで管理します。

主な機能

  1. 01状態を保つMarkdown決定マップ
  2. 02依存関係付きの番号チケット
  3. 03調査・プロトタイプ・対話の種類
  4. 04初期作成と再開のワークフロー
  5. 05決定に応じたマップの更新

活用シーン

  1. 01幅広いアイデアを複数回の決定に分割
  2. 02計画前に外部情報を調査
  3. 03設計上の問いをプロトタイプで検証
  4. 04既存の決定マップから作業を再開

インストール

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

$npx skills add https://github.com/utarn/engineer-skills --skill decision-mapping

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

詳細

このスキルは、漠然としたアイデアを計画にまとめるために、複数のエージェントセッションが必要な場合に呼び出されます。Markdown ファイルに状態を保持する意思決定マップを作成し、未解決の疑問を解決するためのチケットを順に進めます。解決には、プロトタイピング、調査、またはディスカッションが必要になる場合があります。

意思決定マップ

意思決定マップは、計画作業ごとに 1 つ作成する、簡潔な単一の Markdown ファイルです。プロジェクトと並べて Git で追跡します。これが正規の成果物です。マップ全体がすべてのセッションでコンテキストとして読み込まれるため、簡潔さを保つ必要があります。

チケット中に作成したアセットは、マップ内に重複して記載せず、マップからリンクしてください。

構成

番号付きの項目(「チケット」)を、それぞれ番号をキーとする独立したセクションとして記載します。

## #1: Relational Or Non-Relational Database?

Blocked by: #<ticket-number>, #<ticket-number>
Type: Research | Prototype | Grilling

### Question

<question-here>

### Answer

<answer-here>

各チケットは、エージェントの 100K トークンセッション 1 回で完了できる規模にしてください。

チケットの種類

チケットには 3 つの種類があります。

  • 調査:ドキュメント、サードパーティ API、ナレッジベースなどのローカルリソースを読みます。アセットとして Markdown の要約を作成します。現在の作業ディレクトリ外の知識が必要な場合に使います。
  • プロトタイプ:仮説の検証やデザイン空間の探索のために、UI やロジックのコードを書きます。/prototype スキルを使い、アセットとしてプロトタイプを作成します。「どのように見えるべきか」または「どのように動作すべきか」が重要な問いの場合に使います。
  • 質疑:エージェントと会話します。/grilling と /domain-modeling スキルを使います。一度に 1 つずつ質問します。これがデフォルトです。

不確定な領域

マップは、最前線より先の部分を 意図的に 不完全な状態にしておきます。最前線を調査し、チケットを解決して最前線を先へ進めることがあなたの役割です。不確定な領域を、ノードを 1 つずつ明らかにしていきます。

やがて、ゴールまでの道筋が明確になるまで不確定な領域を解消できるはずです。その時点で、それ以上チケットは必要なくなり、意思決定マップは「完了」と見なせます。

呼び出し

このスキルの呼び出し方は、bootstrap と resume の 2 通りです。

Bootstrap

ユーザーが漠然としたアイデアを提示して呼び出します。

  1. /grilling と /domain-modeling のセッションを実施し、未解決の判断事項を洗い出します。一度に 1 つずつ質問します。
  2. 新しい意思決定マップを作成します。大部分は不確定な状態とし、最前線を特定し、簡単に判断できる項目はその場で解決します。
  3. 停止します。マップの作成は 1 回のセッションで行う作業です。チケットの解決も同時に行わないでください。
Resume

既存のマップのパスとチケット番号を指定して呼び出します。

  1. マップ全体をコンテキストとして読み込みます。
  2. チケットを解決するセッションを実施し、必要に応じてスキルを呼び出します。迷った場合は、/grilling と /domain-modeling を使います。
  3. セッションで解決した内容をチケットの本文に記録します。
  4. 新たに見つかったチケットを追加します(blocked_by のエッジも正しく設定してください)。
  5. 停止します。

決定によってマップ内の他の部分が無効になった場合は、該当するノードを更新または削除してください。

並列実行

ユーザーがチケットを並列に実行する場合があるため、ほかのエージェントがマップを変更することを想定してください。

意思決定マップを省略する

最初の質疑の結果、不確定な領域がなく、未解決のチケットもない場合がよくあります。実装するだけで、ほかに作業はありません。

そのような場合は、意思決定マップを省略する選択肢をユーザーに提示してください。意思決定マップが必要なのは、複数セッションにまたがる判断が必要な場合に限られるためです。

省略する場合は、直接実装するか、/to-prd を使って複数セッションにわたる実装を計画することをおすすめしてください。

コメント