Menü
PR 上のレビューコメントに基づきコード修正・コミット・レビュー返信を行う。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| description | PR 上のレビューコメントに基づきコード修正・コミット・レビュー返信を行う。 |
| name | 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_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 ツールで読み込んでから作業を開始すること。
docs/dev/testing-convention.mddocs/reference/python/python-style.md（型ヒント、docstring 等）docs/reference/python/error-handling.md本 Skill は forge provider 専用。最初に provider_type を解決し、
github 以外なら 以降のステップに進まず ABORT verdict を出力して終了 する。
手順:
provider_type の解決（ハーネス注入 → 手動 fallback の優先順）:
PROVIDER_TYPE="${provider_type:-$(kaji config provider-type 2>/dev/null || true)}"
|| true は手動実行で [provider] 不在時に kaji config provider-type が
exit 2 を返しても shell 全体を落とさないため。空文字に縮退する。
判定と verdict 出力:
PROVIDER_TYPE が github → Step 1 に進む
PROVIDER_TYPE が local → 以下の ABORT verdict を そのまま stdout に
出力して以降のステップは実行しない:
---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 を
出力して終了:
---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 を終わらせる。
PR の特定:
pr_id / pr_ref はハーネス注入時にプロンプトへ展開済み（{{pr_id}} / {{pr_ref}}）。手動実行、または auto-resolve が失敗した場合のみ fallback として Issue 本文の > **Branch**: 行からブランチ名を取得し:
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}"
Worktree パスの解決: _shared/worktree-resolve.md の手順に従い、Worktree の絶対パスを取得。
レビューコメントの取得:
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 返信に使用する。
現状把握: 指摘されている該当コード周辺を確認する。
各指摘事項について 1つずつ 検討する。
A: 対応する (Agree)
B: 対応しない/反論する (Disagree/Discuss)
コード修正: 採用した指摘事項に基づきコードを修正する。
品質チェック（コミット前必須）:
cd [worktree_dir] && source .venv/bin/activate && make check
すべてパスするまでコミットしてはならない。
cd [worktree_dir] && git add . && git commit -m "fix: address PR review feedback for [issue_ref]"
cd [worktree_dir] && git push [git_remote]
Step 1 で取得した各 inline review comment に対し、thread 内で返信する。
kaji pr reply-to-comment [pr_id] --to [comment_id] --body "(対応内容または反論の要約)"
top-level PR コメントとして全体サマリーを投稿する:
kaji pr comment [pr_id] --body-file - <<'EOF'
## レビュー指摘への対応報告
### 対応済み
- **(指摘内容の要約)**
- 修正内容: (どう修正したか)
### 見送り・反論
- **(指摘内容の要約)**
- 理由: (なぜ対応しなかったか。根拠となるロジック)
### 品質チェック
- `make check`: PASS
### 次のステップ
`/pr-verify [issue_id]` で修正確認をお願いします。
EOF
以下の形式で報告すること。
## PR レビュー対応完了
| 項目 | 値 |
|------|-----|
| PR | [pr_ref] |
| Issue | [issue_ref] |
| 対応済み | N 件 |
| 見送り | M 件 |
### 次のステップ
`/pr-verify [issue_id]` で修正確認を実施してください。
実行完了後、以下の形式で verdict を出力すること。
---VERDICT---
status: PASS
reason: |
修正完了
evidence: |
全指摘事項に対応済み、make check 通過
suggestion: |
---END_VERDICT---
重要: verdict は stdout にそのまま出力 すること。
| status | 条件 |
|---|---|
| PASS | 修正完了 |
| ABORT | 修正不可能 / Step 0 で provider mismatch |
設計書（draft/design/）に基づき、TDD（テスト駆動開発）アプローチを用いて機能を実装する。
実装完了後の成果物に対し、設計整合性とコード品質の観点から厳格なレビューを実施する
Issue 作成後・workflow 起動前に人間が明示起動する要件 interview。one-way door を含みうる重要な Issue で、未決の decision tree を 1 問ずつ推奨案付きで確認し、決定事項と provenance を Issue に固定するときだけ使用する。軽微な Issue や workflow 実行中には自動起動しない。
第2層のインシデント調査レビュー収束サイクルを 1 コマンドで手動起動する slash command wrapper。kaji run .kaji/wf/official/incident.yaml <incident_issue_id> を Bash 経由で起動し、exit code を verdict に縮約する。
Issue要件に基づき、draft/design/に設計書を作成する。worktree内での作業が前提。
ワークフローを手動実行して検証し、失敗時は継続せず原因を調査して Issue に記録する。成功時も気づきや詰まりどころを Issue に記録する。