github-project-triage

GitHub プロジェクトのトリアージ

ユーザーが triage と入力した場合、リクエストが明示的に GitHub 以外のドメインを対象としていない限り、必ずこのスキルを使ってください。リポジトリ内から実行する場合は、デフォルトで現在の GitHub プロジェクトを使ってください。トリアージとは、メンテナー向けの項目カードを作成することです。項目カードには、URL、各 issue／PR の概要、重要な理由、作成者の信頼性、適合性、リスク、証拠／テスト状況、ブロッカー、次のアクションを記載します。キュー番号や内容の分からない参照だけを返してはいけません。

出力は URL を先頭にします。取り上げる issue／PR／リポジトリの各項目には、その項目の最初の行または最初の文に GitHub URL を含めてください。候補を絞って提示する場合は、項目ごとに URL を 1 つ記載してください。

関連するオーナー／組織をまたいだ広範なキューの検索では、最初の確認にのみ RepoBar を使ってください。RepoBar は手作業で gh repo list を繰り返すより高速で、プロフィールを考慮した検索ができるうえ、リポジトリのアクティビティ、issue 数、PR 数、ローカルプロジェクト、認証、キャッシュ、フィルターにすでに対応しています。

セットアップ

インストール済みの場合は、実際の repobar バイナリを優先してください。このワークスペースでは、~/Projects/RepoBar にある SwiftPM のプロダクトとしてしか存在しない場合があります。

repobar_cmd() {
  if command -v repobar >/dev/null 2>&1; then
    repobar "$@"
  elif [ -x "$HOME/Projects/RepoBar/.build/debug/repobarcli" ]; then
    "$HOME/Projects/RepoBar/.build/debug/repobarcli" "$@"
  else
    swift run --package-path "$HOME/Projects/RepoBar" repobarcli "$@"
  fi
}

repobar_cmd status --json

広範なトリアージでのデフォルトのオーナーは steipete と openclaw です。広範な／デフォルトのキューをトリアージする場合は、件数順で最初のリポジトリでなくても、openclaw/openclaw の詳細確認を含めてください。これは ClawdBot／OpenClaw の主要なキューです。ユーザーが指定した場合、現在のリポジトリがそのオーナー配下にある場合、またはタスクで全件を明示的に求められた場合を除き、amantus-ai やその他のオーナーは含めないでください。特定のオーナーを対象とするタスクでは、指定されたオーナーの範囲を広げないでください。

ローカルリポジトリの確認

ローカルプロジェクト内で作業を始める前に、チェックアウトの準備ができていることを確認してください。

git status --short --branch
git branch --show-current
git pull --ff-only
git status --short --branch

ブランチが main であり、プルが成功し、ワークツリーがクリーンな場合にのみ進めてください。ブランチが main でない場合、プルに失敗した場合、または git status --short で変更が表示された場合は、作業を中止して Peter にどうするか確認してください。明示的な指示なしに、ブランチの切り替え、スタッシュ、コミット、リセット、復元、クリーンアップを行ってはいけません。

スコープのルール

ユーザーが triage と言い、現在の作業ディレクトリが Git リポジトリで GitHub のリモートが設定されている場合は、そのプロジェクトのみをトリアージしてください。ユーザーが broad、all、everything と言うか、複数のオーナー／組織を指定するか、複数リポジトリにまたがるトリアージを依頼しない限り、Peter／組織全体のキューに範囲を広げないでください。

リポジトリに VISION.md がある場合は、自律的に対応できる内容を判断する前に読んでください。製品との適合性を判断する際の信頼できる情報源として使い、そのうえでこのスキルのリスク／テスト可能性のルールを適用してください。VISION.md がない場合は、以下の自律対応適合性ルールを使ってください。

現在のプロジェクトを特定してください。

repo=$(gh repo view --json nameWithOwner --jq .nameWithOwner 2>/dev/null || true)
if [ -z "$repo" ]; then
  url=$(git remote get-url origin 2>/dev/null || true)
  repo=$(printf '%s\n' "$url" |
    sed -E 's#^[email protected]:##; s#^https://github.com/##; s#\\.git$##')
fi
printf '%s\n' "$repo"

現在のプロジェクトのトリアージは、次の確認から始めてください。

gh issue list --repo "$repo" --state open --limit 50 \
  --json number,title,author,labels,createdAt,updatedAt,url
gh pr list --repo "$repo" --state open --limit 50 \
  --json number,title,author,isDraft,reviewDecision,mergeStateStatus,createdAt,updatedAt,url

issue や PR に対応する前に、すべてのコメントを読み、Peter／オーナーのコメントを正式な対応指示として扱ってください。Peter が、よさそう、変更が必要、後続のもので置き換えられている、製品として承認済み、または不要だと述べている場合は、その指示をボットのラベルや通常のトリアージ判断より優先してください。Peter／オーナーのコメントがない場合は、メンテナーとして判断し、その判断が自分によるものであることを明記してください。

取り上げるすべての項目について説明できるよう、十分な詳細を確認してください。キューが小さい場合（オープン項目が約 10 件以下）は、すべての項目を確認してください。キューが大きい場合は、優先度の高い項目を中心に確認し、詳細を確認しなかった項目を明記してください。

gh issue view <n> --repo "$repo" \
  --json number,title,author,body,comments,labels,createdAt,updatedAt,url
gh pr view <n> --repo "$repo" \
  --json number,title,author,body,comments,files,commits,isDraft,reviewDecision,mergeStateStatus,statusCheckRollup,createdAt,updatedAt,url
gh pr diff <n> --repo "$repo" --patch

十分な証拠がある場合にのみ、コメント、クローズ、マージ、再実行、またはパッチ適用を行ってください。

トリアージ結果

ユーザーが triage と言った場合は、常に現在のリポジトリのオープン中のイシューとオープン中の PR をすべて確認してください。次の項目を返してください。

• 自律対応候補：追加のプロダクト判断なしで修正またはマージできそうな項目。URL、該当する理由、必要な検証、確信度を含めてください。これはレビュー用の選定であり、ユーザーが自律的な実行も依頼しない限り、作業開始の許可ではありません。
• Peter の判断が必要：Peter／オーナーの判断、プロダクトの方向性、不足している認証情報／アクセス、取得できない実際のプロバイダーでの証明、セキュリティ／プライバシー上の判断、または変更を求める Peter の正式なコメントが障害となっている項目。
• 延期／クローズ／統合：古い、重複している、品質が低い、または内容が重複しており、新たなコードを追加しない対応が妥当と思われる項目。

自律対応候補となり得る項目はすべて、利用できる場合は高い推論能力を持つサブエージェント、oracle、または独立したエージェントレビューを使い、提示前に実現可能性を確認してください。サブエージェントには、そのタスクに関係する証拠だけを渡し、自律的に完了できるか、必要な検証は何か、安全でない可能性がある要因は何かを尋ねてください。サブエージェントを利用できない場合は、同等の深さで自ら確認し、その旨を伝えてください。

自律作業モード

ユーザーが do work autonomously、work you can do autonomously、keep going などと言った場合は、キューの概要やローカルでのパッチを 1 件作成しただけで停止しないでください。安全に自律対応できる項目がなくなるまで、各項目が証拠を添えてマージ／クローズ／延期されるまで、または Peter の判断が必要なブロッカーに直面するまで、対象となるイシュー／PR のキューを順に処理する許可とみなしてください。

複数のチケットを同時に作業してはいけません。各項目について、次の手順に従ってください。

1. イシュー／PR、関連コード、ドキュメント、CI、存在する場合は VISION.md を確認してください。情報が古い可能性がある場合や不明確な場合は、Google を利用するか、公式ドキュメントを参照してください。
2. 自律対応が可能か判断してください。
   • 実施可：複雑さが過度に増さないパフォーマンス改善、再現手順／根本原因と検証方法が明確なバグ修正、小規模な UI／UX 調整、ドキュメント修正、範囲を絞ったテスト／内部修正、CI が正常に通る低リスクな依存関係／CI の整理。
   • 先に確認：新機能、プロダクト／ビジョンに関する判断、広範な動作変更、リスクの高い依存関係、確かな証拠のないセキュリティ上重要な変更、利用可能な認証情報のない実プロバイダー関連の作業、エンドツーエンドでテストできないこと。
   • リファクタリングの方針：自律対応可能な項目に対して、適切な解決策が範囲を絞ったきれいなリファクタリングである場合はそれを選んでください。設計を悪化させたままにする場合に、「小さなパッチ」を既定の選択肢にしないでください。
3. 最も保守しやすい方法で実装するか、PR を修正してください。書き込み可能であればコントリビューターの PR を更新し、できない場合はクレジットを明記してローカルで再作成してください。
4. 可能な限り、ローカルおよび実環境でエンドツーエンドの検証を行ってください。UI の動作については、Peekaboo、browser-use、スクリーンショット、VM による証明など、リポジトリで想定されている実 UI 検証方法を使ってください。API／プロバイダーの動作については、利用可能であれば、想定されているシークレットのワークフローを使い、実際に使えるキー／アカウントで確認してください。アクセスが不足している場合は、項目が完了したかのように扱わず、作業を止めて Peter に支援を依頼してください。
5. コミット／マージ前に Codex Auto Review を実行してください。ただし、軽微な変更／ドキュメントのみの変更、または明示的に省略する場合は除きます。対応可能で妥当な指摘は修正してください。
6. CI が正常に通ること、PR の説明／変更履歴が適切であることを確認し、証拠を添えてマージ／クローズ／コメントを行ってください。その後 main に戻り、pull --ff-only を実行し、次の自律対応候補を選ぶ前に作業ツリーがクリーンであることを確認してください。
7. マージした PR ごとに、テスト方法を正確に記載したコメントを PR に投稿してください。ローカルコマンド、実環境／UI／API での検証証拠、CI の実行／チェック状態、マージ済みコミット、注意点を含めてください。検証画像がある場合は、利用可能であれば gh image を使ってアップロード／投稿してください。アップローダーを利用できない場合は、その旨を記し、画像を黙って省略せずにスクリーンショットのパス、または代替となる GitHub 添付の証拠を含めてください。

ブロッカーがない限り、自律作業モードを未コミットのファイルや、プッシュされていないローカル修正を残して終えてはいけません。ブロッカーがある場合は、具体的なブロッカー、現在のブランチ／状態、収集済みの証拠、次に必要な判断を明示してください。

自律作業の範囲にも制限があります。既定では現在のリポジトリを対象とします。広範なキュー、全キュー、またはすべての項目を対象とするのは、ユーザーが広範な対象／全件／すべてを依頼した場合、またはオーナー／組織を指定した場合に限ります。

信頼性のシグナル

推奨するメンテナー以外の項目について、対応する前に投稿者／PR作成者の信頼性を必ず確認してください。リスクの低い Dependabot／内部項目では、簡潔なボット／内部向けの信頼性に関する記載で十分です。

同梱のヘルパーを優先してください。

skills/github-project-triage/scripts/github-activity.sh --repo <owner/repo> --global <login>

このスキルのチェックアウトにヘルパーがない場合は、次を代わりに使用してください。

~/Projects/clawdbot/.agents/skills/openclaw-pr-maintainer/scripts/github-activity.sh --repo <owner/repo> --global <login>

PR でより深い信頼性の判断が必要な場合、特に OpenClaw、セキュリティに関わる変更、範囲の広い PR、新しいアカウント、または投稿者の通常と異なる行動については、github-author-context も使用してください。まず既存のコントリビューターに関するメモを確認してください。

~/Projects/maintainers/scripts/clawtributors find github <login>

信頼性に関する出力は、事実に基づくものにしてください。

Trust: @login; acct 2021-04-03; repo 2 PRs/1 issue/0 commits in 12mo; GitHub 9 PRs/3 issues/12 reviews; signal: known contributor / new drive-by / bot / unknown.

信頼性を証明と見なさないでください。信頼性によって変わるのはレビューの深さであり、正しさではありません。

項目の評価

各項目を分類してください。

• bug：可能な限り、再現手順／ログ／失敗するテスト／現在の main ブランチでの証拠を求めてください。修正やマージを推奨する前に、根本原因を特定してください。
• feature：エンドツーエンドのテスト計画を求めてください。実環境での検証にプロバイダーキー、アカウント、デバイス、サービス、モデルへのアクセス、または有料 API が必要な場合、作業完了と見なす前に、具体的にどの認証情報／アクセスが不足しているかを明記してください。
• dependency：パッケージのグループ、メジャー／マイナー更新のリスク、失敗しているチェック、ランタイム／エンジンの変更、分割すべきかどうかを説明してください。
• security：優先度を上げ、コードパスの慎重な検証、テスト、信頼性／背景情報の確認を求めてください。根拠の説明だけでマージしないでください。
• docs/internal：リスクは低めですが、ユーザーに見える関連性と、古くなった内容／生成物の変更によるリスクを説明してください。

次の項目を評価してください。

• Fit：good / mixed / poor のいずれかと、その理由を1つ。
• Risk：影響範囲とともに、low / medium / high のいずれか。
• Proof：現在の CI、ローカルでの再現、失敗するテスト、実環境での E2E、または証拠の不足。
• Blocker：初回コントリビューターによる CI 承認、失敗しているチェック、不足しているキー、不明確な製品方針、古いブランチ、信頼性に懸念のある／範囲の広い差分、再現手順なし、競合。
• Next：CI を承認する、テストを実行する、再現手順を求める、PR を分割する、ローカルでパッチを適用する、チェックが通った後にマージする、証拠を添えてクローズする、または保留する。

優先順位付け用のキューマップ

対象範囲が広い場合にのみ使用してください。まずリポジトリ単位のキューマップを確認します。これにより、オープンな Issue や PR があるリポジトリと、その件数を把握できます。

PR キュー。主なトリアージ順：

repobar_cmd repos \
  --scope all \
  --only-with work \
  --owner steipete \
  --owner openclaw \
  --sort prs \
  --json

Issue の対応状況。Issue が重要な場合の第2段階：

repobar_cmd repos \
  --scope all \
  --only-with work \
  --owner steipete \
  --owner openclaw \
  --sort issues \
  --json

--forks と --archived は、ユーザーが「すべて」「全部」と指定した場合、または過去の経緯の調査を依頼した場合にのみ使用してください。通常のトリアージでは、キューが特に関連する場合を除き、フォークとアーカイブ済みリポジトリは除外してください。

簡潔なターミナル表示には、次を使用してください。

repobar_cmd repos --scope all --only-with work --owner steipete --owner openclaw --sort prs --plain

便利な jq の集計：

repobar_cmd repos --scope all --only-with work --owner steipete --owner openclaw --sort prs --json |
  jq -r '.[] | [.fullName, .openIssues, .openPulls, .activityTitle, .activityActor] | @tsv'

PR 件数順のキューを要約する場合は、RepoBar の PR 件数順を維持してください。同じオーナーの範囲内で、PR 件数の多いリポジトリを省いて、より少ないリポジトリを含めないでください。たとえば、オープンな PR がある Issue ゼロのリポジトリ（openclaw/crabbox など）も、トリアージの対象です。

詳細確認

広範なキューマップを作成した後は、ユーザーが網羅的な詳細を明示的に求めない限り、上位のリポジトリのみを確認してください。

repobar_cmd issues <owner/name> --limit 50 --json
repobar_cmd pulls <owner/name> --limit 50 --json
repobar_cmd ci <owner/name> --limit 20 --json
repobar_cmd activity <owner/name> --limit 20 --json

マージ可能または疑わしい PR については、メンテナー向けの状態確認に gh を使用してください。

gh pr view <n> --repo <owner/name> --json number,title,state,author,isDraft,mergeStateStatus,reviewDecision,statusCheckRollup,updatedAt,url
gh pr diff <n> --repo <owner/name> --patch
gh run list --repo <owner/name> --branch <branch> --limit 10

すでに修正済みの可能性がある Issue については、コメントやクローズを行う前に gh issue view に切り替え、現在のソースを確認してください。

OpenClaw／ClawdBot のキューでは、必要に応じて OpenClaw メンテナー向けの確認手順を使用してください。

• 利用できる場合は、gitcrawl で重複するスレッドや関連スレッドを検索します。
• 投稿者／作者の識別には、アクティビティヘルパーを使用します。
• ユーザーがメンテナー所有の作業を求めている場合を除き、主要メンテナーによるノイズは除外します。
• 明確な証拠がある、外部からのバグ報告や PR を優先します。

ローカルでの相互確認

タスクでローカルプロジェクトの状態、変更のあるリポジトリ、または「ここで自分が担当しているのは何か」に触れている場合は、これを使用してください。

repobar_cmd local --root "$HOME/Projects" --depth 1 --limit 200 --plain
repobar_cmd local --root "$HOME/Projects" --depth 1 --sync --limit 200 --json

ユーザーが明示的に求めない限り、破壊的なローカル操作（local reset、ブランチの削除、チェックアウトの移動）は実行しないでください。

トリアージの指針

優先する対象：

• CI が成功している、またはほぼ成功している PR、メンテナーが最近活動しているリポジトリ、あるいはリスクの低い依存関係／ドキュメント／テストの変更。
• 未オープンの PR が多くても最近活動があるリポジトリ。明らかな整理が必要な箇所が見つかることが多いためです。
• 再現可能な問題、最近報告された問題、またはリリースを妨げる問題。
• セキュリティ、リリース、認証、インストール、CI、データ消失に関する報告を、見た目の問題より優先します。
• 現在の main で明確に再現でき、担当者への経路が明確なバグ。
• ライブ検証が可能な場合、またはアクセスできないことが明示されている場合に限り、機能追加を優先します。

優先度を下げる対象：

• ユーザーから依頼がない限り、アーカイブ済みのリポジトリ。
• Peter が積極的にメンテナンスしていない限り、フォークにしかないキュー。
• 再現手順も担当者の手がかりもない、古くて範囲の広い機能要望。
• ローカルの状態が明らかになるまで、リモートが見つからない、または削除可能なリポジトリ。
• エンドツーエンドの検証に、利用できない API キーやアカウントが必要な機能／プロバイダー関連の PR。
• 明確なユーザーの課題、テスト計画、信頼できる作成者の手がかりがない、広範な生成変更。

出力形式

現在のプロジェクトのトリアージでは、次の形式で回答してください：

Repo: owner/name
Source: gh list/view/diff/checks, local source/tests where inspected

Immediate:
- #123 PR: title
  What: one-line summary in plain words.
  Type/Fit/Risk: bug|feature|dependency; good|mixed|poor; low|medium|high because ...
  Trust: @login; acct date; repo/global activity; known/unknown/bot.
  Proof: CI/repro/test/e2e state.
  Blocker: none / missing key / first-time CI approval / failing lint / unclear direction.
  Next: exact maintainer action.

Needs judgment:
- #124 issue: ...

Defer/close:
- #125 issue: ...

Skipped:
- <why>

広範囲を調査する場合は、次の形式で回答してください：

Owners scanned: steipete, openclaw
Source: RepoBar <command summary>, plus gh for selected PRs/issues

Top queues:
- owner/repo: X issues, Y PRs; why it matters; next action

Immediate actions:
- <small obvious merge/fix/comment/rerun, with item summary>

Needs judgment:
- <larger/ambiguous queues, with item summary>

Skipped:
- archived/forks/missing access/etc.

ユーザーが対応を求めた場合は、そのまま作業を続けてください。選定した PR／issue を gh で調査し、CI を再実行または修正し、根拠がある場合に限りコメント、クローズ、マージを行い、実行したコマンドと確認できた証拠を正確に報告してください。