---
name: my.pr-fix
description: |
  PR の CI 失敗やレビューコメントを取得・分析し、修正案を提案して実装するスキル。
  「PR を直して」「CI 落ちてる」「レビュー対応して」「PR の指摘を修正して」「チェックが失敗している」
  「PR #123 を見て」「この PR のコメント対応」「CI のエラーを修正」「レビューコメントに対応して」
  「husky が通らない」「pre-commit 失敗」「フック直して」「コミットできない」
  など、PR の修正・レビュー対応、CI 修正、ローカル Git フック修正に関する依頼があったときに積極的にこのスキルを使うこと。
  PR 番号を指定すればその PR、指定がなければ現在のブランチに紐づく PR を対象にする。
  PR がなければ WIP PR を自動作成して CI を走らせることもできる。
  ローカルの Husky フック失敗にも対応し、最大10回まで自動修正をリトライする。
compatibility: |
  - gh CLI (GitHub CLI) がインストール済みであること
  - gh auth login 済みであること
  - Bash ツールによるコマンド実行
  - コード修正のための Read / Edit ツール
---

# Overview

`my.pr-fix` は PR の CI チェック結果とレビューコメントを取得・分析し、問題点を特定して修正案を提案・実装するスキルです。CI ログからエラー原因を読み解き、レビューコメントの意図を解釈して、的確なコード修正を行います。ローカルの Husky フック失敗にも対応します。

## When to use

- CI が失敗している PR を修正したいとき
- レビューコメントの指摘に対応したいとき
- PR の状態を確認して、やるべき修正をまとめて片付けたいとき
- Husky の pre-commit / pre-push フックが失敗して修正したいとき
- まだ PR がないが、CI を走らせて確認したいとき

## Workflow

### 1. 対象 PR を特定する

| 条件                       | コマンド                                                                                           |
| -------------------------- | -------------------------------------------------------------------------------------------------- |
| PR 番号が指定されている    | `gh pr view <number> --json number,title,headRefName,state,statusCheckRollup,reviews,comments,url` |
| 指定なし（現在のブランチ） | `gh pr view --json number,title,headRefName,state,statusCheckRollup,reviews,comments,url`          |

PR が見つからない場合:

- ユーザーに「WIP PR を作成して CI を走らせますか？」と確認する
- 承認されたら `gh pr create --title "WIP: <branch>" --body "Work in progress" --draft` で作成
- 作成後、CI が走り始めるので結果を待ってステップ2に進む

マージ済み・クローズ済みの場合はその旨を伝える。

### 2. CI チェック状況を収集する

```bash
gh pr checks <number>
```

失敗しているチェックがある場合、GitHub Actions のログを取得する:

```bash
# 失敗した run を特定
gh run list --branch <branch> --status failure --limit 10 --json databaseId,name,conclusion,event

# 失敗した run のログを取得
gh run view <run-id> --log-failed
```

`--log-failed` は失敗したステップのログだけを返すので、全ログより効率的。ログが長い場合は末尾 200 行程度に絞って分析する。

### 3. レビューコメントを収集する

```bash
# PR のレビューコメント（コード行に紐づくもの）
gh api repos/{owner}/{repo}/pulls/<number>/comments --jq '.[] | {id, path, line, body, user: .user.login, created_at, in_reply_to_id}'

# PR の一般コメント（会話欄）
gh api repos/{owner}/{repo}/issues/<number>/comments --jq '.[] | {id, body, user: .user.login, created_at}'

# レビュー本体（approve / request changes / comment）
gh pr view <number> --json reviews --jq '.reviews[] | {author: .author.login, state: .state, body: .body}'
```

レビューコメントはスレッド構造（`in_reply_to_id`）を考慮して、既に解決済みの議論と未対応の指摘を区別する。

### 4. 問題を分析・分類する

収集した情報を以下のカテゴリに分類する:

#### CI 失敗の分類

| カテゴリ            | 例                        | 修正の方向性                                   |
| ------------------- | ------------------------- | ---------------------------------------------- |
| Lint / フォーマット | ESLint, Prettier, Rubocop | 自動修正コマンドを実行、または手動でコード修正 |
| 型チェック          | TypeScript, mypy          | 型定義の修正、型アノテーションの追加           |
| テスト失敗          | Jest, pytest, RSpec       | テストコードまたは実装コードの修正             |
| ビルドエラー        | コンパイル失敗、依存解決  | import 修正、依存追加、設定修正                |
| セキュリティ        | Dependabot, CodeQL        | 依存のアップデート、脆弱なコードの修正         |

#### レビューコメントの分類

| カテゴリ         | 例                                                     | 対応方法                         |
| ---------------- | ------------------------------------------------------ | -------------------------------- |
| コード修正の要求 | 「この変数名を変えて」「ここにバリデーション追加して」 | 指摘箇所のコードを修正           |
| 設計に関する質問 | 「なぜこのアプローチ？」「代替案は検討した？」         | 回答を提案（コメント用テキスト） |
| 追加実装の要求   | 「エラーハンドリングが足りない」「テスト追加して」     | 対象箇所にコードを追加           |
| 情報提供         | 参考リンク、ヒント、補足情報                           | 対応不要として報告               |

### 5. 修正案を提案する

分析結果をまとめて、修正案を提示する。

```text
## PR #<number>: <title>
URL: <pr-url>

### CI 失敗 (<N> 件)

#### 1. [カテゴリ] <チェック名>
- 原因: <エラーの根本原因>
- 修正案: <具体的な修正内容>
- 対象ファイル: <ファイルパス:行番号>
- 自信度: 高 / 中 / 低

### レビューコメント (<N> 件の未対応)

#### 1. @<reviewer> — <ファイルパス>:<行番号>
> <コメント内容の要約>
- 対応方針: <修正 / 回答 / 対応不要>
- 修正案: <具体的な変更内容>
- 自信度: 高 / 中 / 低

### 対応不要と判断したもの
- <理由付きで列挙>
```

自信度の基準:

- **高**: エラーメッセージから原因が明確、または指摘が具体的で対応が一意に決まる
- **中**: 複数の修正方法があり得る、またはコンテキストの理解に不確実性がある
- **低**: 設計判断が必要、または情報が不足している

### 6. ユーザー確認後に実装する

- 提案を見せた後、ユーザーの承認を待ってから実装に進む
- 自信度「低」の項目はユーザーに方針を確認してから着手する
- 自信度「高」でも、まとめて承認を得てから一括で実装する

実装時の手順:

1. 対象ファイルを Read で読む
2. Edit で修正を適用する
3. Lint / フォーマットの自動修正が使える場合は実行する（`npm run lint --fix`, `prettier --write` など）
4. 修正後に関連するテストがあれば実行して確認する

### 7. 結果を報告する

実装完了後、以下を報告する:

```text
## 修正完了

### 実施した修正
1. <修正内容> — <対象ファイル>
2. ...

### テスト結果
- <テスト実行結果があれば>

### 次のステップ
- [ ] 変更をコミットする
- [ ] CI の再実行を確認する
- [ ] レビュアーに re-review を依頼する
```

### 8. 分析レポートを保存する（任意）

CI 失敗の分析が複雑だった場合、結果を Markdown ファイルとして保存する。

- **出力先**: `paths.md` の `CI_ANALYSIS` を参照（定義がなければスキップ）
- レポートには PR 番号、失敗チェック、原因、修正内容を含める
- 保存先ディレクトリが存在しない場合は自動作成する

---

## Husky フック修正ワークフロー

ローカルの Husky フックが失敗している場合のフローです。

### 1. フック検出

1. `.husky/` ディレクトリの存在確認
2. フックファイルを検出・一覧表示（`pre-commit`, `pre-push`, `commit-msg` など）
3. 各フックの内容を確認

### 2. フック実行とリトライ修正（最大10回）

**ループ処理**:

1. フックを `bash .husky/<hook-name>` で実行
2. 成功 → 処理終了、結果報告
3. 失敗 → エラー分析
   - リンターエラー → `npm run lint -- --fix`, `rubocop -a` など
   - フォーマットエラー → `prettier --write` など
   - 型チェック → TypeScript エラーを手動修正
   - テスト失敗 → 自動修正可能な場合のみ対応
4. 修正を適用し、再度フックを実行（ステップ1に戻る）
5. 最大10回試行で成功しない → 中断して手動修正を促す

### 3. 結果報告

```text
## Husky フック修正結果

### 実行したフック: <hook-name>
- 試行回数: <N> 回
- 結果: 成功 / 失敗

### 実施した修正
1. <修正内容> — <対象ファイル>
2. ...

### 次のステップ
- [ ] 変更をステージングする
- [ ] コミットする
```

## Error handling

- `gh` が未インストール or 未認証の場合: インストール・認証手順を案内する
- PR が見つからない場合: WIP PR の作成を提案する
- CI ログが取得できない場合: 権限や GitHub Actions の設定を確認する
- レビューコメントが 0 件 + CI 全パスの場合: 「対応が必要な項目はありません」と報告する
- `.husky/` ディレクトリが存在しない場合: Husky の初期化方法を案内する
- フックファイルに実行権限がない場合: `chmod +x` を実行する
- 10回リトライしても修正できない場合: これまでの修正内容をまとめて報告し、手動修正を促す

## Tips

- CI ログが長大な場合は `--log-failed` で失敗ステップだけに絞る
- レビューコメントのスレッドで返信済みのものは「対応済みの可能性あり」として区別する
- lint / format 系は自動修正コマンドを先に試すと効率的
- 修正が多い場合はカテゴリごとにコミットを分けることを提案する