| description | コード修正が適切に行われたかを確認する。新規指摘は行わない(レビュー収束のため)。 |
| name | issue-verify-code |
Issue Verify Code
重要: このスキルは実装/修正を行ったセッションとは 別のセッション で実行することを推奨します。
同一セッションで実行すると、実装時のバイアスが確認判断に影響する可能性があります。
コード修正後の確認を行います。
重要: このコマンドは「指摘事項が適切に修正されたか」のみを確認します。
新規の指摘は行いません。これはレビューサイクルの収束を保証するためです。
いつ使うか
| タイミング | このスキルを使用 |
|---|
/issue-fix-code 後の修正確認 | ✅ 必須 |
| 新規レビューが必要な場合 | ❌ /issue-review-code を使用 |
ワークフロー内の位置: implement → review-code → (fix → verify) → i-dev-final-check → i-pr → close
入力
ハーネス経由(コンテキスト変数)
常に注入される変数:
| 変数 | 型 | 説明 |
|---|
issue_id | str | 正規化済み Issue ID(GitHub 数値または local ID) |
issue_ref | str | 人間可読の Issue 参照(GitHub では #<issue_id>、local では bare ID) |
step_id | str | 現在のステップ ID |
条件付きで注入される変数:
| 変数 | 型 | 条件 | 説明 |
|---|
cycle_count | int | サイクル内ステップのみ | 現在のイテレーション番号 |
max_iterations | int | サイクル内ステップのみ | サイクルの上限回数 |
手動実行(スラッシュコマンド)
$ARGUMENTS = <issue_id>
解決ルール
コンテキスト変数 issue_id が存在すればそちらを使用。
なければ $ARGUMENTS の第1引数を issue_id として使用。
issue_ref はハーネス経由ではプロンプトに自動注入される(ハーネス側で provider 別に整形)。手動実行時は issue_id から導出する: GitHub 数値 ID なら #<issue_id>、local-* 形式なら bare ID(# を付けない)。
前提知識の読み込み
以下のドキュメントを Read ツールで読み込んでから作業を開始すること。
- 変更種別と必須ゲート:
docs/dev/change-types-and-gates.md
- テスト規約:
docs/dev/testing-convention.md
- Python コーディング規約:
docs/reference/python-standards.md
verify と review の違い
| 項目 | review | verify |
|---|
| 目的 | フルレビュー | 修正確認のみ |
| 新規指摘 | する | しない |
| 確認範囲 | コード全体 | 前回指摘箇所のみ |
| 使用タイミング | 実装完了後 | fix 後 |
共通ルール
実行手順
Step 1: コンテキスト取得
-
_shared/worktree-resolve.md の手順に従い、Worktree の絶対パスを取得。
-
前回の指摘内容を取得:
uv run kaji issue view [issue_id] --comments
「コードレビュー結果」と「レビュー指摘への対応報告」を確認。
-
Baseline Check コメントの確認:
Issue コメントから最新の ## Baseline Check 結果 を検索する。複数存在する場合は 最新のコメントを正 とする
(commit hash で識別)。存在する場合、テスト実行時の regression 判定に使用する(判定ロジックは
issue-review-code Step 1.5 と同一。特に pytest は && チェーンに含めず個別実行 する点に注意)。
-
修正差分を確認:
cd [worktree_dir] && git diff HEAD~1
Step 2: 修正確認
2.1 修正項目の確認
確認すること:
- 前回の「指摘事項 (Must Fix)」が適切に修正されているか
- 修正によるデグレードがないか
2.2 反論(見送り項目)の検討
「見送り」または「議論」とされた項目について、以下の観点で徹底的に検討する:
-
反論の論理的妥当性
- 根拠が明確か?(「〜だから」が説明されているか)
- 論理に飛躍や矛盾がないか?
-
技術的妥当性
- コードベースの一貫性を損なわないか?
- 将来の保守性に問題はないか?
-
トレードオフの評価
- 指摘を受け入れた場合のコスト/リスクは妥当か?
- 代替案は検討されているか?
-
判定
- 受け入れる: 反論に納得できる → 指摘を取り下げ
- 再反論する: 反論に問題がある → 理由を明記して再度修正を求める
- 一部受け入れ: 部分的に納得 → 妥協点を提示
重要: 反論を無視してはならない。必ず検討結果と理由を回答すること。
2.3 新規発見事項の記録(任意)
確認作業中に前回指摘以外の問題を発見した場合:
- 判定には含めない(verify の収束保証のため)
- 報告は行う(情報損失を防ぐため)
- 推奨対応を添える(放置されないように)
Step 3: 確認結果のコメント
uv run kaji issue comment [issue_id] --commit --body-file - <<'EOF'
| 指摘項目 | 状態 | 理由・根拠 |
|----------|------|------------|
| (項目1) | ✅ OK | (なぜ OK と判断したか:修正内容が指摘意図を満たしている等) |
| (項目2) | ❌ 要再修正 | (なぜ NG か:修正が不十分、意図と異なる等の具体的理由) |
| 見送り項目 | 検討結果 | 理由 |
|------------|----------|------|
| (項目A) | ✅ 受け入れ | (なぜ反論を受け入れるか:技術的に妥当、トレードオフが許容範囲等) |
| (項目B) | ❌ 再修正を求める | (なぜ受け入れないか:根拠が不十分、一貫性を損なう等) |
| (項目C) | ⚠️ 一部受け入れ | (妥協点:〜については受け入れるが、〜は対応が必要) |
> **注意**: 以下は今回の判定には影響しません。verify の対象は前回指摘事項のみです。
| 発見事項 | 重要度 | 推奨対応 |
|----------|--------|----------|
| (問題の概要) | 高/中/低 | 別 Issue 起票 / 次フェーズで対応 / 将来検討 |
- **高(ブロッカー級)**: 現 Issue のスコープに含めるか検討。含める場合は `/issue-review-code` からやり直し
- **中(改善推奨)**: 別 Issue を起票して追跡
- **低(軽微/好み)**: 記録のみ。対応は任意
[ ] Approve (i-dev-final-check へ進む)
[ ] Changes Requested (再修正が必要)
(Approve の場合)
`/i-dev-final-check [issue_id]` で最終チェックを実施してください。
(Changes Requested の場合)
`/issue-fix-code [issue_id]` で再度修正してください。
EOF
Step 4: 完了報告
## コード修正確認完了
| 項目 | 値 |
|------|-----|
| Issue | [issue_ref] |
| 判定 | Approve / Changes Requested |
### 次のステップ
- Approve: `/i-dev-final-check [issue_id]` で最終チェック
- Changes Requested: `/issue-fix-code [issue_id]` で再修正
Verdict 出力
実行完了後、以下の形式で verdict を出力すること:
---VERDICT---
status: PASS
reason: |
修正が適切に行われている
evidence: |
全 Must Fix 項目の修正を確認
suggestion: |
---END_VERDICT---
重要: verdict は stdout にそのまま出力 すること。Issue コメントや Issue 本文更新とは別に、最終的な verdict ブロックは stdout に残す。
status の選択基準
| status | 条件 |
|---|
| PASS | Approve |
| RETRY | 修正不十分 |
| ABORT | 重大な問題 |