check-wayfinder-maps

Wayfinder マップを確認する

人間専用。 人間が名前を指定して依頼した場合にのみ、これを開始してください。別のスキルからここにたどり着いた場合は、停止し、いずれかの手順を実行する前に明示的な確認を得てください。マップを1つ読むだけなら許可は不要です。それは /read-the-map の役割であり、呼び出し可能です。

1つのリポジトリにあるすべてのWayfinder マップを対象とする、読み取り専用の調査です。/wayfinder は一度に1つのマップを扱い、「取り組み全体の状況はどうなっているのか？」と立ち止まって尋ねることはありません。このスキルは、それを1つの表にまとめます。何が決定済みか、何を実装する準備ができているか、何がまだ不明瞭か、何が何を妨げているかを示し、各マップに取り組むためのコピー可能なプロンプトを返します。

マップを読むのは /read-the-map の役割です。このスキルは複数のマップを読みます。 ここにあるすべてのマップは、そのスキルのチェックリストに沿って確認され、判定が出されます。定義はここではなく、そちらにあります。このスキルが担うのは、複数だからこそできるすべてのことです。準備状況に応じた並べ替え、ボトルネック、誰も気づいていないギャップです。

このスキルは書き込みを一切行いません。 主張、コメント、クローズ、マップの編集は行いません。トラッカーを読み、報告します。調査で取り組む価値のある作業が見つかった場合は、/wayfinder、/decisions-to-specs、または /specs-to-tickets に引き継いでください。ここでは実行しないでください。

プロセス

1. リポジトリを特定する — 手元にある情報を使い、検索するより先に尋ねる

以下の順で、すでに目の前にある情報からリポジトリを特定します。

1. 指定されている場合は引数（owner/name）。
2. 現在の作業ディレクトリにある Git リモート — クローン内では gh が自動的に推測します。
3. 明確な既存のコンテキスト — セッションで1つのリポジトリを扱っている、またはユーザーが以前にリポジトリ名を挙げており、その後の情報から別のリポジトリだとは考えられない場合。

どれでも特定できない場合、または2つの情報が食い違う場合は、どのリポジトリか、すぐにユーザーに尋ねてください — 最初にすることとして、質問は1つだけです。

境界となるのは、把握していることと探し回ることです。すでに手元にあるコンテキストは余計な手間がかからず、たいてい正しいため、それを使ってください。禁止されているのは、候補を探してファイルシステムを走査すること、.git を探してディレクトリをたどること、組織のリポジトリ一覧から有力そうなものを選ぶことです。間違ったリポジトリにたどり着く検索は、質問するよりはるかに大きなコストがかかり、ユーザーを待たせたうえに間違った答えを返すことになります。

完了条件: 検索せずに、リポジトリを1つだけ特定できていること。

2. このトラッカーで Wayfinding がどう表現されるかを把握する

/read-the-map のトラッカーの規約に従います。リポジトリごとに1回確認するものなので、ここで1回行い、マップごとには繰り返しません。

完了条件: マップの子項目を一覧表示する方法と、そのブロック状態を読み取る方法がわかっていること。

3. すべてのオープンなマップに /read-the-map のチェックリストを一括で適用する

すべてのオープンなマップを一覧表示し、それぞれについてチェックリストのすべての項目を確認します。マップ本文全体、子項目の状態とブロック状況、実装バックログ、フロンティア、判定、次のアクションです。

最も手間の少ない方法で項目を満たしてください。 すべてのマップの子項目を1回のクエリで取得するほうが、マップごとに確認するより効率的です。リポジトリのオープンな非 Wayfinder イシューを1回のクエリで取得すれば、すべてのマップのバックログを一度に確認できます。一括処理は効率化のためであり、近道ではありません。一括クエリで取得できなかったという理由で本文を読み飛ばしたマップは、読んだことにはなりません。

マップごとに行う必要があるのは、マップ本文の確認だけです。それぞれを最初から最後まで読んでください。ここでの作業の大部分を占めますが、必要な手間です。準備状況は、タイトルやチケット数からはわかりません。

完了条件: すべてのオープンなマップに判定と1行の次のアクションがあり、チケット数からの推測だけで判断したマップがないこと。

4. 報告する：表、マップごとのプロンプト、その後に全体のまとめ

順番どおりに3つのパートで報告します。すべてのマップとチケットは、名前で参照し、リンクしてください。#42 のように番号だけで示してはいけません。

表

最初の列はマップ番号にします。 その列で行を識別し、以下の各プロンプトでも同じ番号を繰り返します。読者がブロックと行を照合する際に、タイトルを横にたどる必要があってはなりません。

| # | Map | Open decision tickets | Ready for implementation | Next move |
|---|---|---|---|---|
| [157](url) | <map title> | <count + named open tickets, or "0 — all closed"> | **<verdict>** | <one line> |

表は準備状況の順に並べ、実装可能なマップを先に、保留中の未完成マップを最後に配置します。これにより、表の上部にすぐ取り組める作業が表示されます。

マップごとに1つのプロンプトを、表の下に

Next move列には実行する内容が記されています。以下はそれを実行するために入力する内容です。各行につきブロックは1つずつ、表の順番どおりに並べ、それぞれの上にマップ名を示す1行のラベルを付けます。ブロックにはプロンプトだけを記し、積み重ねたときに見分けがつかなくなるのを防ぎます。

157 — プレゼンテーションのタイミング

/wayfinder 157 /decisions-to-specs in repo mtngtools/mtng-dotnet-mono
Work in a worktree.

プロンプトの形式は/whats-nextが定めます。つまり、/wayfinder <map#> <next thing> in repo <owner/name>の行、どの移動でワークツリーに関する注意を添えるか、ラベルの書き方です。これに従い、ここで別の形式を作らないでください。

• **マップごとにブロックは1つだけです。2つにはしません。**1つのマップについて複数の道を検討するのは、/whats-nextの役割です。このスキルがマップごとに返すのは、その判定ですでに示された1つの移動先です。
• **それぞれ単独でコピーできるようにします。**各ブロックを独立させ、ブロック内にはプロンプトだけを入れます。末尾に説明文をつなげてはいけません。読者が一度クリックしてコピーし、新しいセッションにそのまま貼り付けられるようにします。
• 進む先のないマップにはブロックを付けません。Done、ブロック中、または意図的に延期されたマップが該当します。実行すべきでないプロンプトを渡す代わりに、ラベル行にその状態を記します。

要するに

短い段落を3つか4つ、箇条書きをむやみに使わず、以下を明確にします。

• いくつのマップで判断が終わっているか、また、どのマップなら最も少ない手間で着手できるか
• すべてのマップにまたがる、実際に未解決の判断チケット（通常はごく短いリストです）と、2つのチケットが同じ根本的な問いを扱っているかどうか
• ボトルネック — 最も多くのほかのマップから待たれているマップ
• 見落とされがちな空白 — 別のマップの検討から派生した後、フォローアップされていないマップです。見つけにくいものです。未解決チケットが0件のため完了したように見えますが、本文は1行しかありません。

**完了の条件：**ユーザーが課題を1つも開かずに表から次のセッションを選び、ブロックを1つコピーして着手できること。

コスト

/read-the-mapではチケット本文を詳しく確認できます。マップが1つなら手間はわずかですが、10個すべてで行うと、全体調査で済むか、午後いっぱいかかるかの違いになります。利用は控えめにしてください。マップのNotesでチケットに改訂が必要だと示されていて、その理由がわからない場合に限ります。チェックリストで求められるそれ以外の情報はすべて一覧レベルのもので、一括で取得できます。

ワークフローでの位置づけ

ワークフローの外から、全体を見渡す位置にあります。/wayfinder → /decisions-to-specs → /specs-to-tickets → /implementは、いずれも1つのマップを対象とします。**/check-wayfinder-maps**はすべてのマップを横断して読み取り、どのマップにどの入口から取り組むべきかを知らせます。1つのマップに取り組み始めたら、/read-the-mapと/whats-nextが引き継ぎます。同じチェックリストを、1つのマップに絞って確認します。

しばらく離れていた取り組みに戻るとき、複数のマップが同時に進行していてどれに着手できるか判断がつかないとき、またはまとまった期間の作業を計画する前に実行してください。