workflow-feature-shipper

Feature Shipper

「機能を作りたい」を、すばやく実行できる一連の流れに変えます。

入力（パスのみ渡す）

• feature.md：要件の説明（受け入れ条件＋対象外事項）
• repo_root
• run_dir

オプションのフラグ（feature.md 内に記載することを推奨）

• mode：plan-only | execute（デフォルト：execute）
• feature_slug：成果物の命名に使用する短いスラッグ（デフォルト：タイトル＋タイムスタンプから生成）
• quality_bar：demo-ready | functional-only（デフォルト：ユーザー向け UI 機能では demo-ready）

出力（永続化）

• evidence/features/<feature_slug>-plan.md（チェックリスト形式の計画：タスク＋検証）
• evidence/parallel/features/<feature_slug>/（実装を分割する場合）
• evidence/features/<feature_slug>-summary.md

プロセス

0. Hooks doctor（必須チェック、ブロッキングではありません）：セッション開始時に一度 tool-hooks-doctor を実行し、skill-evolution フックが有効になっていることを確認します。フックが見つからない場合は、プロジェクトレベルのフックのインストールを提案します。いずれの場合も続行します。
1. feature.md を読み、受け入れ条件、境界、リスク、ロールバックに整理します。
2. UI プロトタイプのルール（デフォルト）：この機能がユーザー向け UI に影響し、quality_bar が functional-only ではない場合、「デモの見せ場」を 1 つ提案し、受け入れ条件に追加します。prefers-reduced-motion を尊重する必要があります。
3. 2 つの選択肢（A：最小限、B：より洗練されているが時間がかかる）を提示し、デフォルトは A とします。ユーザーが「デモらしさ」を重視する場合は、A-demo-ready と A-functional-only を明示的なサブオプションとして提示します。
4. 個別に実行・ロールバックできる、PR サイズの小さなステップに分割します。
5. 計画を evidence/features/<feature_slug>-plan.md に書き込みます。
6. mode: plan-only の場合はここで停止し、実装前に確認を求めます。
7. 実装（バッチ実行＋チェックポイント）：
   • UI の見た目、レイアウト、アニメーションの変更 → まず tool-design-style-selector を呼び出してプロジェクトの design-system.md を読み込み、厳密に従います。tool-ui-ux-pro-max がインストールされている場合は、それを使って動きと UX の制約を確認します（「animation」＋「accessibility」を検索）。複雑な見た目、アニメーション、レスポンシブデザインについては、/gemini のフロントエンド UI/UX シニアデザインエージェントに委任します。
   • ビジネスロジック、データフロー、統合 → 直接実装します。
   • デフォルトのバッチサイクル：バッチごとに小さなタスクを 3 つ実行 → 検証を実行 → 報告してフィードバックを待ちます。ブロックされた場合や検証に失敗した場合は、直ちに停止して支援を求めます。
   • 各バッチの後（またはマージ前）に、最終的なレビューと判定のため review-quality の使用を推奨します。
     • review-quality が唯一のエントリーポイントで、自動的にトリアージします。React/Next.js のパフォーマンスリスクが検出された場合は、review-react-best-practices も実行します。
     • React/Next.js のパフォーマンス監査のみを明示的に希望された場合は、review-react-best-practices を直接実行します。
8. 検証：実行できること、ビルドできること（既存のテストが合格すること）。
   • 検証に失敗した場合（テスト／ビルド／ランタイムエラー）、追加の修正を試みる前に tool-systematic-debugging を実行します。
   • デバッグの成果物を次の場所に永続化します：
     • evidence/features/<feature_slug>-debug.md（再現手順、仮説、根本原因、修正＋再検証）
9. evidence/features/<feature_slug>-summary.md に、実施内容、検証方法、次のステップを記録します。
10. 締めくくりとして、skill-evolution の Evolution checkpoint（3 つの質問）を行います。ユーザーが「最適化したい」を選択した場合は、この run_dir に基づいて skill-improver を実行し、最小限のパッチ提案を作成します。

提供要件

• 「ビッグバン」リファクタリングは行いません。
• 新たな複雑さを持ち込まないでください（将来のコストを大幅に削減でき、ユーザーが確認した場合を除く）。