Skip to content
Back to skills

Pr Fix

ASecurity

PR 上のレビューコメントに基づきコード修正・コミット・レビュー返信を行う。

  • 15 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 1, 2026
ai-agentspythonshellbashtestinggit

Works with

  • cli

Security analysis

A100/100

Scanned October 1, 2026

npx -y skills add apokamo/kaji --skill pr-fix --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Pr Fix?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Pr Fix
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/apokamo-pr-fix/badge)](https://www.skillsdirectory.com/skills/apokamo-pr-fix)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
description: PR 上のレビューコメントに基づきコード修正・コミット・レビュー返信を行う。
name: pr-fix
---

# PR Fix

PR 上のコードレビューコメントに基づき、修正対応を行う。
指摘を盲目的に受け入れるのではなく、技術的な妥当性を検討し、修正と反論を使い分ける。

## いつ使うか

| タイミング | このスキルを使用 |
|-----------|-----------------|
| PR にレビューコメント(Changes Requested 等)が付いた後 | ✅ 必須 |
| PR 作成前(Issue ワークフロー内のレビュー) | ❌ `/issue-fix-code` を使用 |
| `provider.type='github'` 配下 | ✅ 受理(gh CLI 経由) |
| `provider.type='local'` 配下 | ❌ Step 0 で ABORT。代替は `/issue-review-code` 等 |

**ワークフロー内の位置**: i-pr → [PR review] → (**pr-fix** → pr-verify) → close

## 引数

```
$ARGUMENTS = <issue_id>
```

- Issue 番号を受け付ける(関連 PR を自動解決する)

### コンテキスト変数

| 変数 | 型 | 説明 |
|------|-----|------|
| `issue_id` | str | 正規化済み Issue ID(GitHub 数値、または `local-*`) |
| `issue_ref` | str | 人間可読の Issue 参照(GitHub では `#<issue_id>`、local では bare ID) |
| `provider_type` | str | `github` / `local` のいずれか。Step 0 のガード判定に使用 |
| `git_remote` | str | git remote 名(`provider.<type>.git_remote` config から解決。未指定時のフォールバックは `kaji_harness/config.py` 定義)。Step 4 の `git push` 引数に使用 |

### 解決ルール

コンテキスト変数 `issue_id` が存在すればそちらを使用。
なければ `$ARGUMENTS` の第1引数を `issue_id` として使用。

`issue_ref` はハーネス経由ではプロンプトに自動注入される(`prompt.py` 側で provider 別に整形)。手動実行時は `issue_id` から導出する: GitHub 数値 ID なら `#<issue_id>`、`local-*` 形式なら bare ID(`#` を付けない)。

`pr_id` / `pr_ref` はハーネス経由ではプロンプトに自動注入される(`runner.py` の `_resolve_pr_context_safe` が `GitHubProvider.resolve_pr_context()` 経由でブランチから PR を逆引きして展開する)。手動実行時、および auto-resolve が失敗した(branch 未 push / PR 未作成)場合は Step 1 で fallback として `kaji pr list --head` から取得する。`pr_ref` は `gh:<pr_id>` 形式で組み立てる(`kaji_harness/providers/models.py` `PRContext` 準拠)。

## 前提知識の読み込み

変更対象に応じて、以下のドキュメントを Read ツールで読み込んでから作業を開始すること。

1. **テスト規約**: `docs/dev/testing-convention.md`
2. **コーディング規約**: `docs/reference/python/python-style.md`(型ヒント、docstring 等)
3. **エラーハンドリング**: `docs/reference/python/error-handling.md`

## 共通ルール

- [_shared/report-unrelated-issues.md](../_shared/report-unrelated-issues.md) — 作業中に発見した無関係な問題の報告ルール

## 実行手順

### Step 0: provider check

本 Skill は forge provider 専用。最初に `provider_type` を解決し、
`github` 以外なら **以降のステップに進まず ABORT verdict を出力して終了** する。

**手順**:

1. **`provider_type` の解決**(ハーネス注入 → 手動 fallback の優先順):

   ```bash
   PROVIDER_TYPE="${provider_type:-$(kaji config provider-type 2>/dev/null || true)}"
   ```

   `|| true` は手動実行で `[provider]` 不在時に `kaji config provider-type` が
   exit 2 を返しても shell 全体を落とさないため。空文字に縮退する。

2. **判定と verdict 出力**:

   - `PROVIDER_TYPE` が `github` → Step 1 に進む
   - `PROVIDER_TYPE` が `local` → 以下の ABORT verdict を **そのまま stdout に
     出力**して以降のステップは実行しない:

     ```text
     ---VERDICT---
     status: ABORT
     reason: |
       pr-fix is forge-only and cannot run under provider.type='local'.
     evidence: |
       Pull request concept does not exist in local mode (bare provider).
     suggestion: |
       Use /issue-review-code, /issue-fix-code, /issue-verify-code instead.
     ---END_VERDICT---
     ```

   - `PROVIDER_TYPE` がそれ以外(空文字 / 不明値)→ 以下の ABORT verdict を
     出力して終了:

     ```text
     ---VERDICT---
     status: ABORT
     reason: |
       pr-fix could not resolve provider_type.
     evidence: |
       provider_type was not injected and `kaji config provider-type` failed
       (likely missing `[provider]` section in .kaji/config.toml).
     suggestion: |
       Add `[provider]` to .kaji/config.toml. See docs/cli-guides/local-mode.md.
     ---END_VERDICT---
     ```

> **重要**: ABORT verdict は **shell の `exit` に任せず agent 自身が stdout に
> 出力する**こと。workflow runner はその verdict を読み取って `on: ABORT: end`
> で workflow を終わらせる。

### Step 1: コンテキスト取得

1. **PR の特定**:
   `pr_id` / `pr_ref` はハーネス注入時にプロンプトへ展開済み(`{{pr_id}}` / `{{pr_ref}}`)。手動実行、または auto-resolve が失敗した場合のみ fallback として Issue 本文の `> **Branch**:` 行からブランチ名を取得し:

   ```bash
   PR_JSON=$(kaji pr list --head "[branch_name]" --json number,title --jq '.[0]')
   pr_id=$(echo "$PR_JSON" | jq -r '.number')
   pr_ref="gh:${pr_id}"
   ```

2. **Worktree パスの解決**:
   [_shared/worktree-resolve.md](../_shared/worktree-resolve.md) の手順に従い、Worktree の絶対パスを取得。

3. **レビューコメントの取得**:

   ```bash
   kaji pr view [pr_id] --comments
   kaji pr reviews [pr_id] --jq '.[] | {user: .user.login, state: .state, body: .body}'
   kaji pr review-comments [pr_id] --jq '.[] | {id: .id, path: .path, line: .line, body: .body, user: .user.login}'
   ```

   **注意**: inline comment の `id` を控えておく。Step 5 で thread 返信に使用する。

4. **現状把握**:
   指摘されている該当コード周辺を確認する。

### Step 2: 対応方針の検討

各指摘事項について **1つずつ** 検討する。

- **A: 対応する (Agree)**
  - 指摘が正しく、修正により品質・安全性が向上する場合
  - **改善提案の場合**: メリットが明確なら採用。大規模リファクタや高リスクなら見送り可

- **B: 対応しない/反論する (Disagree/Discuss)**
  - 指摘が誤解に基づいている場合
  - 修正による副作用やコストがメリットを上回る場合
  - AGENTS.md / CLAUDE.md の方針や既存の設計思想と矛盾する場合
  - **必須**: 反論する場合は明確な論理的根拠を用意する

### Step 3: 修正の実行

1. **コード修正**:
   採用した指摘事項に基づきコードを修正する。

2. **品質チェック(コミット前必須)**:

   ```bash
   cd [worktree_dir] && source .venv/bin/activate && make check
   ```

   **すべてパスするまでコミットしてはならない**。

### Step 4: コミット & プッシュ

```bash
cd [worktree_dir] && git add . && git commit -m "fix: address PR review feedback for [issue_ref]"
cd [worktree_dir] && git push [git_remote]
```

### Step 5: PR にレビュー返信

#### 5.1 インラインコメントへの thread 返信

Step 1 で取得した各 inline review comment に対し、thread 内で返信する。

```bash
kaji pr reply-to-comment [pr_id] --to [comment_id] --body "(対応内容または反論の要約)"
```

- **対応済みの指摘**: 修正内容を簡潔に説明し、コミットハッシュを添える
- **見送り/反論**: 理由と論理的根拠を明記する

#### 5.2 全体サマリーの投稿

top-level PR コメントとして全体サマリーを投稿する:

```bash
kaji pr comment [pr_id] --body-file - <<'EOF'
## レビュー指摘への対応報告

### 対応済み

- **(指摘内容の要約)**
  - 修正内容: (どう修正したか)

### 見送り・反論

- **(指摘内容の要約)**
  - 理由: (なぜ対応しなかったか。根拠となるロジック)

### 品質チェック

- `make check`: PASS

### 次のステップ

`/pr-verify [issue_id]` で修正確認をお願いします。
EOF
```

### Step 6: 完了報告

以下の形式で報告すること。

```
## PR レビュー対応完了

| 項目 | 値 |
|------|-----|
| PR | [pr_ref] |
| Issue | [issue_ref] |
| 対応済み | N 件 |
| 見送り | M 件 |

### 次のステップ

`/pr-verify [issue_id]` で修正確認を実施してください。
```

## Verdict 出力

実行完了後、以下の形式で verdict を出力すること。

```
---VERDICT---
status: PASS
reason: |
  修正完了
evidence: |
  全指摘事項に対応済み、make check 通過
suggestion: |
---END_VERDICT---
```

**重要**: verdict は **stdout にそのまま出力** すること。

### status の選択基準

| status | 条件 |
|--------|------|
| PASS | 修正完了 |
| ABORT | 修正不可能 / Step 0 で provider mismatch |

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…