このスキルは、「PR を監視して」「PR をウォッチして」「PR を見張って」「watch PR」「monitor PR」「PR の監視を開始」「レビューと CI を自動修正して」「PR を自動で直して」「PR を自動修正して」などとリクエストした時に使用する。PR のレビューコメントと CI 失敗を 2 分間隔で定期監視し、自動で修正・コミット・プッシュ・返信を行う。pr-fix と pr-ci の機能を統合し、ユーザー確認なしに自律実行する。最大 30 分間監視する (活動検出時は最大 120 分)。
PR のレビューコメントと CI 失敗を定期監視し、検出次第自動で修正・コミット・プッシュ・返信を実行する。
japanese-text-style スキルに従う| パラメータ |
|---|
| 値 |
|---|
| 監視間隔 | 2 分 |
| アイドル上限 | 30 分 (レビュー/CI 失敗が一度も検出されなかった場合に終了) |
| 絶対上限 | 120 分 (HAD_ACTIVITY に関わらず強制終了) |
| 即時終了条件 | コンフリクト検出、PR クローズ/マージ済み |
| 修正発生時 | START_TIME をリセットせず引き続き監視を継続 |
監視ループ全体で以下の状態を管理する:
PR_NUMBER: PR 番号OWNER, REPO: リポジトリ情報MY_LOGIN: 自分の GitHub ユーザー名 (gh api user --jq '.login' で取得、自分のコメントを除外するため)START_TIME: 監視開始時刻 (UNIX タイムスタンプ)HAD_ACTIVITY: false (レビュー/CI 失敗を一度でも検出したら true にし、以降リセットしない)UNFIXABLE_RUNS: 修正不可能と判断した CI run ID のリスト (以降のサイクルで同じ失敗の再処理をスキップする)CYCLE_COUNT: 実行サイクル数REVIEW_COMMITS: レビュー修正コミット数CI_COMMITS: CI 修正コミット数REPLIED_COMMENTS: 返信済みコメント数RESOLVED_THREADS: resolve 済みスレッド数PR_UPDATES: PR タイトル・description の更新回数必須: 作業開始前に update_plan で残存タスクを確認し、存在する場合は全て update_plan で削除する。その後、update_planで以下のタスクを登録する:
`update_plan`
`update_plan`
`update_plan`
各ステップの開始時に update_plan で in_progress にし、完了時に completed に更新する。
引数で PR 番号が指定されていない場合、現在のブランチから PR を特定する:
gh pr view --json number,title,headRefName,state --jq '{number, title, headRefName, state}'
MERGED または CLOSED の場合は監視を開始せず終了する状態変数を初期化する。初期化時に MY_LOGIN=$(gh api user --jq '.login') で自分の GitHub ユーザー名を取得し、監視ループ全体で保持する。
以下のサイクルを繰り返す。各サイクルの先頭で経過時間を確認する:
HAD_ACTIVITY が false → 監視を終了するgh pr view <number> --json state,mergeable --jq '{state, mergeable}'
state が MERGED / CLOSED → 監視終了mergeable が CONFLICTING → ユーザーに通知して監視終了# <owner>, <repo>, <number> は実際の値に置き換える
gh api graphql -F query='
query {
repository(owner: "<owner>", name: "<repo>") {
pullRequest(number: <number>) {
reviewThreads(first: 100) {
nodes {
id
isResolved
comments(first: 10) {
nodes {
databaseId
body
path
line
author { login }
}
}
}
}
}
}
}'
フィルタ条件:
取得した reviewThreads.nodes に対して以下の条件でフィルタする:
isResolved == false のスレッドのみを対象とするcomments.nodes[0].author.login) が MY_LOGIN (ステップ 1 で取得済み) と一致するスレッドは除外する (自分によるコメントには返信・resolve しない)除外後に未解決コメントがあれば HAD_ACTIVITY = true にする。
HEAD_SHA=$(gh pr view <number> --json headRefOid --jq '.headRefOid')
gh run list --commit "$HEAD_SHA" --json databaseId,status,conclusion,name --limit 50
conclusion が failure の run があれば HAD_ACTIVITY = true にするstatus が in_progress の run がある場合、このサイクルでは CI 修正をスキップする (CI 結果が確定するのを待つ)UNFIXABLE_RUNS に含まれる run ID はスキップする妥当性判断の基準:
| 指摘の種類 | 判断 | 対応 |
|---|---|---|
| コードの正確性に関する指摘 | 修正が必要 | コードを修正 |
| セキュリティに関する指摘 | 修正が必要 | コードを修正 |
| パフォーマンスに関する指摘 | 修正が必要 | コードを修正 |
スタイルや好みの問題 (nits:) | 内容次第 | コードを修正または、理由を返信して resolve |
| 誤解に基づく指摘 | 対応不要 | 説明を返信して resolve |
| 既に別のコミットで対応済みの指摘 | 対応不要 | 対応済みの旨を返信して resolve |
ファクトチェック (必須):
レビューの指摘を鵜呑みにせず、技術的な主張や根拠が正しいか検証する。特に以下のケースでは必ずファクトチェックを行う:
ファクトチェックのソース優先順位:
| 優先度 | ソース | 用途 |
|---|---|---|
| 1 | LSP | コードベース内の定義・参照・型情報の確認 |
| 2 | deepwiki MCP | OSS リポジトリの Wiki・ドキュメント |
| 3 | Gemini MCP | Google 検索による最新情報の取得 |
| 4 | context7 MCP | ライブラリの公式ドキュメントとコード例 |
| 5 | 必要時のみ WebFetch | 公式サイト・GitHub・特定 URL の確認 |
| 6 | 必要時のみ WebSearch | 最新情報・ブログ・リリースノートの検索 |
例外 (上記の優先順位より優先):
mcp__terraform__*) が最優先mcp__google-developer-knowledge__*) が最優先ファクトチェックの結果、指摘が誤りだった場合はその根拠をソース付きで返信コメントに記載する。
処理フロー:
各未解決コメントの妥当性を上記基準で判断し、ファクトチェックで検証する
修正が必要なコメントに対してコードを修正する
修正したファイルをステージングする: git add <修正ファイル>
コミットメッセージを自前で生成する:
git diff --cached で変更差分を確認するGlob で commitlint.config.* と .commitlintrc* を探し、見つからなければ Read で package.json の commitlint キーを確認するcommitlint.config.* → .commitlintrc* → package.json の順で優先し、最も具体的な設定を採用するRead で開き、type-enum、scope-enum、scope-empty、subject-case、header-max-length、extends を抽出するextends が相対パスならそのファイルもたどる。@commitlint/config-conventional / @commitlint/config-angular は既知 preset として扱うfeat, fix, docs, style, refactor, perf, test, chore, build, ci, revert をデフォルト候補にするgit log -5 --oneline で既存コミットの言語とスタイルを確認する推奨メッセージでコミットする
# <type>, <scope>, <subject>, <body> は上で生成した内容に置き換える
git commit -m "$(cat <<'EOF'
<type>(<scope>): <subject>
<body>
EOF
)"
git push でリモートに反映する
各コメントに返信・リアクション・resolve を実行する:
# 元のコメントに +1 リアクション (databaseId 使用)
gh api repos/{owner}/{repo}/pulls/comments/<databaseId>/reactions -f content="+1"
# スレッドに返信 (GraphQL mutation、thread id 使用)
# <thread_id>, <body> は実際の値に置き換える
gh api graphql -F query='
mutation {
addPullRequestReviewThreadReply(input: {pullRequestReviewThreadId: "<thread_id>", body: "<body>"}) {
comment { id body }
}
}'
# スレッドを resolve
# <thread_id> は実際の値に置き換える
gh api graphql -F query='
mutation {
resolveReviewThread(input: {threadId: "<thread_id>"}) {
thread { isResolved }
}
}'
処理順序: リアクション追加 → 返信投稿 → resolve。エラーが発生しても続行し、失敗を記録する。
返信テンプレート:
| 対応タイプ | 返信例 |
|---|---|
| 修正完了 | 修正しました。ご指摘ありがとうございます。 |
| 対応しない | [理由] のため、現状のままとさせてください。 |
| 対応済み | [コミット hash] で対応済みです。 |
ソース参照ルール:
理由を添えて返信する場合 (対応しない、内容次第で対応不要と判断した場合など)、信頼できるソースの情報を参照できるときはコメントにも記載する。
例:
Go の仕様上、nil map への読み取りはゼロ値を返すためパニックしません。