github-pr-fix

Files (7)

• README.md
• README_ja.md
• SKILL.md
• openai.yaml · agents/
• summary_template.md · references/
• summary_template_ja.md · references/
• fetch_review_threads.sh · scripts/

SKILL.md (first lines)

# GitHub PR Fix

指定されたPRをmerge可能な状態へ戻すために、コンフリクト・CI失敗・未対応レビューコメントを検出し、該当するものだけを解消してPR head branchへ反映するSkill。
修正作業はPRごとの専用Git worktree内で行い、修正内容はPRの言語に合わせて生成し、ユーザーへの報告も同じ言語で行う。
**3つのサブSkillを正しい順序でオーケストレーションし、検出された問題に対応するSkillだけを呼び出す**。

- `git-fix-conflict`: コンフリクトの解消
- `github-fix-ci`: CI失敗の修正
- `github-resolve-pr-comment`: レビューコメントへの対応

修正・commit・pushは必ず専用worktree内で行う。Skillを起動した元の作業ツリーでは、PR情報の取得とworktree作成以外のファイル編集・commit・pushを行わない。

## Arguments

- `PR number` (Optional): 修正するPR番号。省略時は現在のブランチに紐づくPRを対象とする

## Task

### Phase 1: 事前チェック

1. 対象PRの特定:
   - 引数でPR番号が指定されている場合はそのPRを使用する
   - 引数が指定されていなければ、現在のブランチに紐づくPRを使用する
   - PRが存在しない場合はエラーメッセージを表示して中止
2. `owner/repo` を取得: `gh repo view --json owner,name --jq '"\(.owner.login)/\(.name)"'`
3. PRの `baseRefName` / `headRefName` / `headRepositoryOwner` / `isCrossRepository` を取得する
4. cross repository PRの場合は、現在の認証ユーザーがhead repositoryへpushできるかを確認する。pushできない場合は、修正内容を作れてもPRへ直接反映できないため中止して理由を報告する
5. push先 `<push-remote>` を決定する。PR head branchはhead repositoryにあるため、cross repository PRで `origin` (base repository) へpushしないこと:
   - 同一リポジトリのPR: `origin`
   - cross repository PR: head repositoryのURL。`origin` のURL形式に合わせて `https://github.com/<head-repository-owner>/<head-repo-name>.git` または `git@github.com:<head-repository-owner>/<head-repo-name>.git` を組み立てる
6. PRのタイトルと本文から言語を検出する (例: 日本語、英語)。曖昧な場合は英語をデフォルトとする。検出はここで1回だけ行い、すべての報告とサマリーをこの言語で記述し、Phase 4の引き継ぎ制約に含めてサブSkillへ渡す (サブSkillに独立して再検出させない)
7. 最終サマリー用テンプレートを検出された言語に応じて決定する:
   - English/default: [`references/summary_template.md`](references/summary_template.md)
   - Japanese: [`references/summary_template_ja.md`](references/summary_template_ja.md)

### Phase 2: 修正用worktreeの作成

1. `<repo-root>/.tmp/<repo-name>-worktrees/pr-<number>-fix` を専用worktree pathとする。
2. 同じpathのworktreeが存在し、未commit変更がある場合は中止する。cleanな場合のみ作り直してよい。
3. PR headとbase branchをfetchする: `git fetch origin +pull/<number>/head:refs/pr-fix/<number>/head` および `git fetch origin +<base-ref-name>:refs/pr-fix/<number>/base`
4. `git worktree add -B pr-fix/<number> <worktree-path> refs/pr-fix/<number>/head` で、`headRefName` ではなくfetch済みのrefから専用local branchを作ってcheckoutする。`headRefName` はPR head branch名としてpush先の判定に使う。checkout対象にはしない。fork PRや同名branchの衝突で別branchを修正しないよう、worktreeの `HEAD` が `refs/pr-fix/<number>/head` のcommit SHAと一致することを確認する。
5. Phase 3以降は、すべての操作を `<worktree-path>` 配下で実行する。

### Phase 3: 問題の検出

3種類の問題を並列に検出し、検出結果に応じてPhase 4で必要なSkillだけ呼び出す。
検出は `<worktree-path>` をcwdとし、PR番号を明示して実行する。

- **1. コンフリクト**: `mergeable` が `CONFLICTING` の場合のみ対応する。`MERGEABLE` / `UNKNOWN` はスキップする。
- **2. CI失敗**: `FAILURE` / `CANCELLED` / `TIMED_OUT` のcheckがある場合のみ対応する。全て実行中の場合はステータスを報告し、Phase 4のStep 2はスキップする。
- **3. 未対応レビューコメント**: inline review threadのunresolved数が1件以上の場合のみ対応する。unresolved数は [`scripts/fetch_review_threads.sh`](scripts/fetch_review_threads.sh) の `--only-unresolved` で取得し、review全体のstateだけでは判定しない (stateベースの判定はunresolved threadを取りこぼす)。

### Phase 4: 検出した問題への対応

検出された問題に対して、以下の順序でサブSkillを呼び出す。**前のステップが失敗しても後続のステップは試みる**。大きな変更の前にはユーザーに確認を求める。
各サブSkillは必ず `<worktree-path>` をcwdとして実行する。サブSkillへの引き継ぎには次の制約を明示する:

- PR番号: `<number>`
- 作業ディレクトリ: `<worktree-path>`
- 修正対象branch: `<head-ref-name>`
- base branch: `<base-ref-name>`
- 出力言語: Phase 1で検出した言語 (リプライ・commit message・報告に使用する)
- worktree外のファイルを編集しない
- commit / pushは `<worktree-path>` 内のPR head branchから行う
- push時は必ず `git push <push-remote> HEAD:<head-ref-name>` の形式でPR head branchへ明示的に反映すること (worktreeのlocal branch名は`pr-fix/<number>`でありPR head branch名と異なるため。`<push-remote>` はPhase 1で決定したもの)

#### Step 1: コンフリクトの解消

Phase 3でコンフリクト (`CONFLICTING`) が検出された場合のみ:

- `<worktree-path>` 内でSkill toolで `git-fix-conflict` を呼ぶ
- 完了を待ってから、再度 `gh pr view --json mergeable --jq '.mergeable'` でコンフリクトが解消されたことを確認する
- 検出された言語でステータスを報告する

#### Step 2: CI失敗の修正

Phase 3で失敗チェックが検出された場合のみ:

- `<worktree-path>` 内でSkill toolで `github-fix-ci` を呼ぶ
- 完了を待つ。プッシュ後にCIが再実行されることに注意する
- 検出された言語でステータスを報告する

#### Step 3: レビューコメントへの対応

Phase 3で未解決スレッドが検出された場合のみ:

- `<worktree-path>` 内でSkill toolで `github-resolve-pr-comment` を呼ぶ (同Skillにはレビューコメントへのリプライを常に投稿させる)
- 完了後、再度 [`scripts/fetch_review_threads.sh`](scripts/fetch_review_threads.sh) の `--only-unresolved` でunresolved数の差分を取って報告する
- 検出された言語でステータスを報告する

### Phase 5: 最終確認

1. `<worktree-path>` 内で未commit変更と直近のcommitを確認し、`gh pr view <number> --json url,mergeable,mergeStateStatus` と `gh pr checks <number>` でPRの最終状態を確認する
2. commit済みだが未pushの変更が残っている場合は、`<worktree-path>` 内から `git push <push-remote> HEAD:<head-ref-name>` でPR head branchへpushする
3. 未commit変更が残っている場合は、対象サブSkillの失敗として扱い、内容を検出された言語で報告する

### Phase 6: 最終サマリー

検出された問題に応じて、Phase 1で決定したテンプレートを使用して表示する。

### Phase 7: クリーンアップ

修正が完了した場合も、途中のエラーまたはユーザーの中止により中断した場合も行う:

1. Phase 2でfetchした一時refを削除する: `git update-ref -d refs/pr-fix/<number>/head` および `git update-ref -d refs/pr-fix/<number>/base`
2. `git worktree remove --force <worktree-path>`
3. `git branch -D pr-fix/<number>`
4. クリーンアップに失敗した場合は、失敗した項目をユーザーに警告する

From mjun0812/skills, MIT.

More from mjun0812/skills