twg-context-discovery

twg-context-discovery

ルートの twg スキルを使用してください。コマンドの構文は、実行中の twg help、twg help <terms>、または twg help describe <path> から取得してください。

CLI ランチャーのフォールバック

twg <command> を実行します。シェルで command not found が発生した場合は、$HOME/.local/bin/twg （macOS/Linux）／$env:LOCALAPPDATA\Programs\twg\bin\twg.exe（PowerShell）を使用し、そのディレクトリを PATH に追加するようユーザーに伝えてください。認証エラーやコマンドエラーを PATH の問題として扱わないでください。

最初の手順

範囲を広げる前に、基準となる項目を特定します。

• 安定したキー、URL、または ARI：対象の種類が明確であれば、そのまま使用します。
• 曖昧なトピックや名前：対象範囲を分類し、順位付けの前に 2～5 個の基準項目の詳細を取得します。
• 同じ種類の基準項目が複数ある場合：対応していれば、1 回の context 呼び出しにまとめます。
• コマンドの形式が不明な場合：データを取得する前に、関連するヘルプを確認します。

曖昧なトピックについては、明示的な憲章、ロードマップ、プロジェクト、製品、またはサービスの情報を根拠に、関連性の高い候補を対象範囲ごとにグループ化します。同じ名前の機能、プラットフォーム、ドメイン、チーム、イニシアチブは、それぞれ別のまとまりとして扱います。選定前に、対象範囲との適合性、中心性、広がり、最近の状況を比較します。曖昧さが残る場合は、代替案を提示するか、質問してください。専門家や責任者を推定する前に対象範囲を定めます。近くにある著者情報や活動だけでは、より広い責任の証拠にはなりません。

ある種類の基準項目について context が案内されていない場合、パスをでっち上げずに、製品固有の詳細取得と検索結果を使用してください。

責任範囲、専門知識、承認権限、リーダーへの連絡、またはエスカレーションについては、../twg-responsibility-routing/SKILL.md を読み込んでください。関係性や依存関係の展開が必要な場合に限り、このワークフローに戻ってください。

ルートの選択

• 既知の Jira 作業項目では通常、製品固有の作業項目詳細と関係性の context が必要です。
• プロジェクトや目標では、製品固有の詳細に加えて、Jira、ドキュメント、検索、PR、会議の情報が必要です。
• トピックのオンボーディングでは、ナレッジと製品固有の情報を一度ずつ検索します。同じ名前の対象範囲にある正式なエピック、プロジェクト、目標、ページの基準項目を比較します。情報源が定める階層に基づき、中心となるプログラム／プラットフォームと、機能、移行、導入の取り組みを区別します。現在進行中の作業項目とコードを結び付ける基準項目を優先します。その詳細を取得した後、依存関係や関係者の把握に役立つ場合に限り、context と責任範囲をそれぞれ一度だけ確認します。詳細を取得する項目は最大 3 件にします。解決後に、別の表示形式で同じ情報源を再取得したり、さらに類義語を試したりしないでください。呼び出しは 6～10 回を目安とし、各カテゴリの根拠が揃ったら終了します。
• 再開、引き継ぎ、または OOO 期間中の状況把握では、../twg-status-rollups/references/personal-work-summary.md を読み込み、その再開に関するガイダンスに従ってください。関連する証拠全体から優先度を推定し、ユーザーの次の行動を変える基準項目のみ詳細を取得します。
• 依存関係マップやページ／トピックのプロンプトでは、広範な検索を証拠として扱う前に、基準項目の詳細を取得する必要があります。責任者や専門家を割り当てる前に、広いサブドメインをマッピングします。
• グラフクエリやデバッグ用の生のインターフェースは、依存関係マップの標準ルートではありません。ユーザーがそのクエリ言語を明示的に求めている場合、または型付きコマンドでは必要なエッジを表現できない場合に限り使用します。

証拠ポリシー

中心的な候補については、情報源と関係性の取得範囲を限定します。

• 情報源の取得：フィールド、所有者、ステータス、本文、コメント、URL。
• Context：グラフのエッジ、正式な外部リンク、関連する人物、チーム、プロジェクト、目標、ドキュメント、PR、コミット、ブランチ。

まず概要レベルの詳細を確認します。URL、コメント、本文の内容、または来歴が不足している場合に限り、中心となる基準項目、または関連性の高い項目最大 3 件について、完全な詳細に切り替えます。

サードパーティの URL はグラフノードとして扱います。リモートリンク、context のエッジ、説明、コメント、ADF リンク、単独の URL、リンク先の本文を収集し、関係の方向性を示す来歴を保持します。

展開ルール

• 生の件数ではなく、関係性の役割に基づいて展開します。
• 親、エピック、受信側のピア、ブロッカー、利用者、中心ページ、外部デザイン、PR、コミット、ブランチ、担当者、報告者、コントリビューター、レビュアーの各シグナルが、方向性、リスク、所有者、次のアクションを変える場合は、詳細を取得します。
• 既知の古いリンクは、グラフ全体をむやみに広げるのではなく、URL、キー、ID、ARI で直接取得します。
• 多くの類義語ではなく、有効性の高い検索語のバリエーションを使います。
• 最初のソース取得とコンテキスト／検索の確認を終えたら、いったん停止し、証拠を依頼された出力と照合します。担当者、ステータス、関係性、最新性、証拠の URL／キーが揃っている場合は、範囲を広げずに情報を統合します。
• コンテキストまたはグラフに基づくコマンドで、同じバックエンド／カバレッジエラーが 2 回発生した場合は、隣接するグラフ経路を探し続けないでください。カバレッジの不足を記録し、プロダクト標準の詳細取得済み証拠を使って続行します。
• 次の候補を追加しても、新しいエンティティ、リンク、コントリビューター、チーム、決定事項、所有者、リスク、次のアクションが増えない時点で停止します。

グラフの可視化

グラフに関する依頼では、型付きコンテキストの出力を twg visualize にパイプします。方向性、所有者、リスク、次のアクションを変えるエンティティを残し、重複はまとめます。

出力形式

• 基準となるスナップショット：対象の概要と、その重要性。
• OOO の状況把握では、優先度の高いワークストリームと次のアクションごとに情報を統合し、関係性の表は追加しません。それ以外のコンテキストに関する作業では、エンティティ、関係性、担当者、重要度、証拠を含めます。
• リスクと依存関係は、確認済みのつながりと推定される関係性を分けて示します。
• 推奨する次のアクション。
• 証拠が不完全、アクセス制限あり、古い、またはサンプリングされたものである場合は、確信度と不足情報を示します。

アンチパターン

• 検索結果だけで終わり、基準となる項目の詳細を取得しないこと。
• stdout_shape を、エンティティや URL の完全な一覧として扱わないこと。
• ピアが「Done」に見えるという理由で、グラフ／依存関係に関する依頼でのピア展開を省略しないこと。
• 1 ホップ先の候補を、タイトルだけを見て除外しないこと。
• グラフの HTML を独自に手作業で作成しないこと。