ぼんやりとしたアイデアが舞い降りた。ひとつのエージェントセッションには大きすぎて、霧に包まれている。ここから目的地への道筋はまだ見えていない。ウェイファインディングとは、その道筋を見つけることであって、目的地に突っ走ることではない。このスキルは、リポジトリのイシュートラッカー上に共有マップとして道筋を描き、その決定チケット（答えが出れば決定となる質問であり、実行すべきビルドの断片ではない）を、ルートが明確になるまで一つずつ処理していく。
目的地は取り組みごとに異なり、その命名こそがマッピングの第一歩となる。目的地はすべてのチケットを形作る。仕様書として後続に引き渡して反復するものかもしれないし、計画を始める前に確定させておくべき決定かもしれない。あるいは、データ構造の移行のように、その場で行う変更かもしれない。マップはドメインにとらわれない。エンジニアリング作業、コースコンテンツ、どんな形にも適合する。
計画し、実行するな
ウェイファインディングはデフォルトで計画である。各チケットは決定を解決し、決定すべきことが何も残らず、誰かが実行に移す前に道筋が明確になった時点でマップは完了する。「つい作業をしてしまいたい」という衝動は、通常、マップの端に到達し、引き継ぎのタイミングが来たという合図である。取り組みのNotesでこれを上書きし、実行をマップ自体に含めることもできるが、そうでなければ、決定を成果物として生み出せ。
名前で参照せよ
すべてのマップとチケットはイシューであるため、名前（タイトル）を持つ。人間が読むものすべて（ナレーション、マップの「Decisions so far」）において、番号やスラッグだけではなく、その名前で参照せよ。#42, #43, #44 の羅列は読みにくい。名前は一目で読める。IDとURLは消えるわけではなく、名前がそのリンクを包み込むが、名前の代わりにはならない。
マップ
マップはこのリポジトリのイシュートラッカー上の単一のイシューであり、wayfinder:map というラベルが付いた、標準的な成果物である。そのチケットはマップの子イシューである。
マップは索引であり、保管場所ではない。行われた決定をリストし、その詳細を保持するチケットを指し示す。決定は正確に一つの場所、すなわちそのチケットに存在するため、マップはそれを決して言い換えず、要約してリンクするのみである。
マップ、その子チケット、ブロッキング、フロンティアクエリが物理的にどこに存在するかは、トラッカー固有である。 イシュートラッカーは提供されているはずである。提供されていない場合は、ユーザーに /setup-matt-pocock-skills を実行するよう伝えよ。_この_リポジトリがそれらをどのように表現するかについては、トラッカードキュメントの「Wayfinding operations」セクションを参照せよ。トラッカーが提供されていない場合は、デフォルトでローカルマークダウントラッカーを使用せよ。
マップの本文
マップ全体の低解像度版。セッションごとに一度読み込む。未完了のチケットはリストされない。それらは未完了の子イシューであり、クエリによって見つけられる。
## Destination
<このマップの終着点がどのようなものか：この取り組みが道筋を見つけようとしている仕様、決定、または変更。一文か二文。セッションはチケットを選ぶ前に、毎回これに照らし合わせる。>
## Notes
<ドメイン。すべてのセッションが参照すべきスキル。この取り組みにおける標準的な選好。>
## Decisions so far
<!-- 索引：完了したチケット1行につき1エントリ。関連性を判断するのに十分な情報を記載し、詳細はリンク先のチケットへ。 -->
- [<完了したチケットのタイトル>](link): <答えの一行要約>
## Not yet specified
<!-- 「Fog of war」を参照。スコープ内だが、まだチケット化できない霧。フロンティアが進むにつれて卒業する。 -->
## Out of scope
<!-- 「Out of scope」を参照。目的地を超えて除外された作業。完了であり、卒業することはない。 -->
チケット
各チケットはマップの子イシューである。トラッカーのイシューIDがそのアイデンティティである。本文は質問であり、100Kトークンのエージェントセッション1回分のサイズに収める。
## Question
<このチケットが解決する決定または調査>
各チケットには wayfinder:<type> ラベルが付与される（research、prototype、grilling、task のいずれか。チケットタイプを参照）。
セッションは、作業を行う前に、まずチケットをマップを推進する開発者にアサインすることでクレームする。これにより、同時実行セッションはそのチケットをスキップする。そのアサインイーがクレームである。オープンで未アサインのチケットは、未クレームである。
ブロッキングには、トラッカーのネイティブな依存関係を使用する。これは、トラッカーのUI上でフロンティアを_視覚的に_レンダリングするために不可欠であり、人間がマップを開かずにどのチケットが取得可能かを確認できる。ネイティブなブロッキングを持たないトラッカーのみ、本文の規約にフォールバックする。チケットは、それをブロックするすべてのチケットがクローズされたときにアンブロックされる。フロンティアとは、オープンかつアンブロックかつ未クレームの子チケットであり、既知の領域の端である。
答えは本文の一部ではない。解決時に記録される（マップを進めるを参照）。チケットの解決中に作成されたアセットは、イシューにリンクされ、本文に貼り付けられない。
チケットタイプ
すべてのチケットは、HITL（人間がループ内にいる。人間と協力して作業し、人間が自分自身で発言する）またはAFK（エージェント単独で推進する）のいずれかである。HITLチケットは、そのライブなやり取りを通じてのみ解決される。エージェントは人間側の立場に立って代弁してはならない（自身の質問に答えるグリリングエージェントはこれを破っている）。
- Research (AFK)：ドキュメント、サードパーティAPI、ナレッジベースなどのローカルリソースを読み、決定が待つ事実を明らかにする。Skillツールを「research」で呼び出すサブエージェントによって解決される。現在の作業ディレクトリ外の知識が必要な場合に使用する。
- Prototype (HITL)：安価でラフで具体的な成果物（アウトライン、ラフ案、スタブ、UI/ロジックコードなど）を作成し、それに反応してもらうことで議論の確度を高める。Skillツールを「prototype」で呼び出す。プロトタイプをアセットとしてリンクする。「どのように見えるべきか」「どのように振る舞うべきか」が重要な質問である場合に使用する。
- Grilling (HITL)：会話。デフォルトのケース。常にSkillツールを2回呼び出し、「grilling」と「domain-modeling」を指定する。
- Task (HITL または AFK)：決定を下す_前_に発生しなければならない手動の作業。決定すべきことも、プロトタイプすべきことも、調査すべきこともないが、議論が完了するまでブロックされる。サービスのAPIを判断できるようにサインアップする、アクセス権をプロビジョニングする、データを移動してその形状を確認できるようにするなど。これが唯一、決定ではなく_実行_を行うタイプであり、その位置づけは、決定をアンブロックすることによって得られる。目的地を届けることではない。エージェントは可能な限り単独で推進する（AFK）。そうでない場合は、人間に正確なチェックリストを渡す（HITL）。作業が完了した時点で解決される。答えには、行われた作業と、それに依存する後のチケットが参照するであろう結果の事実（認証情報の場所、新しいURL、行数など）を記録する。
戦霧
マップは_意図的に_不完全である。まだ見えないものはマッピングするな。ライブのチケットの先には戦霧が広がっている。まだ未解決の質問に依存しているため、まだ正確に特定できない決定や調査がぼんやりと見えている状態である。チケットを解決すると、その先の霧が晴れ、新たに特定可能になったものが、一つずつ新しいチケットとして卒業する。目的地までの道筋が明確になり、チケットが残らなくなるまでこのプロセスを繰り返す。
マップの Not yet specified セクションは、そのぼんやりとした見通しを書き留める場所である：疑わしい質問、後で再訪する領域。目的地_に向かう_未発見のフロンティアである。ここにあるものはすべてスコープ内だが、チケット化するにはまだ十分に鮮明ではない。見通しに応じて、緩やかにまたは完全に記述せよ。これは、取り組みの方向性を読む共同作業者への道標としても機能する。
霧か、チケットか？ 判断基準は、今、質問を正確に述べられるかどうかであり、今答えられるかどうかではない。
- チケットにするのは、質問がすでに鮮明である場合。たとえブロックされていてすぐに行動できなくても。
- Not yet specified にするのは、まだそれほど鮮明に表現できない場合。霧をチケットサイズにあらかじめスライスしてはならない。霧はチケットよりも粗く、ひと固まりの霧がフロンティアに達したときに、複数のチケットに卒業することも、ゼロになることもある。
Not yet specified は、すでに決定されたもの（Decisions so far）、すでにライブのチケットであるもの、そしてスコープ外のもの（次のセクション）を除外する。
スコープ外
霧は_目的地に向かって_のみ集まる。目的地がスコープを固定するため、それを超える作業はスコープ外である。それは霧ではなく、Not yet specified に属さない。マップ上に独自の Out of scope セクションが設けられる。_この_取り組みから意識的に除外した作業である。スコープ（鮮明さではない）が、ここに配置する基準である。
スコープ外の作業が卒業することはない（フロンティアは目的地で停止する）。したがって、目的地が再描画された場合にのみ再登場し、その際も新たな取り組みとしてであり、再開ではない。
何かをスコープ外と判断することは、スコーピング行為であり、ルート上のステップではない。すでに存在するチケットが目的地の先にあることが判明した場合（マッピング中に誤ってスコープ内に入れてしまったか、解決によって明らかになったか）、それをクローズし（クローズされたチケットはフロンティアから明確に外れる）、Out of scope セクションに一行を追加する。要約と、なぜスコープ外かの理由、クローズしたチケットへのリンクを記載する。それは Decisions so far には残さない。Decisions so far は実際に歩いたルートを記録するものであり、スコープ境界はルート上のステップではない。
呼び出し
2つのモードがある。いずれの場合も、リサーチチケットを除き、1セッションで複数のチケットを解決してはならない。
マップを描く
ユーザーが漠然としたアイデアを添えて呼び出す。
- 目的地を命名する。 Skillツールを2回呼び出し、「grilling」と「domain-modeling」を指定して、このマップが何への道筋を見つけようとしているのか（仕様、決定、または変更）を確定させる。目的地がスコープを固定するため、最初に確定させる。
- フロンティアをマッピングする。 再度グリリングを実行するが、今回は幅優先で行う。特定のスレッドを深く掘り下げるのではなく、空間全体に広がり、未解決の決定と、今すぐ取れる最初のステップを表面化させる。これによって霧が表面化しなかった場合（目的地への道筋がすでに明確で、旅全体が1セッションに収まるほど小さい場合）、マップは不要である。中止し、ユーザーにどのように進めたいか尋ねよ。
- マップを作成する（ラベル
wayfinder:map）。Destination と Notes を記入し、Decisions so far は空、霧を Not yet specified にスケッチする。 - 現在特定できるチケットを作成する（マップの子イシューとして）。次に、2回目のパスでブロッキングエッジを配線する（イシューが互いを参照するにはIDが必要であるため）。配線により、チケットはフロンティアとブロックされたものに分類される。まだ特定できないものはすべて霧の中に残る。つまり Not yet specified セクションに残る。
- リサーチサブエージェントを起動する。 作成したばかりの各
researchチケットに対して、Skillツールを「research」で呼び出すサブエージェントを起動し、並行して解決する。その調査結果は、使い捨てのresearch/<name>ブランチにキャプチャし、チケットからコンテキストポインタを設定する。 - 停止する。マッピングは1セッションの作業である。何も手動で解決しない。
マップを進める
ユーザーがマップ（URLまたは番号）を添えて呼び出す。チケットはオプションである。指定がない場合は、ユーザーではなく、次の決定を選択する。
- マップを読み込む。低解像度ビューであり、すべてのチケット本文ではない。
- チケットを選択する。ユーザーが指定した場合はそれを使用する。それ以外の場合は、順序に従って最初のフロンティアチケットを取得する。それをクレームする。いかなる作業よりも先に、自分自身にアサインする。
- 解決する。必要に応じてズームする。関連するチケットやクローズされたチケットの全文をオンデマンドで取得する。
## Notesブロックに指名されているスキルについては、Skillツールを呼び出す。不明な場合は、Skillツールを2回呼び出し、「grilling」と「domain-modeling」を指定する。 - 解決を記録する。答えを解決コメントとして投稿し、イシューをクローズし、マップの Decisions so far にコンテキストポインタを追加する。
- 新たに表面化したチケットを作成する（作成してから配線する）。答えによって特定可能になった霧を卒業させ、各卒業した固まりを Not yet specified から削除し、新しいチケットとしてのみ存在させる。答えによって、あるチケット（このチケットまたは別のチケット）が目的地の先にあることが明らかになった場合は、ルート上で解決するのではなく、スコープ外として扱う。決定がマップの他の部分を無効にする場合は、それらのチケットを更新または削除する。
ユーザーはアンブロックされたチケットを並行して実行できるため、他のセッションが同時にトラッカーを編集している可能性があることを想定せよ。