twg-responsibility-routing について
責任に関する相談で、関係者を役割別に特定するtwgスキルです。範囲を定め、明示された責任と業務上の根拠に基づいて候補を示します。
主な機能
- 01責任と権限の役割を区別
- 02範囲を定めてから候補を選定
- 03明示された責任と根拠を確認
- 04承認者と貢献者を区別
- 05役割に応じた連絡先を提案
活用シーン
- 01プロジェクトやサービスの担当者探し
- 02業務領域の専門家の特定
- 03申請の承認者の確認
- 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人までとしてください。複数のワークストリームにまたがる根拠がある場合に限り、全体の責任者を示してください。承認やエスカレーションに関する依頼では、連絡先候補、役割、担当範囲、根拠、確信度、その人物が適任である理由、推奨する質問または連絡方法を示してください。権限が未確認の場合は、その旨を明記してください。
追加の検索によって、担当範囲、役割、権限、エスカレーション、確信度、または推奨する連絡先が変わらない場合は、検索を終了してください。