القائمة
コード修正が適切に行われたかを確認する。新規指摘は行わない（レビュー収束のため）。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
dev workflow 向けの最終チェック。PR 前に品質ゲート、docs 整合、設計書昇格、Issue 更新をまとめて確認する。
docs-only workflow 向けの最終チェック。docs 整合と Issue 状態を確認し、PR に進めるか判定する。
docs review の指摘に対応し、ドキュメントのみを修正する。コードやテストは変更しない。
docs-only の変更をレビューし、事実整合性・実装整合性・運用整合性の観点から判定する。
docs-only の更新を行う。コードやテストは変更せず、現行実装・CLI・運用方針との整合を確認しながら docs を修正する。
docs review の指摘が適切に修正されたかを確認する。新規指摘は行わない。
| description | コード修正が適切に行われたかを確認する。新規指摘は行わない（レビュー収束のため）。 |
| name | 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.mddocs/dev/testing-convention.mddocs/reference/python-standards.md| 項目 | review | verify |
|---|---|---|
| 目的 | フルレビュー | 修正確認のみ |
| 新規指摘 | する | しない |
| 確認範囲 | コード全体 | 前回指摘箇所のみ |
| 使用タイミング | 実装完了後 | fix 後 |
_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
確認すること:
「見送り」または「議論」とされた項目について、以下の観点で徹底的に検討する：
反論の論理的妥当性
技術的妥当性
トレードオフの評価
判定
重要: 反論を無視してはならない。必ず検討結果と理由を回答すること。
確認作業中に前回指摘以外の問題を発見した場合：
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
## コード修正確認完了
| 項目 | 値 |
|------|-----|
| Issue | [issue_ref] |
| 判定 | Approve / Changes Requested |
### 次のステップ
- Approve: `/i-dev-final-check [issue_id]` で最終チェック
- Changes Requested: `/issue-fix-code [issue_id]` で再修正
実行完了後、以下の形式で verdict を出力すること:
---VERDICT--- status: PASS reason: | 修正が適切に行われている evidence: | 全 Must Fix 項目の修正を確認 suggestion: | ---END_VERDICT---
重要: verdict は stdout にそのまま出力 すること。Issue コメントや Issue 本文更新とは別に、最終的な verdict ブロックは stdout に残す。
| status | 条件 |
|---|---|
| PASS | Approve |
| RETRY | 修正不十分 |
| ABORT | 重大な問題 |