---
name: fix-feature
description: audit-feature の監査レポートを基に、既存機能の改修要件定義書・実装手順書・GitHub Issueを作成するスキル。監査レポートから改修方針を定義したい、"$fix-feature"、"/fix-feature" の依頼で使用する。
---

# Fix Feature

`audit-feature` の監査レポートを基に、既存機能の改修要件を定義し、実装手順書・GitHub Issueを作成する。
`define-feature` の改修版として、同じパイプラインに接続する。

**ユーザーとの対話はすべて日本語で行うこと。**

## 並行作業とworktree前提の注意

- このスキルは改修要件定義と改修実装手順書を作るためのもの。実装作業そのものは原則として専用worktreeで行う前提で計画する。
- 同じ `docs/features/<機能名>/fix-requirements.md` や `fix-implementation-plan.md` を複数セッションで同時に編集しない。途中状態のファイルがある場合は、その内容を読み、どのセッションの作業か確認してから続行する。
- `fix-implementation-plan.md` には、実装時に専用worktreeを使うこと、同じファイルを別セッションで同時編集しないこと、commit/push/PR作成前に確認することを前提としてタスクを分割する。
- 監査レポートの推奨アクションが複数ある場合は、並行実装しても衝突しにくい単位へ分ける。

## Step 0: 起動モードの判定

### 機能名が指定されている場合

ユーザーの依頼で指定された機能名に対応する `docs/features/<機能名>/fix-requirements.md` を探す。

- **ファイルが存在し、`status` が `completed` でない場合**: 途中再開モード（Step 0a へ）
- **ファイルが存在し、`status` が `completed`、かつ `fix-implementation-plan.md` の `status` が `completed` でない場合**: 実装手順書の途中再開モード（Step 0b へ）
- **ファイルが存在しない場合**: 新規作成モード（Step 1 へ）
- **両方とも `completed` の場合**: 「この機能の改修要件定義は完了済みです。実装スキルを追加済みなら `$implement <機能名>` で実装に進めます。」と伝える

### 機能名が指定されていない場合

会話コンテキストに `audit-feature` のレポートがあるか確認する。

- **レポートがある場合**: レポートから機能名を抽出し、Step 1 へ
- **レポートがない場合**: `docs/features/` 配下を走査し、途中状態の `fix-requirements.md` があれば一覧表示する。なければ「先に `$audit-feature <機能名>` で監査を実施してください。」と伝える

### Step 0a: ヒアリング途中からの再開

`fix-requirements.md` のフロントマター（`status`, `completed_sections`, `next_section`）を読み取る。

```text
前回は「<機能名>」の改修要件定義で、<completed_sections> まで完了しています。
<next_section> のヒアリングから再開します。
```

該当する Step のセクションから続行する。

### Step 0b: 実装手順書の途中再開

`fix-requirements.md` は完了済み。`fix-implementation-plan.md` のフロントマターを読み取り、途中から再開する。

```text
前回は「<機能名>」の改修要件定義書は完了しており、実装手順書の作成途中です。
続きから再開します。
```

Step 5b から続行する。

## Step 1: 監査レポートの確認

会話コンテキストにある `audit-feature` のレポートを確認する。

ユーザーに確認する。

```text
直前の監査レポートを基に改修要件の定義を進めます。よろしいですか？
```

確認を得たら、レポートから以下を抽出する。

- 機能名
- 懸念事項・問題点の一覧
- 推奨アクションの一覧（優先度付き）

`docs/features/<機能名>/` ディレクトリが存在しなければ作成する。

## Step 2: 改修項目の選択

レポートの推奨アクションを一覧表示し、ユーザーに対応する項目を選択してもらう。

```text
監査レポートの推奨アクション:

| # | 優先度 | 内容 |
|---|-------|------|
| 1 | 高 | ○○のバリデーション不足を修正 |
| 2 | 高 | ○○のN+1クエリを解消 |
| 3 | 中 | ○○の認可チェック追加 |
| 4 | 低 | ○○のエラーハンドリング改善 |

どの項目に対応しますか？（番号をカンマ区切りで指定。例: 1,2,3）
```

選択された項目を改修スコープとして確定する。

## Step 3: 改修方針のヒアリング

選択された各項目について、改修方針を掘り下げる。
既存のコードベースを調査しながら、具体的な修正方法を提案・確認する。

### 3a. 改修内容の詳細化

各項目について:

- 現状の問題（レポートから引用）
- 具体的な修正方針（コードベース調査に基づく提案）
- 修正後のあるべき姿

ユーザーと認識合わせを行い、方針を確定する。
完了したら自動保存する。

### 3b. 技術設計

改修に伴う変更の詳細:

- APIの変更（エンドポイント、リクエスト/レスポンスの変更）
- DBスキーマの変更（カラム追加・変更・削除）
- フロントエンドの変更（コンポーネント、状態管理）
- バックエンドの変更（Controller / Service / Repository / Entity / DTO）

完了したら自動保存する。

### 3c. 影響範囲の確認

- 変更が波及する既存機能
- 共通コンポーネント・ユーティリティへの影響
- API・DBスキーマの互換性（破壊的変更の有無）

完了したら自動保存する。

### 3d. 自動保存の仕組み

各セクション完了時に `docs/features/<機能名>/fix-requirements.md` を上書き保存する。

```markdown
---
status: ヒアリング中
completed_sections: [改修内容, 技術設計]
next_section: 影響範囲
audit_source: 会話内レポート
selected_items: [1, 2, 3]
---
# <機能名> 改修要件定義書（ドラフト）

## 1. 改修概要
- 対象機能
- 改修の背景（監査レポートからの引用）
- 改修スコープ（選択した項目）

## 2. 改修内容
（確定した内容）

## 3. 技術設計
（確定した内容 or 未着手）

## 4. 影響範囲
（確定した内容 or 未着手）

## 5. 設計判断の根拠
（確定した内容 or 未着手）
```

### 3e. 中断の検知

ユーザーが「今日はここまで」「また明日」「一旦終わり」等の発言をした場合、現時点の内容を保存する。

```text
現在の進捗を保存しました。
- ファイル: docs/features/<機能名>/fix-requirements.md
- ステータス: ヒアリング中
- 完了済み: <completed_sections>
- 次回: <next_section> から再開

再開するには `$fix-feature <機能名>` または `/fix-feature <機能名>` を実行してください。
```

## Step 4: 改修要件定義書ドラフトの提示

全ヒアリング完了後、`fix-requirements.md` のステータスを更新する。

```yaml
---
status: ドラフトレビュー中
completed_sections: [改修内容, 技術設計, 影響範囲]
next_section: null
audit_source: 会話内レポート
selected_items: [1, 2, 3]
---
```

以下の構成でドラフトを提示し、ユーザーの承認を得る。修正指示があれば反映して再提示する。

```markdown
# <機能名> 改修要件定義書

## 1. 改修概要
- 対象機能
- 改修の背景（監査で検出された問題）
- 改修スコープ

## 2. 改修内容
### 2.1 項目ごとの改修詳細
- 現状の問題
- 修正方針
- 修正後のあるべき姿

## 3. 技術設計
### 3.1 API変更
### 3.2 DB変更
### 3.3 フロントエンド変更
### 3.4 バックエンド変更

## 4. 影響範囲
- 影響を受ける既存機能
- 破壊的変更の有無

## 5. 設計判断の根拠
- 主要な設計判断とその理由
```

承認後、ステータスを `completed` に更新する。

```yaml
---
status: completed
audit_source: 会話内レポート
selected_items: [1, 2, 3]
---
```

ドラフトレビュー中にユーザーが中断を申し出た場合も、Step 3e と同様に保存して中断する。

## Step 5: 成果物の作成

### 5a. 要件定義書の確定

Step 4 で承認済みの `fix-requirements.md` がそのまま確定版。

### 5b. 実装手順書の作成

`docs/features/<機能名>/fix-implementation-plan.md` に実装手順書を作成する。

作成開始時にフロントマター付きでファイルを作成する。

```markdown
---
status: draft
---
# <機能名> 改修実装手順書

## 実装タスク

## 並行作業ルール
- 実装は専用worktree（例: `C:\tmp\fix-<summary>` または `C:\tmp\impl-<summary>`）で行う
- メイン作業ツリーでは原則として編集しない
- 複数セッションで同じファイルを同時編集しない
- commit / push / PR作成前に変更内容とテスト結果を確認する

### タスク1: <タスク名>
- [ ] 完了
- **概要:** タスクの説明
- **変更対象ファイル:**
  - `path/to/file1` - 変更内容
  - `path/to/file2` - 変更内容
- **依存タスク:** なし / タスクN
- **対応Issue:** （Issue作成後に記入）

### タスク2: <タスク名>
...

## 実装順序
1. タスク1（依存なし）
2. タスク2（タスク1に依存）
3. ...
```

ユーザーに内容を提示して承認を得る。承認後、ステータスを `completed` に更新する。
作成中にユーザーが中断を申し出た場合、`status: draft` のまま保存し、中断メッセージを表示する。

### 5c. GitHub Issue の作成

**前提条件:** `fix-requirements.md` と `fix-implementation-plan.md` の両方が `status: completed` であること。

Issue作成前に、これから作る親Issue・子Issueのタイトルと本文要約をユーザーに提示し、承認を得る。

**ラベルの自動判定:**

- 改修内容にバグ修正（ロジックの誤り、エッジケース漏れ等）が含まれる: `bug`
- 改善・リファクタリングが主体: `improvement`
- 混在する場合: 両方のラベルを付与

**親Issue:**

```bash
gh issue create --title "[Fix] <機能名> 改修" --label "<判定したラベル>" --body "$(cat <<'EOF'
## 概要
<改修の概要>

## 監査レポートからの対応項目
<選択された推奨アクションの要約>

## 改修要件定義書
`docs/features/<機能名>/fix-requirements.md`

## 改修実装手順書
`docs/features/<機能名>/fix-implementation-plan.md`

## タスク一覧
- [ ] #<子Issue番号>: タスク1
- [ ] #<子Issue番号>: タスク2
...
EOF
)"
```

**子Issue（各タスクごと）:**

```bash
gh issue create --title "<タスク名>" --label "<判定したラベル>" --body "$(cat <<'EOF'
## 親Issue
#<親Issue番号>

## 概要
<タスクの説明>

## 変更対象ファイル
- `path/to/file1` - 変更内容
- `path/to/file2` - 変更内容

## 依存タスク
なし / #<依存する子Issue番号>

## 完了条件
- <具体的な完了条件>
EOF
)"
```

子Issue作成後、親Issueのタスク一覧に子Issue番号を反映する。
実装手順書の各タスクにも対応するIssue番号を記入する。

## Step 6: 完了報告

ユーザーに以下を報告する。

- 作成した改修要件定義書のパス
- 作成した改修実装手順書のパス
- 親IssueのURL
- 子Issue一覧（番号・タイトル・URL）
- 「実装スキルを追加済みなら `$implement <機能名>` で実装に進めます」