Issue Fix Code

---
description: レビュー指摘事項に対し、技術的妥当性を検討した上で修正対応（または反論）を行う
name: issue-fix-code
---

# 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` 指定ステップ | 前ステップの verdict |
| `cycle_count` | int | サイクル内ステップのみ | 現在のイテレーション番号 |
| `max_iterations` | int | サイクル内ステップのみ | サイクルの上限回数 |

### 手動実行（スラッシュコマンド）

```
$ARGUMENTS = <issue_id>
```

### 解決ルール

コンテキスト変数 `issue_id` が存在すればそちらを使用。
なければ `$ARGUMENTS` の第1引数を `issue_id` として使用。

`issue_ref` はハーネス経由ではプロンプトに自動注入される（`prompt.py` 側で provider 別に整形）。手動実行時は `issue_id` から導出する: GitHub 数値 ID なら `#<issue_id>`、`local-*` 形式なら bare ID（`#` を付けない）。

## 前提知識の読み込み

以下のドキュメントを Read ツールで読み込んでから作業を開始すること。

1. **開発ワークフロー**: `docs/dev/development_workflow.md`
2. **テスト規約**: `docs/dev/testing-convention.md`
3. **Python スタイル**: `docs/reference/python/python-style.md`（必要に応じて他の `docs/reference/python/*.md` も追加読込）

## 共通ルール

- [_shared/report-unrelated-issues.md](../_shared/report-unrelated-issues.md) — 作業中に発見した無関係な問題の報告ルール

## 実行手順

### Step 1: コンテキスト取得

1. [_shared/worktree-resolve.md](../_shared/worktree-resolve.md) の手順に従い、Worktree の絶対パスを取得。

2. **レビュー結果の取得**:
   1. コンテキスト変数 `previous_verdict` が存在する場合はそれを確認（ハーネス経由）
   2. 存在しない場合は Issue コメントから最新のレビュー結果を取得（手動実行時）

3. **レビュー内容の取得**:
   ```bash
   kaji issue view [issue_id] --comments
   ```
   最新の「コードレビュー結果」を取得。

4. **現状把握**:
   指摘されている該当コード周辺を確認。

### Step 2: 対応方針の検討

各指摘事項について、以下の基準で**1つずつ**検討してください。

- **A: 対応する (Agree)**
  - 指摘が正しく、修正により品質・安全性が向上する場合。
  - **改善提案 (Should Fix) の場合**:
    - メリットが明確な場合は積極的に採用
    - 大規模なリファクタリングを伴う場合や高リスクな場合は見送り可

- **B: 対応しない/反論する (Disagree/Discuss)**
  - 指摘が誤解に基づいている場合
  - 修正による副作用やコストがメリットを上回る場合
  - AGENTS.md / CLAUDE.md の方針や既存の設計思想と矛盾する場合
  - **必須**: 反論する場合は、明確な論理的根拠を用意

### Step 3: 修正の実行

1. **コード修正**:
   採用した指摘事項に基づきコードを修正

2. **品質チェック（コミット前必須）**:

   以下を実行し、**すべての基準をクリアするまでコミットしてはならない**。失敗した場合は原因を修正して再実行すること。
   AGENTS.md の pre-commit 契約（`make check`）と等価。artifact が `known_failures` の場合は
   pytest を deterministic `--compare` に置換して分離する。

   #### 3.1 Lint / Format / 型チェック（exit 0 必須）

   ```bash
   cd [worktree_dir] && source .venv/bin/activate && ruff check kaji_harness/ tests/ experiments/ && ruff format --check kaji_harness/ tests/ experiments/ && mypy kaji_harness/
   ```

   > `ruff format --check` は非破壊 gate（`make check` と等価）。整形差分で FAIL
   > した場合は `make fmt`（または `ruff format kaji_harness/ tests/`）で整形し、
   > 生じた差分をコミット対象に含めてから再チェックすること。

   #### 3.2 テスト実行

   ```bash
   cd [worktree_dir] && source .venv/bin/activate && python -m kaji_harness.scripts.baseline_precheck --worktree [worktree_dir] --compare
   ```

   合否判定は `issue-implement` Step 7b と同一とし、`verdict: ok`、regression 0 件を必須とする。
   artifact / stale 判定の正本は [docs/dev/baseline-check.md](../../../docs/dev/baseline-check.md)。

### Step 4: コミット

```bash
cd [worktree_dir] && git add . && git commit -m "fix: address review feedback for [issue_ref]"
```

### Step 5: 結果報告

Issueにコメントします:

```bash
kaji issue comment [issue_id] --commit --body "$(cat <<'EOF'
# レビュー指摘への対応報告

レビューありがとうございます。以下の通り検討・対応を行いました。

## 対応済み

- **(指摘内容の要約)**
  - 修正内容: (どう修正したか、ファイル名など)

## 見送り・反論

- **(指摘内容の要約)**
  - 理由: (なぜ対応しなかったか。根拠となるロジック)

## 品質チェック結果

```
(ruff check + ruff format --check + mypy + pytest の出力をそのまま貼り付け)
```

## 次のステップ

`/issue-verify-code [issue_id]` で修正確認をお願いします。
EOF
)"
```

### Step 6: 完了報告

```
## コード修正完了

| 項目 | 値 |
|------|-----|
| Issue | [issue_ref] |
| 対応済み | N 件 |
| 見送り | M 件 |

### 次のステップ

`/issue-verify-code [issue_id]` で修正確認を実施してください。
```

## Verdict 出力

実行完了後、以下の形式で verdict を出力すること:

---VERDICT---
status: PASS
reason: |
  修正完了
evidence: |
  全指摘事項に対応済み
suggestion: |
---END_VERDICT---

**重要**: verdict は **stdout にそのまま出力** すること。Issue コメントや Issue 本文更新とは別に、最終的な verdict ブロックは stdout に残す。

### status の選択基準

| status | 条件 |
|--------|------|
| PASS | 修正完了 |
| ABORT | 修正不可能 |