workflow-project-intake

プロジェクトの受付（ブレインストーミング＋要件の明確化＋振り分け）

スキルは「ステートレスな実行単位」として扱い、すべての状態をファイルシステムに外部化します。

このスキルは**「プロジェクトの入口／要件の明確化」**として位置付けられています。

• ユーザーのアイデアが漠然としている場合：実行チェーンに進む前に、要件（最小限の情報セット）の明確化を支援します
• ユーザーがリポジトリや明確な目標を提示した場合：理解した内容をすばやく確認してから、適切なワークフロー／ステップに進みます

このスキルは、実際の大規模な実装を担当するものではありません（それはworkflow-ship-faster／workflow-feature-shipperなどの実行スキルの役割です）。「会話」を「実行可能な入力」にまとめ、制御を引き継ぐ役割を担います。

基本原則（必ず従う）

1. パスのみを渡し、内容は渡さない：エージェント／サブエージェント間では..._pathのみを渡し、実行担当が自分でファイルを読み込みます。
2. ファイルを第一級の要素として扱う：すべてのステップで成果物を保存します。失敗時に再試行でき、再生および追跡が可能でなければなりません。
3. 書き込み操作にはチェックポイントを設ける：外部に影響を及ぼす操作（クラウドリソースの削除／変更、データベースへの書き込み、返金、サブスクリプションのキャンセルなど）を行う場合は、まず計画を書き出し、ユーザーの明示的な確認を待ちます。
4. 質問は一度に1つ：情報が不足している場合は追加で質問しますが、各メッセージで尋ねるのは質問1つだけです（選択式を優先）。複雑なテーマは複数回に分けてください。
5. Hooks doctor（必須チェック、ブロックなし）：Claude Code上で実行しており、進化ループを有効にしたい場合は、早い段階で一度tool-hooks-doctorを実行します。フックがない場合は、プロジェクトレベルのフックのインストールを提案し、いずれの場合も続行します。

0）ブレインストーミングモジュール（旧方式に代わるもの）

ユーザーの入力がまだ「アイデア／方向性／漠然とした要件」の場合は、まずworkflow-brainstormモジュールを使って実行可能な設計に具体化してから、受付チェックリストに進みます。

workflow-brainstormモジュールの要件：

• プロジェクトのコンテキストを最初に確認します（リポジトリが存在する場合）
• 質問は一度に1つだけにします（選択式を優先）
• トレードオフを説明しながら、2～3個の選択肢を提示します
• 設計を分割して出力します（各セグメントは約200～300語）。各セグメントの最後に「この内容でよさそうですか？」と尋ねます

生成する最小限の情報セット（受付チェックリスト）

ユーザーの入力を以下の情報にまとめます（不足している情報を尋ねます。すでに提示されている情報は再度尋ねません）。

質問の手順（必須）：

• 各メッセージで尋ねるのは質問1つだけ
• 選択式を優先し、必要な場合のみ自由回答式の質問を使います
• まず方向性を決める質問（成功基準／対象外の範囲／制約）を尋ね、その後に実装の詳細を尋ねます

A）開始タイプ

• entry_type：idea | prototype
• prototypeの場合：repo_root（ローカルパスまたはリポジトリのリンク）

B）成功基準（必須）

• ユーザーが最初に実装したい「中心となる1つのループ」（1文）
• 受け入れ基準（3～5項目）
• 明確な対象外の範囲（1～3項目）

C）Ship Fasterの主要スイッチ（要確認）

• need_database：データベースが必要かどうか（デフォルトはSupabase）
• need_billing：課金／決済が必要かどうか（デフォルトはStripe）
• need_auth：認証が必要かどうか（デフォルトはfalse）
• need_deploy：本番環境へのデプロイが必要かどうか（デフォルトはGitHub + Vercel）
• need_seo：SEOが必要かどうか（サイトマップ／robots／llms.txtなど）

D）制約（任意ですが推奨）

• リリースまでの期間（ある場合）
• リスクに対する方針（積極的／慎重）
• 既存のデザイン上の制約（ブランドカラー／フォント／既存のコンポーネントライブラリ）

実行ディレクトリの仕様

デフォルト（推奨）：対象プロジェクトのルートに作成します：runs/<workflow>/active/<run_id>/

OpenSpec 互換モード（openspec/project.md が存在する場合、またはユーザーが context.json で強制した場合）：

• アクティブ：openspec/changes/<change-id>/
• アーカイブ：openspec/changes/archive/YYYY-MM-DD-<change-id>/

バックエンドの選択ルール（決定的）：

1. context.json に "artifact_store": "runs" または "openspec" が含まれている場合は、その指定に従います。
2. それ以外で、repo_root に openspec/project.md が存在する場合は、OpenSpec モードを使用します。
3. それ以外の場合は、runs/ を使用します。

推奨構成（OpenSpec スタイル、簡潔）：

• proposal.md：ユーザーの目標（元の質問＋期待する出力＋制約＋受け入れ基準＋対象外事項）
• tasks.md：実行可能なチェックリスト（- [ ] → - [x]）＋承認ゲート
• context.json：主要なコンテキスト（repo_root、need_* スイッチ、リスク設定、既知の ID）
• evidence/（任意）：各アナライザーによる証拠・分析（大きな出力はチャットに含めないでください）
• logs/（任意）：
  • events.jsonl：構造化イベントログ（手順ごとに1行追加）
  • state.json：機械可読な状態（次の作業／完了した作業、任意）

アーカイブ規約（完了後）：active/<run_id>/ → archive/YYYY-MM-DD-<run_id>/ に移動します。

イベントログ形式（推奨）

1行につき1つの JSON：

{"ts":"2026-01-11T12:00:00Z","step":"evidence","action":"cloudflare.query_worker_observability","status":"ok","artifacts":["evidence/observability.md"],"note":"p95 latency spike"}

機密情報（トークン／メールアドレス／電話番号／秘密情報）は記録しないでください。必要に応じて、マスキングした内容を記録してください。

チェックポイントプロトコル（書き込み操作では必須）

書き込み操作を実行する前に：

1. tasks.md の Approvals セクションに承認計画を記述します（オブジェクト ID、影響範囲、検証方法）
2. 同じ概要を会話に提示し、ユーザーから明示的な返信「confirm/yes/proceed」があるまで待ちます。
3. ユーザーの確認後にのみ実行し、結果を evidence/ に記録します（必要に応じて logs/events.jsonl にも記録します）。

成果物（このスキルでは永続化が必須）

ルーティング／実行の前に、確認結果を次のファイルに書き込みます：

• proposal.md：目標、範囲、受け入れ基準、対象外事項、タイムライン
• context.json：repo_root、entry_type、need_* スイッチ、リスク設定など

この Intake に「design spec」フェーズ（workflow-brainstorm モジュールから）が含まれる場合は、次も永続化します：

• evidence/YYYY-MM-DD-<topic>-design.md：確認済みの設計と主要な決定事項（後続の計画／実装で参照）

注：

• ファイルがすでに存在する場合：不足しているフィールドの追加／情報の追記のみを行い、無条件に上書きしないでください（後続のワークフローで重複して書き込まれるのを避けるため）。
• 目的は、後続のワークフローが追加の確認を挟まず「すぐに実行を開始」できるようにすることです。

context.json（推奨される最小構成）：

{
  "entry_type": "idea",
  "repo_root": "",
  "scope": "full",
  "artifact_store": "auto",
  "need_database": false,
  "need_billing": false,
  "need_auth": false,
  "need_deploy": false,
  "need_seo": false
}

ルーティング：選択するワークフロー／スキル（デフォルトでは迅速なリリースを優先）

推奨する優先順位：

1. アイデア／小規模なプロトタイプからリリースまで（デフォルト）：workflow-ship-faster を使用します。

• workflow-ship-faster はデフォルトで runs/ship-faster/active/<run_id>/ に永続化します（または OpenSpec モードが選択されている場合は openspec/changes/<change-id>/）。DB／決済／デプロイ／SEO の任意ステップを実行するかどうかは、context.json のスイッチに基づいて判断します。
• スタイル／デザインシステムのみ：tool-design-style-selector を使用します。
• 1つの機能のイテレーションのみ（分割＋納品）：workflow-feature-shipper を使用します。
• React／Next.js のパフォーマンスレビューのみ（ウォーターフォール／バンドル／再レンダリング）：review-react-best-practices を使用します。
• DB 側の操作のみ（SQL／マイグレーション／ログ／型生成）：supabase スキルを使用します。
• Stripe 側の操作のみ（商品／価格／支払いリンク／返金など）：stripe スキルを使用します。

迷った場合：まず Intake Checklist を完了 → proposal.md／context.json を作成 → その後にルーティングします（大規模な操作を先に実行しないでください）。

会話の収束（必須）

後続のスキルに制御を引き渡す前に、このスキルを次の3段落で締めくくります。

1. 理解した内容を言い直します（目標、受け入れ基準、対象外事項）
2. 進めるルートを明確にします（デフォルトは workflow-ship-faster とし、その理由を説明します）
3. 今すぐ実行を開始するかユーザーに尋ねます：
   • 「workflow-ship-faster の実行を開始してもよいですか？（デフォルトでは、プロジェクト内の runs/ship-faster/active/<run_id>/ に成果物を書き込み、重要な書き込み操作の前に確認を求めます）」

並列実行（サブエージェント）

次のいずれかに該当する場合は、サブタスクを並列に分割します。

• ディレクトリまたはモジュールごとにスキャンする必要がある
• 観点（命名、関数、重複など）ごとにレビューする必要がある
• 複数の案（プラン A／B／C）を生成する必要がある

並列サブタスクの規約：

• 入力：パス（proposal_path、context_path、output_dir）のみを受け取ります
• 出力：evidence/parallel/<task-name>/ に成果物を書き込み、成果物のパス一覧を返します

チェックポイントからの再開

再実行する場合：

• まず tasks.md を読みます。マシン状態の確認が必要で、logs/state.json が存在する場合にのみ、それを使用します
• 完了済みのステップは繰り返さず、不足している成果物の補完または失敗した箇所からの続行のみを行います

成果物（最低要件）

• tasks.md：実際の状況を反映したチェックリスト、実行サマリー、次のステップ
• 任意：追跡可能性を確保するための logs/events.jsonl

完了後、skill-evolution の進化チェックポイント（3つの質問）を実施します。ユーザーが「最適化したい」を選んだ場合は、skill-improver を呼び出してこの実行をレビューし、最小限のパッチ案を提示します。