mcpField
W
woocommerce-stale-pr-audit

woocommerce-stale-pr-audit

github.com/woocommerceテスト・品質1645 回インストール9 週間前に更新
リポジトリ

woocommerce-stale-pr-audit について

WooCommerce の非アクティブなプルリクエストを対象に、メンテナーが範囲を定めて行う読み取り専用監査スキルです。対象収集、現行 trunk との比較、代表的なユーザーテスト、推奨事項とチェックリストの作成を案内し、分析と要承認の変更を分離します。

主な機能

  1. 01非アクティブ PR の対象固定
  2. 02現行 trunk との変更比較
  3. 03代表的なユーザーテストの案内
  4. 04PR ごとの監査記録の検証
  5. 05チェックリスト報告の作成

活用シーン

  1. 01古い PR を閉じるか維持するかの判断
  2. 02現行 trunk に照らした変更案の確認
  3. 03メンテナー向け判断チェックリストの準備

インストール

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

$npx skills add https://github.com/woocommerce/agent-skills --skill woocommerce-stale-pr-audit

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

同梱ファイル

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

references/
audit-schema.md
workflow.md
scripts/
collect_cohort.py
fetch_live_state.mjs
fetch_review_dismissals.mjs
validate_audit.py

詳細

WooCommerce の滞留 PR 監査

使用するタイミング

メンテナーが、非アクティブなプルリクエストの対象群を定めてレビューし、各 PR をクローズするか、オープンのままにするか、担当者の判断を仰ぐか決める場合に、このスキルを使用します。対象群の収集、現在のトランクとの比較、代表的なユーザーテスト、対応の推奨、およびチェックリスト形式のレポートを扱います。

監査は読み取り専用で実施してください。クローズ、コメント、ラベル付け、担当者の割り当て、プッシュ、マージは別個の操作であり、明示的な許可が必要です。

必要な入力

開始前に、以下を収集してください。

  • owner/name 形式の GitHub リポジトリ。
  • 正の整数で表した非アクティブ期間のしきい値(例:60 日または 90 日)。ユーザーが指定しない場合に限り、90 日を使用します。
  • カットオフの計算に使用する正確な基準日時。
  • デフォルトブランチと正式なリモート。
  • 必要な出力先と、非公開での公開が想定されているかどうか。
  • 利用可能なローカルテストツールと、安全な環境の実行可能容量。

cutoff = asOf - inactivityDays を計算し、対象群の条件を明示してください。同梱のコレクターは、updatedAt < cutoff のオープン PR を使用します。

手順

  1. references/workflow.md を最初から最後まで読んでください。 エビデンスの収集、現在のトランクとの比較、実行時テストの規則、並列作業の範囲、チェックリストの保存、公開、および変更の境界を定義しています。

  2. 記録を作成する前に references/audit-schema.md を読んでください。 そのフィールド仕様、列挙値、統合時の不変条件を、作業者間で変更せずに使用してください。

  3. git status --short --branch でチェックアウトを確認してください。無関係な作業は保持し、ブランチの調査とテストには分離したワークツリーを使用してください。

  4. 現在のデフォルトブランチをフェッチし、その完全なコミット SHA を記録してください。

  5. 対象群を固定します。

    python3 scripts/collect_cohort.py \
      --repo woocommerce/woocommerce \
      --inactive-days 60 \
      --as-of 2026-08-25T00:00:00Z \
      --output work/cohort-raw.json
    

    inactivityDays、asOf、cutoffExclusive、順序付き PR 番号、および取得時点のトランクメタデータを保持してください。PR が後から変更されても、対象群の構成を書き換えないでください。

  6. 各 PR について、意図された成果を特定し、関連する Issue と議論を確認し、変更内容を現在のトランクおよび履歴と正確に比較し、互換性リスクを評価し、リポジトリの最新のラベルを使って Bug と Enhancement に分類してください。オープンのままにする場合は、現在のレビュー担当者または担当チームも特定してください。

  7. 挙動を実行できる場合は、代表的なユーザーフローを実施してください。セットアップ、正確なコードの状態、フィクスチャ、ユーザーの手順、期待結果と観測結果、アサーション、後処理、およびクリーンアップの確認結果を記録してください。CI、ユニットテスト、ソースコードの確認、またはビルド成功を「ユーザーテスト」と呼ばないでください。

  8. 固定した対象群の各 PR につき、監査記録を 1 件作成してください。検証します。

    python3 scripts/validate_audit.py \
      --cohort work/cohort-raw.json \
      --audit work/audit.json \
      --labels work/repository-labels.json
    
  9. 報告の直前に、最新の状態をフェッチしてください。

    node scripts/fetch_live_state.mjs \
      --repo woocommerce/woocommerce \
      --cohort work/cohort-raw.json \
      --output work/cohort-live-state.json
    
  10. 承認が失われたことに関する観察が重要な場合は、正式な却下イベントをフェッチしてください。

    node scripts/fetch_review_dismissals.mjs \
      --repo woocommerce/woocommerce \
      --cohort work/cohort-raw.json \
      --output work/review-dismissals.json
    
  11. 非公開のチェックリストレポートを作成してください。初回の監査推奨、GitHub の最新状態、ユーザーが処理した状態は、それぞれ別の層として保持してください。成果物を更新する際は、処理済み状態の選択内容とユーザーによる編集を保持してください。

検証

  • 対象件数、順序付き番号、しきい値、基準日時、およびカットオフに矛盾がないこと。

  • 対象群のすべての PR が監査に一度ずつ含まれ、余分な PR が含まれていないこと。

  • 現在のトランクに関する結論が、フェッチ済みの SHA と具体的なエビデンスを参照していること。

  • 実行可能なテストすべてについて、テストしたコードの状態が明示され、クリーンアップが確認されていること。

  • 提案するラベルがリポジトリの最新のラベル一覧に存在し、まだ付与されていないこと。また、Bug と Enhancement のどちらかが明示されていること。

  • オープン継続および担当者判断待ちの記録に、理由とともにレビュー担当者またはチームが記載されていること。

  • 推奨、関連性、優先度、複雑さ、確信度の各合計が、それぞれ固定した対象群の件数と一致すること。

  • 同梱されている 4 つのコピーすべてが正常にビルドされること。

    node shared/scripts/skillpack-build.mjs --clean \
      --targets=codex,vscode,claude,cursor \
      --skills=woocommerce-stale-pr-audit
    

障害パターン/デバッグ

  • 監査中にコホートが変更された場合: 元のメンバー構成を保持し、変更は最終的な現状にのみ記録します。
  • GitHub 接続でさらにデータがあると報告された場合: ページネーションするか、証拠が不完全であると記録します。first: 100 を完全なデータとして黙って扱ってはいけません。
  • 古いブランチが動作しない場合: 現在の trunk を対照としてテストし、必要に応じて一時的なクリーンマージまたは最小限の移植を行います。古いブランチと、未解決のユーザーニーズを区別します。
  • 代表的なフローが存在しない場合: フローまたはサブシステムが削除されたことを示す証拠がある場合に限り、not-runnable-obsolete を使用します。古くなっているだけでは証拠になりません。
  • 人によるレビュー後に件数が変わった場合: 履歴を上書きせず、初期と最終の件数をタイムスタンプとともに示します。
  • 公開を検証できない場合: 成果物をローカルに保存し、アクセスまたはレンダリング上の問題を報告します。

エスカレーション

ソースと議論を確認した後も、締め切りルール、リポジトリの範囲、関連する issue の有効性、互換性への影響、製品の所有者、または許容されるテストの代替手段が不明確な場合は、メンテナーに確認してください。外部への変更を行う前、またはローカル環境の並行処理数を既知の安全な上限を超えて増やす前にも、確認してください。

コメント