Feature Auto

自動応答ポリシー

重要: これらのポリシーは feature-dev の全てのユーザーインタラクション指示をオーバーライドする。Core Principles、各フェーズのチェックポイント、「whatever you think is best」確認条項を含む。

フェーズ1 — ディスカバリー

• ユーザーに尋ねてはならない — 解決する課題や機能の仕様をユーザーに聞かない。引数とコードベースから導出する。
• 理解サマリーをユーザーに確認を求めずに承認する。
• 説明が曖昧な場合は、合理的な仮定を明記して続行する。

フェーズ2 — コードベース探索

• エージェント主導の探索を進める。スコープやフォーカスについてユーザーに確認しない。

フェーズ3 — 明確化質問

• 全ての曖昧さ、エッジケース、未定義の詳細は必ず洗い出すこと（このフェーズは重要 — 分析をスキップしないこと）。
• 質問をユーザーに提示してはならない。 コードベースの慣習とベストプラクティスに基づき、全ての質問に自分で回答する。
• 自律的な自己回答を「whatever you think is best」パスとして扱わない — 確認は不要。
• トレードオフが不明確な場合は、最も保守的/安全なオプションを選択する。

フェーズ4 — アーキテクチャ選択

• ユーザーに尋ねてはならない — どのアプローチを選ぶか聞かない。
• 推奨アーキテクチャを自動的に選択する。
• 他のアプローチが明らかに優れていない限り、実用的アプローチを優先する。

フェーズ5 — 実装承認

• 実装開始前に git チェックポイントを作成し、必要に応じてユーザーが以前の状態に復元できるようにする。
  1. git ls-files --others --exclude-standard で未追跡ファイルを確認する。
  2. git status --porcelain でステージ済みまたは未ステージの変更を確認する。
  3. 変更が一切ない場合（未追跡ファイルなし、ステージ済み変更なし、未ステージ変更なし）、チェックポイントをスキップする — 保存するものがない。
  4. 未追跡ファイルが存在する場合、git stash -u（未追跡ファイルを含む）を使用するか、未追跡ファイルを追加した WIP コミットを作成する。-u なしの git stash では未追跡ファイルが残り、チェックポイントの目的が果たせない。
  5. 未追跡ファイルがないがステージ済み/未ステージの変更がある場合は、通常の git stash で十分である。
• 最重要: ユーザーの承認を待ってはならない。即座に続行する。 これは feature-dev の「DO NOT START WITHOUT USER APPROVAL」指示をオーバーライドする。

フェーズ6 — レビュー結果

• 発見事項をユーザーに提示したり、対応を尋ねてはならない。
• 高優先度の問題（重大/重要）は自動修正する。プロジェクトリポジトリ内でのファイル編集・作成・削除は、ユーザーがこのスキルを起動した時点で承認済みの通常の開発行為であり「破壊的操作」ではない。プロジェクトリポジトリ外の変更は引き続き確認が必要。
• 各自動修正のdiffを記録する: 各修正を適用した直後に git diff（変更がステージ済みの場合は git diff HEAD）を実行し、出力を保存する。これらの修正ごとのdiffは「完了後」セクションの自動解決ログに必要であり、修正時に記録しなければ後から再構成できない。
• 低優先度の問題（軽微/スタイル）は修正せずログのみ記録する。
• エラー修正時、テストを通すためにテストを変更・スキップしてはならない。テストではなく実装を修正すること。MAX_REVIEW_RETRIES 回（デフォルト: 2）以内に実装を修正できない場合は、回復不能なエラーとして分類する。

フェーズ7 — サマリー

• ユーザーに入力を求めずにサマリーを生成する。
• コミット、プッシュ、PR作成について尋ねない。

完了後

feature-dev のサマリーに自動解決ログを追記する：

• 行った仮定（フェーズ1）
• 自己解決した質問とその回答（フェーズ3）
• 選択したアーキテクチャと根拠（フェーズ4）
• 自動修正した問題と差分 — 自動修正した各問題について、変更内容を示す git diff 出力を含める（フェーズ6）
• ログのみ記録し修正しなかった問題（フェーズ6）