القائمة
レビュー指摘事項に対し、技術的妥当性を検討した上で修正対応（または反論）を行う
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| description | レビュー指摘事項に対し、技術的妥当性を検討した上で修正対応（または反論）を行う |
| name | issue-fix-code |
実装に対するレビュー指摘事項に基づき、修正対応を行います。 指摘を盲目的に受け入れるのではなく、技術的な妥当性を検討し、必要な修正と反論を使い分けます。
| タイミング | このスキルを使用 |
|---|---|
/issue-review-code で Changes Requested 後 | ✅ 必須 |
| 人間からのレビューコメントへの対応 | ✅ 使用可 |
ワークフロー内の位置: 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 |
条件付きで注入される変数:
| 変数 | 型 | 条件 | 説明 |
|---|---|---|---|
previous_verdict | str | resume または inject_verdict: true 指定ステップ | 前ステップの verdict |
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_shared/worktree-resolve.md の手順に従い、Worktree の絶対パスを取得。
レビュー結果の取得:
previous_verdict が存在する場合はそれを確認（ハーネス経由）レビュー内容の取得:
uv run kaji issue view [issue_id] --comments
最新の「コードレビュー結果」を取得。
現状把握: 指摘されている該当コード周辺を確認。
各指摘事項について、以下の基準で1つずつ検討してください。
A: 対応する (Agree)
B: 対応しない/反論する (Disagree/Discuss)
コード修正: 採用した指摘事項に基づきコードを修正
品質チェック（コミット前必須）:
以下を実行し、すべての基準をクリアするまでコミットしてはならない。失敗した場合は原因を修正して再実行すること。
AGENTS.md の pre-commit 契約（make check）と等価。baseline failure
判定のため pytest を && チェーンから切り離す必要がある。
cd [worktree_dir] && source .venv/bin/activate && make lint && make format && make typecheck
cd [worktree_dir] && source .venv/bin/activate && pytest
pytest は && チェーンに含めず、必ず個別に実行する。 合否判定は issue-implement Step 7b と
同一の基準（Baseline Check コメントの有無で分岐）を適用する。
cd [worktree_dir] && git add . && git commit -m "fix: address review feedback for [issue_ref]"
Issueにコメントします:
uv run kaji issue comment [issue_id] --commit --body "$(cat <<'EOF'
# レビュー指摘への対応報告
レビューありがとうございます。以下の通り検討・対応を行いました。
## 対応済み
- **(指摘内容の要約)**
- 修正内容: (どう修正したか、ファイル名など)
## 見送り・反論
- **(指摘内容の要約)**
- 理由: (なぜ対応しなかったか。根拠となるロジック)
## 品質チェック結果
(make lint + make format + make typecheck + pytest の出力をそのまま貼り付け)
## 次のステップ
`/issue-verify-code [issue_id]` で修正確認をお願いします。
EOF
)"
## コード修正完了
| 項目 | 値 |
|------|-----|
| Issue | [issue_ref] |
| 対応済み | N 件 |
| 見送り | M 件 |
### 次のステップ
`/issue-verify-code [issue_id]` で修正確認を実施してください。
実行完了後、以下の形式で verdict を出力すること:
---VERDICT--- status: PASS reason: | 修正完了 evidence: | 全指摘事項に対応済み suggestion: | ---END_VERDICT---
重要: verdict は stdout にそのまま出力 すること。Issue コメントや Issue 本文更新とは別に、最終的な verdict ブロックは stdout に残す。
| status | 条件 |
|---|---|
| PASS | 修正完了 |
| ABORT | 修正不可能 |
dev workflow 向けの最終チェック。PR 前に品質ゲート、docs 整合、設計書昇格、Issue 更新をまとめて確認する。
docs-only workflow 向けの最終チェック。docs 整合と Issue 状態を確認し、PR に進めるか判定する。
docs review の指摘に対応し、ドキュメントのみを修正する。コードやテストは変更しない。
docs-only の変更をレビューし、事実整合性・実装整合性・運用整合性の観点から判定する。
docs-only の更新を行う。コードやテストは変更せず、現行実装・CLI・運用方針との整合を確認しながら docs を修正する。
docs review の指摘が適切に修正されたかを確認する。新規指摘は行わない。