クライアント要件からの高速プロトタイピング

納期どおりに納品されたプロトタイプは次の契約を勝ち取り、デモ日程を逃したプロトタイプはそれを失います。Sun Agent Kitを使えば、クライアントの要件仕様書、機能リスト、画面モックアップをフォルダに入れて /sk:brainstorm で指定するだけです — エージェントがすべてを読み取り、要件を抽出し、ギャップを特定し、スタックを推奨します。そこから /sk:bootstrap でプロジェクトをスキャフォールドし、機能ごとの /sk:plan + /sk:cook サイクルでクライアントとのミーティング前に完成させます。

概要

目標: クライアントのブリーフから、1日以内にデモ可能な動作するプロトタイプを作成する
所要時間: 2〜4時間（手動では2〜3日）
使用エージェント: planner、implementer、reviewer
コマンド: /sk:brainstorm、/sk:research、/sk:ui-ux-pro-max、/sk:bootstrap、/sk:plan、/sk:cook、/sk:code-review、/sk:git

前提条件

Sun Agent Kitがインストール済みであること（インストールガイド）
Node.js 18以上またはBunランタイムが利用可能であること
クライアントのドキュメントがプロジェクトディレクトリに配置されていること — 要件仕様書、機能リスト、画面リスト、会議メモ（PDF、Markdown、Word、またはプレーンテキストすべて対応）
対象ディレクトリでGitが初期化済みであること（git init)
明確なデモ期限があること（ブレインストームエージェントがスコープとスピードのトレードオフを調整できるよう）

ステップバイステップのワークフロー

ステップ1：クライアントドキュメントからブレインストームする

/sk:brainstorm "read ./docs/client-brief/ — this contains the client's requirement spec, feature list, and screen mockups for a personal task manager. Brainstorm what's missing, suggest the fastest stack for a 3-day prototype, and flag any scope risks"

実行内容: エージェントが以下を実行します：

指定パス内のすべてのファイル — PDF、Markdown、画像、スプレッドシート — を読み取り、要件、機能、画面説明を抽出します
クライアントドキュメントのギャップを特定します：不足しているエッジケース、未定義のユーザーフロー、曖昧な要件
クライアントがまだ検討していなかった追加の機能や改善点をブレインストームします
期限を考慮したプロトタイプ速度に最適化されたスタックを推奨します
確認済みの機能リスト、スタック決定、およびクライアントに確認すべき質問のリストを出力します

ステップ2：スタック選定を検証する

/sk:research "best lightweight stack for a task manager prototype — compare Node.js/Express vs Next.js for speed of prototyping, Bull queue vs cron for email reminders"

実行内容: エージェントが以下を実行します：

候補スタックをプロトタイピング速度、エコシステムの成熟度、統合の複雑さの観点から比較します
メールリマインダー用のBullキューとcronを比較し、キューの永続性とリトライ動作のトレードオフを明らかにします
選定スタックの統合上の注意点を含むランク付きの推奨事項を返します
クライアントドキュメントから抽出された要件に基づき、ブレインストームのスタック推奨を確認または異議を唱えます

ステップ3：デザインスタイルを選択する

/sk:ui-ux-pro-max "personal task manager SaaS — recommend style, color palette, and typography for a professional prototype"

実行内容: エージェントが以下を実行します：

デザインデータベースを照会します — 50以上のスタイル、161のカラーパレット、57のフォントペアリング — プロダクトタイプでフィルタリング
統一されたスタイルの方向性を推奨します（例：SaaSカラーパレットとクリーンなフォントペアリングによるミニマリズム）
具体的なデザイントークンを出力します：プライマリ/セカンダリカラー、フォントスタック、スペーシングスケール、コンポーネントスタイルガイドライン
このコンテキストは /sk:cook に引き継がれ、実装エージェントがデフォルトスタイルではなくこれらの選択を適用します

ステップ4：プロジェクトをスキャフォールドする

/sk:bootstrap "personal task manager: Next.js, PostgreSQL, Prisma, NextAuth for user auth, task CRUD with deadlines and priorities, Bull queue for email reminders, dashboard page"

実行内容: エージェントが以下を実行します：

機能リストに合ったフォルダ構造、ルートスタブ、データベーススキーマを生成します
Next.js、Prisma、NextAuth、Bull、およびすべての必要な依存パッケージをインストール・設定します
.env.example、ローカルPostgres用の docker-compose.yml、Prismaマイグレーションを作成します
ロジックを1行書く前にスキャフォールドが正常にコンパイルされることを確認するため、初回の型チェックを実行します

ステップ5：各機能を計画する

/sk:plan "Feature 1: user auth + task CRUD. Feature 2: email reminders with Bull queue. Feature 3: dashboard with task statistics"

実行内容: エージェントが以下を実行します：

スキャフォールドされたコードベースを読み取り、機能を生成されたファイル構造にマッピングします
plans/ 配下に機能ごとのフォーカスされたフェーズファイルを作成します（各ファイルにタスク、受け入れ基準、ファイルオーナーシップを記載）
機能間の依存関係を解決します（認証はタスクより前に、タスクはダッシュボードより前に完了する必要がある）
/sk:cook がパスごとに狭く曖昧さのないスコープを持てるよう、各フェーズファイルをコンパクトに保ちます

ステップ6：機能ごとに実装する

/sk:cook plans/{timestamp}-personal-task-manager/phase-01-auth-tasks.md

phase-02-email-reminders.md と phase-03-dashboard.md についても繰り返します。

実行内容: エージェントが以下を実行します：

フェーズファイルを読み取り、依存関係の順序に従って各タスクを実装します
機能のサービスロジック、APIルート、データベースクエリ、UIコンポーネントを記述します
ファイルごとに型チェックとリンティングを実行し、エラーが複合する前に検出します
変更されたファイルの一覧と計画からの逸脱があれば、完了報告と共に出力します

ステップ7：プロトタイプスコープのコードレビューを行う

/sk:code-review --pending

実行内容: エージェントが以下を実行します：

最後のコミット以降に変更されたすべてのファイルを読み取ります
プロトタイプの視点を適用します — クラッシュ、壊れたルート、デモを妨げるバグを優先します
デモに影響しない限り、本番環境の懸念事項（レート制限、ページネーションのデフォルト、完全なテストカバレッジ）はスキップします
デモへの影響でソートされた、修正推奨付きの優先度付き問題リストを出力します

ステップ8：プロトタイプのベースラインをコミットする

/sk:git cm

実行内容: エージェントが以下を実行します：

.gitignore を尊重しながらすべての変更ファイルをステージングします（.env は自動的に除外）
プロトタイプの状態を要約するコンベンショナルコミットメッセージを作成します
クライアントフィードバックの反復のためにブランチを切ることができるベースラインコミットを作成します

完全な例：月曜日のデモに向けたタスクマネージャープロトタイプ

シナリオ: 月曜日の朝、クライアントから個人タスク管理アプリの要件仕様書（PDF）、機能リスト（スプレッドシート）、画面モックアップ（Figmaエクスポート）が届きました。水曜日に動作するデモを見たいとのことです。ファイルを ./docs/client-brief/ に配置して開始します。

月曜日の朝に実行するコマンド:

# 1. クライアントドキュメントをブレインストームに渡す — すべてを読み取りギャップを埋めます
/sk:brainstorm "read ./docs/client-brief/ — this contains the client's requirement spec, feature list, and screen mockups for a personal task manager. Brainstorm what's missing, suggest the fastest stack for a 3-day prototype, and flag any scope risks"

# 2. スタックの推奨事項を検証する
/sk:research "best lightweight stack for a task manager prototype — compare Node.js/Express vs Next.js for speed of prototyping, Bull queue vs cron for email reminders"

# 3. スキャフォールドの前にデザインスタイルを選ぶ
/sk:ui-ux-pro-max "personal task manager SaaS — recommend style, color palette, and typography for a professional prototype"

# 4. 確認済みのスタックでスキャフォールドする
/sk:bootstrap "personal task manager: Next.js, PostgreSQL, Prisma, NextAuth for user auth, task CRUD with deadlines and priorities, Bull queue for email reminders, dashboard page"

# 5. 各機能を独立したフェーズとして計画する
/sk:plan "Feature 1: user auth + task CRUD. Feature 2: email reminders with Bull queue. Feature 3: dashboard with task statistics"

# 6. 機能ごとに実装する
/sk:cook plans/{timestamp}-personal-task-manager/phase-01-auth-tasks.md
/sk:cook plans/{timestamp}-personal-task-manager/phase-02-email-reminders.md
/sk:cook plans/{timestamp}-personal-task-manager/phase-03-dashboard.md

# 7. プロトタイプスコープのレビュー — クラッシュとデモを妨げる問題のみ
/sk:code-review --pending

# 8. ベースラインをコミットする
/sk:git cm

結果: 月曜日の午後には、ローカルで動作するプロトタイプが完成しています — ログイン、期限と優先度付きのタスク作成、リマインダーメールを配信するBullキュー、タスク統計を表示するダッシュボード。すべての機能はクライアントのドキュメントに遡ることができます。水曜日のデモまで丸2日、クライアントのフィードバックに対応する余裕があります。

時間比較

タスク	手動	Sun Agent Kit使用
要件分析 + スタック選定	2〜4時間	数分
デザインスタイル選定	1〜2時間	数分
プロジェクトスキャフォールディング + 設定	1〜2時間	数分
機能ごとの実装（3機能）	1〜2日	1〜3時間
コードレビュー	30〜60分	数分
合計	2〜3日	2〜4時間

ベストプラクティス

1. ブレインストーム時にプロトタイプのスコープを明示する ✅

エージェントに「デモ用」であることを伝えてください。「本番用」ではなく。ブレインストームのステップはその境界を引くために存在します — スキャフォールドが構築される前に、期限に収まらない機能を排除するために使用してください。

2. スキャフォールド前にデザインスタイルを選択する ✅

ブレインストームがプロダクトタイプを確認した後に /sk:ui-ux-pro-max を実行してください。スタイル、カラーパレット、タイポグラフィの選択は各 /sk:cook サイクルに引き継がれます — 事前に選択することで「デフォルトTailwindの汎用的な見た目」のプロトタイプを防ぎます。

3. 機能ごとのplan + cookサイクルを使用する ✅

スコープが定まっていないコードベースに対して1回の巨大なcookを実行すると、焦点の定まらない出力が生まれます。実装エージェントがパスごとに狭く、レビュー可能なスコープを持てるよう、各フェーズファイルを単一の機能に絞り込んでください。

4. code-reviewにプロトタイプのコンテキストを伝える ✅

レビュー時にコンテキストを渡してください：「これはクライアントデモ用のプロトタイプであり、本番コードではありません」。レビュアーエージェントはそれに合わせて視点を調整します — クラッシュレベルのバグを優先し、本番への強化は後回しにします。

5. ブレインストームの前にすべてのクライアントドキュメントを1つのフォルダに入れる ✅

要件仕様書、機能リスト、画面モックアップ、会議メモを1つのディレクトリ（例：./docs/client-brief/）にまとめてください。ブレインストームエージェントはパス内のすべてを読み取ります — マシン上に散らばったファイルは要件の見落としを意味します。

6. クライアントドキュメントを読まずにブレインストームをスキップしてブートストラップする ❌

/sk:bootstrap "build a task app" はクライアントの実際の要件に合わない汎用的なスケルトンを生成します。まずクライアントのドキュメントを /sk:brainstorm に渡してください — クライアントが書いたものを抽出し、不足を特定し、エビデンスに基づいた機能リストを作成します。

7. プロトタイプを本番グレードに磨き上げる ❌

レート制限、完全なテストカバレッジ、ページネーションのデフォルト、i18nはプロトタイプスプリントには不要です。その作業はクライアントが承認した後の新しいプロジェクトを開始に属します。

トラブルシューティング

問題：ブートストラップが間違ったスタックを選択する

解決方法: ブレインストームエージェントがクライアントドキュメントから十分な詳細を抽出できていない可能性があります。より厳格な制約を設けて /sk:brainstorm を再実行してください — 特定のファイルを指定: "read ./docs/client-brief/tech-requirements.pdf and pick a stack that matches the client's existing infrastructure"。その後、確認済みのスタックで /sk:bootstrap を再実行してください。

問題：計画が機能フェーズごとに多すぎるタスクを生成する

解決方法: 計画プロンプトの機能スコープが広すぎます。単一の垂直スライスに絞り込んでください: /sk:plan "Feature 1: NextAuth email/password login and Prisma user table only"。3つの機能をまとめて1つのプロンプトに記載するのではなく、各機能に対して個別に /sk:plan を実行してください。

問題：Cookが計画から逸脱する

解決方法: 欲しいものをテキストで説明するのではなく、常に明示的なフェーズファイルパスをcookに渡してください。/sk:cook plans/{timestamp}-personal-task-manager/phase-01-auth-tasks.md はエージェントを書かれた仕様に基づかせます。テキストプロンプトは解釈のズレを引き起こします。

問題：コードレビューがプロトタイプには多すぎる問題を指摘する

解決方法: コマンドでコンテキストを伝えてください: /sk:code-review --pending "this is a prototype for a client demo — flag crashes and broken routes only, defer production hardening"。レビュアーエージェントは記載された目的に合わせて基準を調整します。

問題：cookを使ったのにプロトタイプのUIが汎用的に見える

解決方法: デザインスタイル選択のステップをスキップしました。次の /sk:cook サイクルの前に、プロダクトタイプを指定して /sk:ui-ux-pro-max を実行してください — 50以上のスタイルと161のカラーパレットを照会し、統一されたデザインの方向性を推奨します。実装エージェントはこれらの選択を自動的に適用します。

次のステップ

クライアントアップセール提案 — プロトタイプの関与をより長期の契約に発展させる
プロジェクトマイグレーション — プロトタイプを本番スタックに移行する必要がある場合
新しいプロジェクトを開始 — プロトタイプ段階を過ぎた後の本格的な本番への道筋
新機能を追加 — プロトタイプに追加機能を加える

要点: 頭の中の要約ではなく、クライアント自身のドキュメントから始めましょう — /sk:brainstorm がファイルを読み取り、要件を抽出し、ギャップを埋めます。/sk:ui-ux-pro-max がビジュアルの方向性を設定します。/sk:bootstrap でスキャフォールドし、機能ごとの /sk:plan + /sk:cook サイクルでクライアントとのミーティング前に完成させます。