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-verify |
重要: このスキルは修正を行ったセッションとは 別のセッション で実行することを推奨します。 同一セッションで実行すると、修正時のバイアスが確認判断に影響する可能性があります。
PR レビュー修正後の確認を行う。
重要: このスキルは「指摘事項が適切に修正されたか」のみを確認する。 新規の指摘は行わない。これはレビューサイクルの収束を保証するためである。
| タイミング | このスキルを使用 |
|---|---|
/pr-fix 後の修正確認 | ✅ 必須 |
| 新規レビューが必要な場合 | ❌ PR 上で直接レビューを実施 |
provider.type='github' 配下 | ✅ 受理（gh CLI 経由） |
provider.type='local' 配下 | ❌ Step 0 で ABORT。代替は /issue-verify-code |
ワークフロー内の位置: i-pr → [PR review] → (pr-fix → pr-verify) → close
$ARGUMENTS = <issue_id>
| 変数 | 型 | 説明 |
|---|---|---|
issue_id | str | 正規化済み Issue ID（GitHub 数値、または local-*） |
issue_ref | str | 人間可読の Issue 参照 |
provider_type | str | github / local のいずれか。Step 0 のガード判定に使用 |
コンテキスト変数 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| 項目 | 新規レビュー | verify |
|---|---|---|
| 目的 | フルレビュー | 修正確認のみ |
| 新規指摘 | する | しない |
| 確認範囲 | コード全体 | 前回指摘箇所のみ |
| 使用タイミング | 初回レビュー | pr-fix 後 |
本 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-verify 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-verify-code instead.
---END_VERDICT---
PROVIDER_TYPE がそれ以外（空文字 / 不明値）→ 以下の ABORT verdict を
出力して終了:
---VERDICT---
status: ABORT
reason: |
pr-verify 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 '.[] | {path: .path, line: .line, body: .body, user: .user.login}'
「レビュー指摘への対応報告」コメントを確認する。
修正差分の確認:
cd [worktree_dir] && git log --oneline -5
cd [worktree_dir] && git diff HEAD~1
確認すること:
「見送り」または「反論」とされた項目について、以下の観点で 徹底的に検討 する:
反論の論理的妥当性
技術的妥当性
トレードオフの評価
判定
重要: 反論を無視してはならない。必ず検討結果と理由を回答すること。
確認作業中に前回指摘以外の問題を発見した場合:
cd [worktree_dir] && source .venv/bin/activate && make check
判定結果に応じて、GitHub の正式なレビュー状態を更新する。
kaji pr review [pr_id] --approve --body-file - <<'EOF'
## PR レビュー修正確認結果
### 修正項目の確認
| 指摘項目 | 状態 | 理由・根拠 |
|----------|------|------------|
| (項目1) | ✅ OK | (なぜ OK と判断したか) |
### 反論への検討結果
| 見送り項目 | 検討結果 | 理由 |
|------------|----------|------|
| (項目A) | ✅ 受け入れ | (なぜ反論を受け入れるか) |
### 新規発見事項（参考情報）
> **注意**: 以下は今回の判定には影響しません。verify の対象は前回指摘事項のみです。
| 発見事項 | 重要度 | 推奨対応 |
|----------|--------|----------|
| (問題の概要) | 高/中/低 | 別 Issue 起票 / 次フェーズ / 将来検討 |
### 品質チェック
- `make check`: PASS
EOF
kaji pr review [pr_id] --request-changes --body-file - <<'EOF'
## PR レビュー修正確認結果
### 修正項目の確認
| 指摘項目 | 状態 | 理由・根拠 |
|----------|------|------------|
| (項目1) | ✅ OK | (なぜ OK と判断したか) |
| (項目2) | ❌ 要再修正 | (なぜ NG か) |
### 反論への検討結果
| 見送り項目 | 検討結果 | 理由 |
|------------|----------|------|
| (項目B) | ❌ 再修正を求める | (なぜ受け入れないか) |
| (項目C) | ⚠️ 一部受け入れ | (妥協点) |
### 品質チェック
- `make check`: PASS / FAIL
EOF
以下の形式で報告すること。
## PR レビュー修正確認完了
| 項目 | 値 |
|------|-----|
| PR | [pr_ref] |
| Issue | [issue_ref] |
| 判定 | Approve / Changes Requested |
### 次のステップ
- Approve: `/issue-close [issue_id]` で PR マージ & クリーンアップ
- Changes Requested: `/pr-fix [issue_id]` で再修正
実行完了後、以下の形式で verdict を出力すること。
---VERDICT---
status: PASS
reason: |
修正が適切に行われている
evidence: |
全指摘事項の修正を確認、make check 通過
suggestion: |
---END_VERDICT---
重要: verdict は stdout にそのまま出力 すること。
| status | 条件 |
|---|---|
| PASS | Approve |
| RETRY | 修正不十分 |
| 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 に記録する。