mcpField
R
read-the-map

read-the-map

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

read-the-map について

Read The Mapは、イシュートラッカー内のプロジェクトマップを評価するエージェントスキルです。定められたチェックリストで判定、着手可能な項目、次の手順を報告し、データは編集しません。

主な機能

  1. 01マップの詳細と子チケットの状態を確認
  2. 02バックログとチケットの依存関係を確認
  3. 03未完了・非ブロック・未割り当ての作業を特定
  4. 04規則に沿って判定と次の手順を提示
  5. 05編集せずに結果を報告

活用シーン

  1. 01プロジェクトマップが実装可能かを評価
  2. 02マップ上で次に着手できるチケットを探す
  3. 03仕様がチケットに分割済みか確認
  4. 04ブロッカーや延期事項を報告

インストール

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

$npx skills add https://github.com/mtngtools/agents --skill read-the-map

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

詳細

マップを読む

このマップは今どの段階にあり、次は何をするのでしょうか? このスキルは、1つのマップについてその答えを示し、マップを読むとは何を意味するのかを定めたチェックリストを管理します。/whats-next や /check-wayfinder-maps を含め、マップの読み取りが必要な他のすべての機能も、独自のリストを作るのではなく、このリストに従います。

このスキルは書き込みを行いません。 主張の追加、コメント、クローズ、マップの編集はしません。読み取って報告するだけです。読み取りによって作業が見つかった場合は、/wayfinder、/decisions-to-specs、または /specs-to-tickets に引き継ぎます。

トラッカーの規約

リポジトリの課題トラッカーに関するドキュメント(docs/agents/issue-tracker.md)で、特に Wayfinding operations セクションを読み、このリポジトリでマップ、子チケット、ブロック関係をどのように表現するかを確認します。これはマップごとではなく、リポジトリごとに確認します。ドキュメントに記載がない場合のデフォルトは次のとおりです。

  • マップ — wayfinder:map ラベルが付いた課題
  • 子チケット — マップの GitHub サブイシューで、wayfinder:<type> ラベルが付いたもの
  • ブロック関係 — GitHub のネイティブな課題依存関係。利用できない場合は、本文の Blocked by: #n 行を使用します
  • 担当者あり — チケットに担当者が割り当てられている状態

チェックリスト

以下はすべて、対象のマップについて行います。項目2と3はリストレベルのデータ(タイトル、状態、ラベル、担当者、依存関係)に基づいています。トラッカーは、何も開かなくてもこれらを返します。項目1では、必ず本文を読みます。

  1. マップの本文全体。 Destination、Notes(延期の目印、実行時の上書き、この作業で参照するスキル)、Decisions so far、Specs settled、Not yet specified、Out of scope。準備状況を示す情報はここにあり、チケット数にはありません。未完了の子チケットがゼロのマップでも、未着手で曖昧なままの場合があります。
  2. 子チケットの状態 — オープンかクローズか、wayfinder:<type>、担当者、ブロック関係。
  3. ビルドのバックログ — /specs-to-tickets による、オープン中の wayfinder 以外の課題と、マージ済みのものがあるかどうか。準備状況は、仕様がチケットに分割されているかどうかによって決まります。
  4. フロンティア — オープン中で、ブロックされておらず、担当者もいない子チケット。次のセッションで実際に着手できるのは、この集合です。
  5. 判定 —表から必ず1つ選びます。
  6. 次の一手 —対応表から1つ選びます。

マップの Notes は、推論より優先されます。マップに「チケット化の準備完了」と書かれている場合、それは作成者の判断として報告し、曖昧さが明らかに示されている場合に限って異議を唱えます。

判定

次の2つを順番に確認します。意思決定は完了していますか? 次に、仕様はビルドチケットに分割されていますか?

判定条件
はい — すでに分割済み未完了の意思決定がなく、仕様が確定しており、実装チケットが存在する
はい — まだ分割されていない未完了の意思決定がなく、仕様が確定しており、ビルドチケットはまだない
はい、ただし条件あり分割済みだが、チケットに修正メモが付いているか、後からの意思決定によって無効になっている
いいえ — マップの作成が必要仮のマップであるか、まだどのチケットも扱っていない曖昧さがある
いいえ — #n にブロックされている別のマップの成果を待っている
いいえ — 意図的に延期マップの Notes で将来のイベントまで延期されている。手を付けない
完了すべてクローズ済みで、分割済みかつマージ済み

判定 → 次の一手

判定次の一手
着手可能なオープン中のフロンティアチケットtake #<n> — <title> — 最も多くのブロックを解除するものか、最も早く終えられるもの
未完了の意思決定がなく、仕様が確定していない/decisions-to-specs
はい — まだ分割されていない/specs-to-tickets
はい — すでに分割済み/implement #<n> — <title>
分割済みだが、チケットの内容がまだ推測に基づいている/prototype #<n> — <title> — 要望があった場合、または安定した形に議論でまとめるより、実験的なサイクルで試す場合
いいえ — マップの作成が必要曖昧さに対して /wayfinder
ブロック中または延期中ここで行うことはありません。何を待っているかを明記します
完了マップは完了です。次の一手は別のマップです

確認範囲

チケットの本文はチェックリストの対象外です。本文を開くのは、次の場合だけです。

  • マップのNotesに修正が必要とあるのに、理由がわからない場合
  • フロンティアチケットが2件進行中で、タイトルだけでは次に取り組むべきものを判断できない場合

それ以外にチェックリストで必要な情報は、すべてリストのレベルで確認できます。

出力

簡潔にします。判定、次の一手を1行で、フロンティアの名前、そしてそれらと矛盾するマップ上の情報を記載します。すべてのマップとチケットは、名前を使ってリンクしてください。裸の#42は使わないでください。マップが1つの場合は表を使わず、文章のほうが簡潔です。

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

ほかのスキルが前提とする確認作業です。/whats-nextは、このスキルの次の一手をプロンプトに変換します。/check-wayfinder-mapsは、開いているすべてのマップに対してチェックリストを一度に実行します。すべての項目を網羅する必要がありますが、マップごとに個別に確認する代わりに、一括トラッカークエリで満たしてもかまいません。マップが10件ならそれが効率的ですが、1件なら意味がありません。

コメント