workflow-ship-faster

ワークフロー：より速くリリースする（Next.js 16.1.1）

このチェーンの目標は、反復の速度をその後も維持しながら、アイデアや小規模なプロトタイプを最短時間で本番運用可能な状態にすることです。

使用するタイミング

ユーザーが次のようなエンドツーエンドのチェーンを求めている場合に、このワークフローを使用します。

• 「このMVPをリリースして」「本番運用可能な状態にして」「このプロジェクトを公開／デプロイして」
• 「このプロトタイプを実際のアプリにして」
• 「基盤＋UIシステム＋デプロイをセットアップして」

基本原則（必須）

• 渡すのはパスのみで、内容は渡しません：エージェント／サブエージェント間では ..._path のみを渡します。
• ファイルを第一級の成果物として扱います：各ステップで成果物を保存します。失敗した場合は再試行でき、処理を再現できます。
• 確認ポイントを設けます：あらゆる「高リスク／高負荷／副作用のある」操作では、まず計画を書き、確認を待ちます。
• 計画はチェックリストとして管理します：進捗はチャットではなく、tasks.md で - [ ] → - [x] として追跡します。
• 段階的に情報を開示します：必要になったときだけ、このスキルディレクトリ内のステップファイル（foundation.md、deploy-vercel.md など）を開きます。一度にすべての詳細を読み込まないでください。
• Hooks doctor（必須チェック、ブロックしません）：Claude Code で実行しており、進化ループを有効にしたい場合は、セッション開始時に tool-hooks-doctor を一度実行します。フックがない場合は、プロジェクトレベルのフックのインストールを提案します（いずれの場合も続行します）。

入力／出力（パスのみ）

入力（パスのみ）：

• repo_root：プロジェクトのルート（デフォルトは "."）
• 任意：ユーザーがすでに使用している run_dir（アクティブな実行ディレクトリ）

出力（成果物、run_dir/ の下に書き込みます）：

• 必須：proposal.md、tasks.md、context.json
• 任意：design.md、evidence/、logs/

正式な仕様（バックエンド、テンプレート、読み込み順、アーカイブの自動化）：

• references/artifact-contract.md
• リファレンスの索引：references/README.md

ステップモジュール（該当するステップに到達したときだけ開きます）

• 基盤：foundation.md
• ガードレール：guardrails.md
• トレースのクリーンアップ：cleanup-traces.md
• ドキュメントのベースライン：docs-baseline.md
• Supabase の統合：supabase-integration.md
• Stripe の統合：stripe-integration.md
• デプロイ（GitHub + Vercel）：deploy-vercel.md
• AI 時代の SEO（Next.js）：ai-seo-nextjs.md

プロセス（デフォルトのルート）

0) 実行の初期化（必須）

1. run_dir/ を解決／作成します（references/artifact-contract.md の決定論的なバックエンドルールを参照）。
2. 基本となる成果物が存在することを確認します（存在しない場合は作成し、すでに存在する場合はマージ／追記します）。
   • proposal.md、tasks.md、context.json
3. tasks.md で次の項目を確認します。
   • 冒頭付近に status: active|blocked|done フィールドがあること
   • 短い 次のアクション セクション（1～3項目）
   • 承認 セクション（必要になるまでは空で構いません）
4. 保存する大きな出力が実際にある場合に限り、evidence/ と logs/ を作成します。

0.2) スコープの確認（必須）

この問題が解決するもの：ユーザーがスキップを選択していないのに、重要なステップが「スキップ」と記載された実行サマリーは誤解を招き、監査も困難です。

ビルドチェックを超えるステップを実行する前に、ユーザーにスコープを選択してもらいます。

• A) full（デフォルト）：基盤 → デザインシステム → UI/UX → ガードレール → ドキュメント → 機能の反復 → デプロイ
• B) deploy-only：基盤（ビルド＋動作確認）→ デプロイのみ（UI 作業、ガードレールやドキュメントの仕上げはなし）
• C) design-only：デザインシステム＋UI/UX の計画のみ（コード変更なし）
• D) feature-only：1 回の機能反復（計画＋実装）、デプロイはスキップ

ルール：

• 選択したスコープを context.json に保存します（scope フィールドを追加または更新します）。
• tasks.md では、ユーザーが明示的にスキップを依頼しない限り、デフォルトのステップを「スキップ」と記載しないでください。
  • 推奨：disabled (scope=...) とし、「Scope / Disabled steps」セクションに簡潔な理由を記載します。
• 破壊的な操作（例：既存のリポジトリを上書きする強制プッシュ）は、リスクの高い副作用です。
  • まず tasks.md に実行可能な承認項目を記載します。
  • 実行前に、ユーザーから明示的な確認を得ます。

0.25) キックオフ時の確認（軽量ブレインストーミング）（推奨。目標が曖昧な場合は必須）

この問題が解決するもの：人々がすぐに「機能を実装する」ことに取りかかると、デモが難しい、ごく基本的な MVP になりがちです。

次のいずれかに該当する場合は、このステップを実行します。

• proposal.md に明確な受け入れ基準と対象外事項がない
• ユーザーの依頼が「X のようなものを作る」／「プロトタイプを作る」であり、中心となるループが指定されていない
• ユーザーが「デモ可能な状態」のプロトタイプを明示的に希望している（アニメーション、驚きの演出、共有可能なもの）

手順：

• 同じ repo_root とこの run_dir を使用して workflow-brainstorm を呼び出します。
• 質問は一度に1つずつ行うルールに従い、次の点をまとめます。
  • 1つの中心となるループ（1文）
  • 受け入れ基準（箇条書きで3～5項目）
  • 対象外事項（箇条書きで1～3項目）
  • 制約（タイムライン／リスクに対する希望）
  • 「デモの見せ場」の方向性（ステップ 0.3 を参照）
• 確定した仕様を次のファイルに保存します。
  • evidence/YYYY-MM-DD-kickoff-design.md
• 次の入力を更新します（上書きせず、統合します）。
  • proposal.md
  • context.json（need_database/need_billing/need_deploy/need_seo が明示的に設定されていることを確認します）

0.3) デモの見せ場を最優先する（プロトタイプに推奨）

原則：本物らしく感じられるプロトタイプには、少なくとも1つの「デモの見せ場」が必要です（上品で目を引く演出にし、奇をてらったものにはしません）。

「デモの見せ場」の例（1つ選び、小規模に保ちます）。

• ライブのインタラクティブプレビュー（ダミーデータでも可）と、滑らかで意図のある動きを備えたヒーローセクション
• コマンドパレット、ドラッグ可能なカード、タイムラインスクラバーなど、心地よいマイクロインタラクション
• 中心となるループを明確に伝える「変更前／変更後」の変換アニメーション（入力 → 出力）

ワークフロー：

1. 小さな機能仕様ファイルを作成します（存在しない場合）。
   • evidence/feature-00-demo-moment.md
   • mode: plan-only、feature_slug: demo-moment、quality_bar: demo-ready を含めます。
2. workflow-feature-shipper を呼び出し、計画のみを生成します（まだ実装はしません）。
3. デモの見せ場が選択したデザインシステムに沿うよう、実際の UI 実装はステップ 2 の後（design-system.md が存在してから）に行います。

0.5）動的な分岐判断（必須）

context.json の内容に基づき、実行順序を動的に調整します。

• データベース連携：context.json に "need_database": true がある場合にのみ実行します
• 決済連携：context.json に "need_billing": true または "need_stripe": true がある場合にのみ実行します
• 認証：context.json に "need_auth": true または "auth": true がある場合にのみ実行します
• デプロイ：context.json に "need_deploy": true がある場合、またはユーザーがデプロイを明示的に依頼した場合にのみ実行します
• SEO：context.json に "need_seo": true がある場合、またはプロジェクトがすでに公開されている場合にのみ実行します

各オプションのステップを開始する前に：

• context.json（および選択した scope）を確認し、そのステップが必要か判断します
• スキップする場合は、tasks.md に理由を1行で記録します（再開や監査でチャット履歴が不要になるようにします）

1）基盤：Next.js の基盤（デフォルトで必須）

foundation.md を開いて、その指示に従います。

成果物の要件（最低限）：

• evidence/foundation.md（現状＋リスク評価＋選択した方針）
• tasks.md：基盤のチェックリストセクションを追加します（タスク＋検証コマンド）
• アップグレード／移行で大幅な変更が必要な場合：tasks.md に承認項目を追加し、確認を待ちます

分岐ルール（重要）：

• 結論が現在のスタックを維持（例：Vite の静的サイト）の場合、「Next.js 固有のステップ」を無理に続けないでください。
  • 現在のスタックに引き続き適用できるステップのみ実行します：スタイル（2）、ガードレール（3、現在のスタックに合わせて調整）、ドキュメント（4）、デプロイ（8、任意）、SEO（9、任意）
  • DB／決済連携が引き続き必要な場合：まず「Next.js に移行しますか？」とユーザーに確認するか、そのスタック向けの連携ステップを追加します（このチェーンのデフォルトの対象範囲には含まれません）

2）スタイル仕様（デフォルトで必須）

tool-design-style-selector を呼び出し、プロジェクトの意図を確認して design-system.md に保存します。

確認ポイント：ユーザーがスタイルを確認した後、design-system.md を反映し、2.5 UI/UX 実装に進みます（デフォルトで必須。ユーザーが明示的にスキップする場合は理由を記録します）。

2.5）UI/UX 実装（デフォルトで必須）

目標：design-system.md を仕様として書くだけでなく、実際にインターフェースへ反映させます。

推奨する方法：「design-system.md に沿った UI/UX のやり直し」を独立した機能として扱い、workflow-feature-shipper に引き継ぎます。

• 入力：design-system.md（唯一のデザイン制約）＋現在の UI ページ一覧（コードスキャンから取得）
• 出力：evidence/features/<feature_slug>-plan.md（スコープ／受け入れ基準／対象外／リスク／ロールバック）＋コード変更

デフォルトの追加内容（インストール済みの場合）：

• tool-ui-ux-pro-max がインストールされている場合は、これを使って UI/UX 計画に具体的な配色、タイポグラフィ、UX のガードレールを追加し、納品前チェックリストを受け入れ基準として使用します。
• ユーザーがスキップを明示的に依頼した場合（例：「過剰にデザインしない／シンプルに保つ」）に限り、tool-ui-ux-pro-max による補強をスキップし、その理由を記録します。

大規模なリファクタリングの場合：まず tasks.md に承認項目を追加し、実装前にユーザーの確認を待ちます。

3）コード規約（軽量、必須）

guardrails.md を開いて、その指示に従います。

成果物：tasks.md（ガードレールのチェックリストセクション）

3.5）痕跡の整理（ブランド除去とソースのクリーンアップ）（プロジェクトをコピーした場合は必須）

解決する問題：Google AI Studio／v0／Lovable からインポートされた多くのスタータープロジェクトには、ベンダーのブランド表記や、壊れた残骸（importmap など）、誤解を招く README の説明が含まれています。

cleanup-traces.md を開いて、その指示に従います。

成果物：

• evidence/trace-scan.md
• tasks.md（痕跡整理のチェックリストセクション）

4）ドキュメント規約（軽量、必須）

docs-baseline.md を開いて、その指示に従います。

成果物：tasks.md（ドキュメントのチェックリストセクション、およびプロジェクトの README の更新）

5) コア機能の開発（反復ループ）

workflow-feature-shipper を呼び出します：

• 各機能では、まず evidence/features/<feature_slug>-plan.md を作成します（受け入れ基準／対象外事項を含めます）
• デフォルトでは、PR にできる小さなステップに分割します
• 各バッチの後（またはマージ前）に、決定的なレビューと判定を得るため review-quality の呼び出しを推奨します
• review-quality が唯一のエントリーポイントとなり、自動で振り分けます。React／Next.js のパフォーマンスリスクが検出された場合は、review-react-best-practices も実行します（CRITICAL ルールを優先）

認証に関する注記（任意）：機能にログイン／セッション／権限が含まれ、tool-better-auth がインストールされている場合は、実装前にこれを呼び出して、セッション戦略、リダイレクト、Cookie／CSRF、ミドルウェアの境界を確定します。以下を保存します：

• evidence/auth-plan.md
• evidence/auth-summary.md

6) データベース連携（任意）

実行条件：context.json に "need_database": true または "database": "supabase" があること

開いて、次の内容に従います：supabase-integration.md。

7) 決済連携（任意）

実行条件：context.json に "need_billing": true または "need_stripe": true または "payment": true があること

開いて、次の内容に従います：stripe-integration.md。

8) GitHub + Vercel へのデプロイ（任意ですが推奨）

実行条件：context.json に "need_deploy": true があるか、"deploy_target" フィールドが存在し、空でないこと

開いて、次の内容に従います：deploy-vercel.md。

9) AI 時代の SEO（任意ですが推奨）

実行条件：context.json に "need_seo": true または "seo": true があるか、ステップ 8 が正常に完了していること（デプロイ済み）

開いて、次の内容に従います：ai-seo-nextjs.md。

最終納品

final.md（実行ルート内）に、最低限次の内容を記載します：

• 現在のプロジェクト状況（ローカルで実行可能か、ビルド可能か、デプロイ済みか）
• 完了したステップと成果物のパス
• 次のステップ（価値の高い順）

また、次の作業を完了します：

• tasks.md の status を done に更新し、Delivery summary を記入します
• 各バッチの後と最後に自動アーカイブを実行します：
  • python3 ~/.claude/skills/workflow-ship-faster/scripts/auto_archive.py --run-dir "<run_dir>"
• 作業領域を整理したい場合（自動アーカイブを使わない場合）：active/<run_id>/ を archive/YYYY-MM-DD-<run_id>/ に移動します
• skill-evolution の Evolution checkpoint（3 つの質問）を実施します。ユーザーが「最適化したい」を選んだ場合は、この run_dir に基づいて skill-improver を実行し、最小限のパッチ提案を作成します