twg-engineering-work

twg-engineering-work

ルート twg とともに使用します。ドキュメントに記載されたコマンド形式に従い、不明または確信のないコマンド、引数、出力仕様についてのみ、対象を絞って twg help を実行します。

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

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

使用する場面

• 「自分のレビュー待ちの PR はどれですか？」
• 「この API はどこで実装、または使用されていますか？」
• 「このパッケージに依存しているリポジトリはどれですか？」
• 「この課題に関する最新の PR」
• 「このリポジトリ／トピックに最も貢献したのは誰ですか？」
• 「自分が PR を作成したリポジトリ」
• 「滞留しているレビュー」
• 「レビューの流れ、またはボトルネック」
• 「ユーザー、チーム、リポジトリの PR のみのステータス」、「この人の PR」、「今週の自分の PR」
• 「進行中の PR がある未解決のバグ／タスク」

最初に行うこと

エンジニアリングの基点を特定します。

• リポジトリ：URL、ローカルのチェックアウト、またはリポジトリの検索から、ワークスペースとリポジトリを特定します。
• PR：正確な PR の URL、ID、ワークスペース、リポジトリを特定します。
• 作業項目：Jira の作業項目を取得／参照し、関連する PR、コミット、ブランチ、リポジトリを確認します。
• トピック：一度解決／検索してから、関連するリポジトリ、PR、作業項目を見つけます。
• コード：パッケージ、API、シンボル、またはリポジトリを基点として特定し、references/code-search.md を読み込みます。

プロバイダー固有の PR コマンドは、そのホストに対してのみ使用します。Bitbucket のアクティビティ／コメント／タスクコマンドは、GitHub の PR には適用されません。

ルートの選択

• 名前を指定された場合、またはコードレビューで追加のコンテキストが求められた場合にのみ、../twg-code-review/SKILL.md を使用します。テスト時は通常のレビューを除外します。
• 課題から PR を検索する場合は、広範な PR テキスト検索より先に作業項目のコンテキストを使用します。
• リポジトリの貢献者や注目領域を調べる場合は、PR／コミット／ファイル領域の情報を、所有者情報とレビューの証拠と組み合わせます。
• PR のリーダーシップ／チーム／組織の集計には twg-status-rollups を使用します。このスキルでは PR の詳細を補足します。
• 個人／リポジトリのステータスでは、対象の人、リポジトリ、期間について、マージ済み／オープンの PR を収集します。
• コード：references/code-search.md を読み込みます。
• PR 以外の個人別サマリー（Jira、ドキュメント、会議、計画、通知）には、twg-status-rollups と ../twg-status-rollups/references/personal-work-summary.md を使用します。

PR セットをまとめて処理する

PR セットの情報は 1 回の呼び出しで取得し、PR ごとに呼び出してはいけません。

• レビュアー、承認、経過日数、マージ状態：1 回の pull-requests get <pr-url…> でセット全体を確認できます。クエリ結果の PR URL（url）を使用します。ARI では approved: null が返されます。
• 候補：bitbucket pull-requests query（作成者、レビュアー、状態、期間）または pull-requests query（ユーザー／組織）。
• pr-tree のレビュアー数は「レビュアーとして記載されている」人数であり、承認済みの人数ではありません。
• パイプライン：bitbucket pipeline query が一覧表示するのは最近の実行のみです（--limit のデフォルトは 15）。これを増やし、期間を網羅していると主張する前に、返されたタイムスタンプを確認します。ログの確認が必要な失敗に限り pipeline get を使用します。 commits／deployments は ARI ごとにまとめて処理します。
• 承認／コメントのタイムスタンプを確認する場合に限り、PR ごとに bitbucket pull-requests activity を実行します。PR が約 10 件を超える場合はサンプルを抽出し、その旨を明記します。--type を指定しないと、承認、更新、コメントのイベントがまとめて返されるため、イベント種別ごとに再度呼び出してはいけません。

証拠に関する方針

• 滞留、ブロック、中心的、または影響の大きい PR に限り、PR のコメント、タスク、パイプラインのステータス、差分を取得します。
• PR の集計では、テーマ、リポジトリ／サービス、担当者、最近の動向が特定できた時点で終了します。同じテーマの PR を追加しても新たな情報は得られません。
• レビュー状況には、経過日数、レビュー依頼先、コメント／タスク、承認状態、CI／パイプラインの状態、確認できる場合は最終アクティビティを含めます。
• リポジトリ／チームのレポートは、個人別の件数ではなく、リポジトリ、サービス、または作業ストリームごとにまとめます。
• テーマは PR の件数ではなく、タイトル、説明、関連する課題から推定します。
• Bitbucket、GitHub、Atlassian の認証エラーは、それぞれ別に扱います。
• PR グラフまたはリポジトリ全体のクエリが繰り返し失敗する場合は、既知のリポジトリ、人、作業項目、検索基点から対象を絞ったフォールバックを 1 回実行します。その後、成功した情報をもとに回答し、PR の網羅性に不足があることを明記します。

レシピカード

レビューキュー

レビュアー別のオープン PR を検索し、待機時間、依頼されたアクション、未解決のタスク／コメント、失敗した CI、関連性の順に並べ替えます。対応が必要な PR のみ詳細を取得します。

滞留レビュー／レビューのボトルネック

しきい値を超えてオープン状態または待機中の PR を見つけ、リポジトリ、作成者、レビュアー、段階ごとにグループ化します。ボトルネックのパターン：レビュアーが未指定、未解決のタスク、失敗した CI、「変更を要求」の繰り返し、担当者が対応できない状態。

Issue に関連する PR

リンクされた PR、コミット、ブランチ、リポジトリについては、作業項目のコンテキストを使用します。ユーザーが詳細、ステータス、または次のアクションを求めた場合にのみ、PR を取得します。

リポジトリのコントリビューター／注目領域

リポジトリと期間を指定して PR／コミットを検索し、ファイル／領域、作成者、レビュアー、テーマごとにグループ化します。注目領域は、変更された領域、頻度、担当状況を基準に順位付けします。

PR ベースのステータス集計

まず組織／チームを特定し、次に期間内のメンバーまたはリポジトリの PR を収集します。テーマとリポジトリ／サービスごとにグループ化し、PR のみの根拠では Jira、ドキュメント、計画、顧客のコンテキストが抜け落ちる箇所を明示します。より広範な内容について一人の状況を尋ねられた場合は、twg-status-rollups を使用します。

出力形式

キュー：PR、リポジトリ、担当者、状態、理由、次のアクション、根拠。 レポート：ワークストリーム、コントリビューター、ボトルネック、リスク、抜け落ちている情報、安定したアーティファクト URL／ID。

アンチパターン

• Bitbucket のワークスペースやリポジトリを推測しないでください。
• バッチ処理やクエリの経路で一括対応できる場合に、PR ごと、またはパイプラインごとに単一エンティティのコマンドを呼び出さないでください。
• 大規模なキュー内のすべての PR について、本文、差分、コメントを取得しないでください。
• PR の件数を影響度として扱わないでください。
• Bitbucket、GitHub、Atlassian の認証エラーを混同しないでください。