mcpField
T
twg-responsibility-routing

twg-responsibility-routing

github.com/atlassian生産性2483 回インストール7 週間前に更新
リポジトリ

twg-responsibility-routing について

責任に関する相談で、関係者を役割別に特定するtwgスキルです。範囲を定め、明示された責任と業務上の根拠に基づいて候補を示します。

主な機能

  1. 01責任と権限の役割を区別
  2. 02範囲を定めてから候補を選定
  3. 03明示された責任と根拠を確認
  4. 04承認者と貢献者を区別
  5. 05役割に応じた連絡先を提案

活用シーン

  1. 01プロジェクトやサービスの担当者探し
  2. 02業務領域の専門家の特定
  3. 03申請の承認者の確認
  4. 04停滞案件や部門横断案件のエスカレーション

インストール

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

$npx skills add https://github.com/atlassian/twg-cli --skill twg-responsibility-routing

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

同梱ファイルagents/openai.yamlLICENSE.txt

詳細

twg-responsibility-routing

ルートの twg スキルを使用します。「誰を、なぜ、どの役割で関与させるべきか」という質問には、このワークフローを使用します。大まかなトピックが特定の製品を指すとは限りません。

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

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

役割を分類する

以下の役割は明確に区別します。

  • 正式なオーナー:エンティティまたは領域について、正式に説明責任を負います。
  • 運用オーナーまたはメンテナー:現在の提供または運用に責任を持ちます。
  • エキスパート:特定の作業ストリームについて、情報源に裏付けられた深い知識を持ちます。
  • レビュー担当者または相談先:評価や助言を行いますが、決定権を持つとは限りません。
  • 承認者または決定権者:特定の依頼や決定を承認できます。
  • エスカレーション先またはエンジニアリング責任者:担当するエンジニアリング組織を率いるか、未解決の依頼を適切な相手に取り次ぐことができます。
  • 情報共有対象のステークホルダー:決定の影響を受けますが、その決定に責任を負うわけではありません。

担当者を探す前に対象範囲を特定する

曖昧なトピックや領域については、範囲を限定して twg rovo search "<topic>" --app confluence を1回、twg work search "<topic>" を1回実行し、結果を比較します。同じ名前の結果を、イニシアチブ、プラットフォーム、ドメイン、機能、チームごとに分類します。担当者の順位付けを行う前に、中心となるチャーター、ロードマップ、サービス、プロジェクト、または進行中の作業ストリームを2~5件確認します。情報源の内容が一致しない場合は、代替となる対象範囲を提示するか、ユーザーに確認します。

安定したプロジェクト、目標、コンポーネント、サービス、作業項目、ページ、またはリポジトリについては、その参照先を直接使用します。

責任と権限を特定する

  • 正式なオーナー、チーム、メンテナー、承認者、レビュー担当者、またはエスカレーション先を特定するには、twg responsibility get <reference> を使用します。
  • 正式な責任者が不明な場合、またはユーザーがエビデンスに基づく候補者を求めている場合に限り、twg responsibility infer <reference> を使用します。信頼度、理由コード、エビデンスの対象期間、正式な責任者と観測に基づく候補者の区別を維持します。
  • 推定は主に、対象範囲を絞った検索、正式な役割、確認済みの作業エビデンスに基づいて行います。組織データは任意です。利用できないことを理由にワークフローを中断したり、弱めたりしないでください。
  • 組織データが接続されており、候補となるリーダーやマネージャーが分かっている場合は、目的に合った最も狭いツリーを優先します。階層の確認には org-tree、複数の情報源にまたがる範囲の確認には work-tree、Jira 作業の確認には workitem-tree、PR の作成者やレビュー担当者の確認には pr-tree を使用します。ツリーの件数は、対象範囲や組織上の範囲の妥当性を確認するのに役立ちますが、それだけで専門性、所有責任、承認権限が証明されるわけではありません。
  • 承認を求める場合は、決定の根拠となる成果物を確認します。たとえば、プロジェクトまたは目標のオーナー情報、Jira のワークフローや承認者フィールド、チャーター、決定記録、または説明責任を負うチームです。推薦できる人、相談が必要な人、承認できる人をそれぞれ明示します。現在作業に貢献している人を承認者に格上げしてはいけません。
  • エスカレーションでは、最初に確認済みの最も近いオーナーを示します。オーナーが不明、対応が滞っている、複数のチームにまたがる場合、または組織上の権限が必要な依頼の場合に限り、エンジニアリングのリーダーを追加します。

対象範囲と担当者の役割を特定した後、関係性や依存関係の展開が必要な場合に限り、twg-context-discovery を使用します。責任者を尋ねる質問で、これを既定の方法として使用しないでください。

根拠と出力

強い根拠には、明示的な所有権、責任を負う役割、ワークフローに関する権限、チャーターやロードマップを主導した実績、サービスの所有権、継続的な意思決定、または中心的な貢献を繰り返した実績が含まれます。プロフィールの記述、組織上の近さ、単一の文書、生のアクティビティ、自ら作成した更新情報だけでは、根拠として不十分です。

トピックや SME のマップでは、ユーザーがより多くを求めない限り、ワークストリームは最大5つ、それぞれのワークストリームにつき主要な専門家は1人までとしてください。複数のワークストリームにまたがる根拠がある場合に限り、全体の責任者を示してください。承認やエスカレーションに関する依頼では、連絡先候補、役割、担当範囲、根拠、確信度、その人物が適任である理由、推奨する質問または連絡方法を示してください。権限が未確認の場合は、その旨を明記してください。

追加の検索によって、担当範囲、役割、権限、エスカレーション、確信度、または推奨する連絡先が変わらない場合は、検索を終了してください。

コメント