---

name: feature-revision description: Guide feature modification process with structured proposal document. Use when user requests feature changes, bug fixes requiring spec changes, or modifications to existing functionality. Manages requirements gathering, proposal creation, design documentation, and TDD workflow planning through phased user confirmation. allowed-tools: Read, Write, Edit, Glob, Grep, AskUserQuestion

機能修整スキル

既存機能の修正・改善を構造化された提案書形式で進めるスキルです。

When to Use

• ユーザーが「機能を修正したい」「仕様を変更したい」と言った時
• バグ修正が設計変更を伴う場合
• 既存機能の改善・拡張を行う場合
• 「/feature-revision」「/func-revision」「/修整」と指示された時

実行フロー概要

CopyPhase 0: ヒアリング（開発内容の把握）
    ↓
Phase 1: 提案書作成（## 1〜4）→ ユーザー確認
    ↓
Phase 2: 設計フロー（## 5）→ ユーザー確認 → 設計ドキュメント反映
    ↓
Phase 3: TDDワークフロー（## 6）→ ユーザー確認 → 実装開始

---

Phase 0: ヒアリング

ユーザーから開発内容を把握し、提案書作成に必要な情報を収集します。

AskUserQuestionツールを使用して以下を確認：

1. 対象サービス・セクション: どのサービス・セクションの機能を修正するか
2. 変更内容: 何をどう変えたいか（現状と理想）
3. 背景・目的: なぜこの変更が必要か
4. 関連ドキュメント: 既存の設計書があるか

ヒアリング例

Copyどのような機能修正を行いますか？以下の情報を教えてください：

1. 対象: どのサービス・セクションですか？（例: account/authentication, blog/posts）
2. 変更内容: 現状（As-Is）と修正後（To-Be）を簡潔に
3. 背景: なぜこの修正が必要ですか？

---

Phase 1: 提案書作成（## 1〜4）

仕様変更提案テンプレートを使用し、提案の基本部分を記載します。

1-1: テンプレートをコピー

Copy# テンプレートをルート直下にコピー
cp develop/仕様変更提案テンプレート.md ./【機能修正提案】{機能名}.md

ファイル名は 【機能修正提案】{機能の簡潔な説明}.md とします。

1-2: ## 1〜4 を記載

Phase 0で収集した情報を基に、以下のセクションを記載：

1-3: ユーザー確認

記載完了後、ユーザーに内容を確認してもらいます。

確認ポイント:

• 提案概要が意図と合っているか
• As-Is / To-Beの認識に齟齬がないか
• Pros/Consの評価が妥当か

確認方法: 提案書の該当セクションを表示し、承認を求める

---

Phase 2: 設計フロー（## 5）

Phase 1でユーザー確認が取れていることが前提です。

設計ドキュメントへの影響を整理し、編集内容を明確化します。

2-1: ## 5 設計フローを記載

以下の設計ドキュメントを上から順に確認し、編集内容を追記：

各項目について、変更がある場合は具体的な編集内容を記載。 変更がない場合は「変更なし」と明記。

2-2: ユーザー確認

記載完了後、ユーザーに設計フローの内容を確認してもらいます。

2-3: 設計ドキュメントへの反映

ユーザー確認が取れたら、実際の設計ドキュメントを編集します。

対象ファイルパス（例: accountサービスの場合）:

• develop/account/{section}/func-spec.md
• develop/account/{section}/uiux-spec.md
• app/specs/account/{section}-spec.yaml

---

Phase 3: TDDワークフロー（## 6）

Phase 2でユーザー確認が取れ、設計ドキュメントが更新されていることが前提です。

実装計画を立て、TDDフローに沿った作業手順を明確化します。

3-1: ## 6 TDD_WORK_FLOW.md 簡易版を記載

以下の全項目に対して、実際のパスと編集内容を1行で記載：

特に重要: 新規ファイルは明確に識別できるように記載

3-2: ユーザー確認

記載完了後、ユーザーにTDDワークフローの内容を確認してもらいます。

3-3: 実装開始

ユーザー確認が取れたら、TDDフローに従って実装を開始します。

実装順序:

1. E2Eテスト（Red）
2. 単体テスト（Red）
3. 実装（Green）
4. リファクタリング

---

成果物

---

注意事項

各フェーズでのユーザー確認は必須

ユーザー確認なしに次のフェーズに進まないこと。 確認を求める際は、該当セクションの内容を明示すること。

提案書はルート直下に配置

develop/ 配下ではなく、プロジェクトルート直下に配置します。 これにより、進行中の修正案件であることが明確になります。

実装完了後の提案書の扱い

実装完了後、提案書は以下のいずれかの扱いとする：

1. docs/thinking/ に移動（設計判断の記録として保存）
2. 削除（不要な場合）

移動・削除はユーザーに確認してから行うこと。