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）を読み取る。

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

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

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

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

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

Step 5b から続行する。

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

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

ユーザーに確認する。

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

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

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

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

Step 2: 改修項目の選択

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

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

| # | 優先度 | 内容 |
|---|-------|------|
| 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 を上書き保存する。

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

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

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

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

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

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

3e. 中断の検知

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---
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 に実装手順書を作成する。

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

---
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:

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（各タスクごと）:

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 <機能名> で実装に進めます」