decision-mapping

漠然としたアイデアを計画に落とし込むのに複数のエージェントセッションが必要な場合、このスキルを呼び出します。Markdown ファイルに状態を保持する意思決定マップを作成し、未解決の疑問を解消するためのチケットを順に進めます。これには、プロトタイピング、リサーチ、または質問を重ねる作業が必要になる場合があります。このマップは特定の分野に依存せず、同じ形式に当てはまるエンジニアリング作業、コースのコンテンツ、その他あらゆるものを計画できます。

意思決定マップ

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

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

構造

エントリー（「チケット」）はそれぞれ独立したセクションとし、ミニタイトルとして読める短いダッシュケースのスラッグ（例：relational-db、auth-strategy、cache-layer）をキーにします。トークン効率を保てるほど簡潔で、マップ内で一意である必要があります。

## relational-db: Relational Or Non-Relational Database?

Blocked by: <slug>, <slug>
Status: open | in-progress | resolved
Type: Research | Prototype | Grilling | Task

### Question

<question-here>

### Answer

<answer-here>

スラッグは正式な ID であり、すべての Blocked by の依存関係と文章内での参照に使用します。コロンの後のタイトルは省略可能です。チケットは、Blocked by リストに記載されたすべてのチケットが resolved になると、ブロックが解除されます。セッションは、作業を始める前にチケットの Status: in-progress を設定してマップを保存することで、そのチケットを取得します。これにより、並行しているセッションはそのチケットをスキップします。

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

チケットの種類

チケットには 4 種類あります。

• Research：ドキュメント、サードパーティの API、またはナレッジベースなどのローカルリソースを読みます。成果物として Markdown の要約を作成します。現在の作業ディレクトリ外の知識が必要な場合に使用してください。
• Prototype：議論の具体性を高めるため、検討できる簡易的で粗削りな成果物（概要、ラフ案、スタブ、または /prototype スキルを使った UI／ロジックのコード）を作成します。プロトタイプを成果物として作成します。「どのような見た目にするか」または「どのように動作させるか」が主な疑問の場合に使用してください。
• Grilling：エージェントとの対話です。/grilling と /domain-modeling のスキルを使用します。一度に 1 つの質問をします。これがデフォルトです。
• Task：議論を進める前に済ませなければならない、文字どおりの手作業です。決めること、プロトタイプを作ること、リサーチすることはありません。データをある場所から別の場所へ移す、サードパーティのサービスに登録する、アクセス権を付与する、といった作業です。可能な範囲でエージェントが自動化し、それ以外は人間が手作業で行えるよう、正確なチェックリストを提示します。作業が完了すると解決済みになります。その回答には、実施した作業と、後続のチケットが必要とする結果情報（認証情報の保存場所、新しい URL、行数など）を記録します。

戦場の霧

マップは最前線より先を 意図的に 未完成にしてあります。あなたの役割は最前線を調査し、チケットを解決して最前線を前に進めることです。終着点への道筋が明らかになり、チケットが残らなくなるまで、戦場の霧を一つずつ晴らしてください。

呼び出し

分岐は 2 つあります。どちらの場合も、各セッションの最後には必ず 引き継ぎ を行います。1 回のセッションで複数のチケットを解決してはいけません。

マップの作成

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

1. /grilling と /domain-modeling のセッションを実施し、未決定の事項を明らかにします。一度に 1 つの質問をしてください。
2. 新しい意思決定マップを作成します。大部分を未解決のままにし、最前線を特定し、すぐに決められる項目はその場で解決します。
3. 引き継ぎます。マップの作成は 1 セッション分の作業です。チケットの解決も同時に行ってはいけません。

マップを進める

ユーザーは既存のマップへのパスを指定して呼び出します。チケットのスラッグは任意です。指定がない場合、次の決定を選ぶのはユーザーではなくあなたです。

1. マップ全体をコンテキストとして読み込みます。
2. チケットを選びます。ユーザーが指定した場合はそれを使います。そうでなければ、ドキュメント順で最初の open チケットのうち、ブロックされていないものを選びます。それをクレームします: Status: in-progress を設定し、作業前に保存します。
3. 必要に応じてスキルを呼び出しながら解決します。## Notes ブロックで名前が挙げられているものも含みます。迷った場合は、/grilling と /domain-modeling を使います。
4. チケットの本文に回答を記録し、Status: resolved を設定します。
5. 新たに発見したチケットを、正しい Blocked by エッジとともに追加します。行った決定によってマップの他の部分が無効になる場合は、それらのノードを更新または削除します。
6. ハンドオフします。

ユーザーはブロックされていないチケットを並行して実行する可能性があるため、他のエージェントがそれぞれのセッションでマップを編集していることを想定してください。

ハンドオフ

すべてのセッションを、コンテキストをクリアし、1 つ以上の新しいセッションを開いて終了します。ユーザーがコピー＆ペーストできる Next steps ブロックで締めくくります。2 つのケースがあります:

未解決のチケットが残っている場合。 現在ブロックされていないチケットを列挙し、2 つのコピー＆ペースト用オプションを提示します: 1 つのセッション向けの素のコマンド (次のチケットはあなたが選びます) と、並行実行用のブロックされていないチケットごとの固定コマンドです。新しいウィンドウごとに 1 行を貼り付けます — 1 つ、いくつか、またはすべてを開いてください。

Next steps — 3 件のチケットがブロック解除済み: auth-strategy、cache-layer、rate-limits。 コンテキストをクリアし、新しいセッションを開いてください。

1 セッション — 次にブロックされていないチケットを解決します:

Invoke /decision-mapping with the map at <path>.

並行 — ウィンドウごとに 1 行を、最大 3 つすべてまで貼り付けます:

Invoke /decision-mapping with the map at <path>, ticket auth-strategy.
Invoke /decision-mapping with the map at <path>, ticket cache-layer.
Invoke /decision-mapping with the map at <path>, ticket rate-limits.

未解決のチケットが残っていない場合。 霧は十分に押しやられ、ゴールまでの道筋は明確です — マップは完成です。(最初の grilling で霧がまったく見つからないこともあります。その場合、構築すべきマップはそもそも存在しませんでした。) 直接実装するか、/to-prd を使って複数セッションの実装をスケジュールすることをおすすめします。

Notes

ドメイン、すべてのセッションが consult すべきスキル、および計画時に提示される自由形式の常設設定を宣言する任意のブロックです。