mcpField
T
twg-status-rollups

twg-status-rollups

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

twg-status-rollups について

twg-status-rollups はルートの `twg` skill と併用し、個人・チーム・組織の活動、プロジェクト状況、意思決定の準備状況をまとめるスキルです。対象範囲の特定、証拠の選択、組織ツリーに応じたクエリ経路を定めています。

主な機能

  1. 01人員・チーム・プロジェクト範囲の特定
  2. 02組織ツリーに応じたクエリ経路の選択
  3. 03PR、Jira、目標の進捗集約
  4. 04証拠要件に応じたデータ取得
  5. 05状況・リスク・確度の要約

活用シーン

  1. 01個人の週次報告やスタンドアップの準備
  2. 02チームや組織の成果の集約
  3. 03プロジェクト状況やローンチ準備の確認
  4. 04組織のボトルネック、停滞した目標、リスクの特定

インストール

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

$npx skills add https://github.com/atlassian/twg-cli --skill twg-status-rollups

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE.txt
references/
decision-readiness.md
personal-work-summary.md

詳細

twg-status-rollups

ルートの 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 の問題として扱わないでください。

使用する場面

  • 「自分/チーム/組織は何に取り組んだか」、週次更新、スタンドアップ、引き継ぎ、または休暇後の再開
  • 「プロジェクト/目標/トピック/重点領域の状況」
  • 「このプロジェクトはローンチの準備ができていますか?」または実施可否の概要
  • リーダーシップ、月次、年次、サイクル、評価、または目標との整合性に関する報告
  • 組織のボトルネック、優先事項、停滞した目標、またはプロジェクトのリスク

最初の手順

取得前に対象範囲を確定します。

  • 人/チーム/組織:ID、名簿、または組織ツリーのグループを特定します。
  • プロジェクト、目標、重点領域、またはトピック:ネイティブキー、ARI、URL、名前、または中心となるページ/作業項目のアンカーを特定します。

期間を設定します。指定がなく、正確さが重要な場合は期間を確認してください。それ以外の場合は、最近の期間を限定して設定し、その旨を明記します。個人の要約は1年以内に収めてください。

ツリーのルーティングマトリックス

  • pr-tree:マネージャーまたはチーム別のマージ済み/オープン PR、レビュー、リリース済みの作業、またはリポジトリの動向。PR に限定した証拠には、これをデフォルトとして使用します。
  • org-tree:マネージャーの階層、名簿、報告体制。グループ分けにのみ使用し、成果の証拠には使用しません。
  • workitem-tree:組織ツリー別の Jira チケットの負荷と、進行中/完了の推移。
  • work-tree:Jira、PR、目標、プロジェクト、ドキュメント、動画を横断した組織の件数。PR のみ、または Jira のみを対象とする依頼には使用しません。

最短手順:PR ベースのリーダーシップ向け集計

PR ベースのリーダーシップ向け依頼では、次の手順に従います。

  1. 指定された対象範囲と期間を維持します。「過去2週間」の場合は --since 14d を使用します。
  2. 最初に pr-tree を使用します。これは報告ツリーの directReports ごとにグループ化します。階層の把握には org-tree のみを追加します。
  3. オプションの形式が不明な場合は、データ取得の前に twg help describe "pr-tree" を確認します。互換性のないフラグの組み合わせを試さないでください。
  4. まず件数を取得し、その後、リポジトリまたはテーマの証拠を確認するために、サポートされているサンプリング/全件取得を最大1回行い、マネージャー/チーム単位でまとめます。 グループを埋めるために個人ごとのクエリを実行しないでください。重要なテーマの証拠が不足している場合に限り、対象を絞った PR の追加確認を1回行います。
  5. 名前の挙がった不足事項に対してのみ、二次的な情報源を1つ追加します。

呼び出し回数は2~4回を目安にします。

証拠に関する方針

  • 証拠は依頼の制約に合わせます。マージ済み PR に関する結論には PR の証拠が必要です。
  • ツリーを使う場合は、まず件数を取得します。テーマ、リスク、または担当者の特定に必要な場合にのみ、具体例を取得します。
  • 幅広いリストは、最小限の詳細取得の前に優先順位を付けます。
  • 優先順位を付けた項目は1回の呼び出しでまとめて取得し、項目ごとに呼び出さないでください。goals get、projects get、focus-areas get、jira workitem get、docs get、pull-requests get は、キーまたは URL をすべて一度に指定できます。
  • 作成者としての成果を、レビュー、調整、影響力と区別します。
  • 証拠が十分になったら終了します。バックエンドで同じ失敗が2回続いたら、その経路での取得を中止し、不足している情報を報告します。

レシピカード

個人または個人向けの更新

対象者を特定し、最近の Jira 作業、PR、ドキュメント/ページ、会議、プロジェクト/目標への関与を取得します。対象、通知、PR の詳細取得、成果優先のルールについては references/personal-work-summary.md を読み込みます。成果、レビュー、ドキュメント/戦略、調整、影響力を分けて記載します。

短期間の個人向け更新/スタンドアップ

references/personal-work-summary.md を読み込みます。対象者を特定し、指定されたプロジェクトと期間を維持します。重要な作業を優先し、証拠の不足と確認済みのブロッカーを分けて記載します。

チームまたは組織のリーダーシップ向け報告

最初に組織ツリーを確認します。組織のプロジェクトには twg projects query --scope org --include-inferred([Paid: Enriched])を使用します。結果をグループ化し、勢い、ブロッカー、または所有権に影響する外れ値の詳細を取得します。

プロジェクトまたは目標の状況

最初にネイティブのプロジェクト/目標を取得し、担当者、状態、更新内容、リンク、日付、更新の新しさを確認します。リスク、進捗、または依存関係の証拠のみ詳細を取得します。

意思決定の準備状況/Go-No-Go

references/decision-readiness.md を読み込みます。まずネイティブのプロジェクトまたは意思決定のアンカーを解決し、明示的なリンクをスコープの境界として維持します。ゲートを特定してから、確信度、ギャップ、変更条件を添えて意思決定または推奨を示します。担当者を推測してはいけません。

トピックの状況

一度だけ解決/検索し、中心となるプロジェクト、目標、ページ、または作業項目のアンカーを選択してから、広範な作業/アクティビティのクエリを実行する前にそれらの情報を取得します。

参照資料

  • references/personal-work-summary.md - スタンドアップ、キャッチアップ、より広範な個人の状況を示す情報
  • references/decision-readiness.md - ドメイン横断の Go-No-Go と承認に関する情報
評価/パフォーマンスの情報

人物と対象期間を解決します。デリバリー、レビュー、コラボレーション、ドキュメント/戦略、プロジェクト/目標への影響、ステークホルダーからのシグナルを分けて評価します。件数だけで順位付けすることは避け、情報が不十分な場合はその旨を明記します。

出力形式

  • まずエグゼクティブサマリーを提示し、重要度の高い観察事項を3〜6件示します。
  • 担当者/チーム/ワークストリーム、肯定的なシグナルとリスクのシグナル、現在の重点事項、確信度、根拠を含む表を作成します。
  • リスクは影響度と担当者に基づいて順位付けします。
  • 確信度とギャップとして、更新情報の古さ、対象範囲の不足、ACL のギャップ、サンプリングの境界を示します。

アンチパターン

  • すべての成果物を列挙してはいけません。
  • イシューの件数だけから、目標/プロジェクトの健全性を推測してはいけません。
  • マネージャー/チーム単位のグループ化で質問に回答できる場合、組織のメンバーごとに問い合わせを広げてはいけません。
  • 状況やリスクの最終的な根拠として、検索結果のスニペットを使ってはいけません。
  • 明示的に統合された PR の集計は、ほかのツリーではなく pr-tree から始めます。

コメント