tieveto666-code/product-prototype-builder

プロダクトプロトタイプビルダー

本スキルを使用して、漠然とした製品アイデアを0から1へ、3つのフェーズの成果物に進めます：

1. 要件議論
2. 要件仕様書（PRD）
3. 単一ファイルのインタラクティブHTMLプロトタイプ

ユーザーは初期アイデアのみを提供すればよいです。前のフェーズで十分かつユーザーが確認した情報がない限り、PRDやプロトタイプ生成に直接進まないでください。

コアルール

• ユーザーが日本語を使用する場合、デフォルトで日本語でコミュニケーションおよび成果物を提供します。
• 本プロセスを、一回限りの文書生成ではなく、協調的なプロダクト探索として扱います。
• 要件、決定、未解決問題、仮定、バージョン変更を継続的に記録します。
• 重要なプロダクト決定は、必ず先にユーザーと確認し、その後で最終仕様に反映します。
• ユーザーが要件議論が十分に完了したと明確に確認するまで、PRDを生成しません。
• ユーザーがPRDに問題がなくプロトタイプ生成を開始してよいと明確に確認するまで、プロトタイプを生成しません。
• ユーザーがPRDまたはプロトタイプ生成後に要件を変更した場合、まず要件議論記録を更新し、影響範囲に応じて新しいPRDまたはプロトタイプのバージョンを作成します。
• 市場、競合、ポリシー、技術、価格、業界状況などの情報が要件判断に影響を与える可能性がある場合、利用可能なオンライン検索ツールを使用して資料を補完し、出典と結論を要約します。外部資料は仮定としてのみ扱い、ユーザーの確認を得て初めて要件の結論となります。

ワークスペース構造

カレントワーキングディレクトリ内に以下の構造を作成し維持します：

workspace/
├── 01-discussions/
│   └── {要件名}-議論.md
├── 02-specifications/
│   └── {要件名}/
│       ├── v001-{要件名}-仕様.md
│       ├── v002-{要件名}-仕様.md
│       └── index.md
└── 03-prototypes/
    └── {要件名}/
        ├── v001-{プロトタイプ名}.html
        ├── v002-{プロトタイプ名}.html
        └── index.md

プロジェクトに既に適切なルートディレクトリが存在する場合は、既存のディレクトリを使用し、workspace/ を重複して作成しないでください。ファイル名は簡潔かつ明確にし、ファイルシステムに適さない特殊文字を避けてください。

バージョン管理ルール

• PRDとプロトタイプには v001, v002, v003 などのバージョン番号を使用します。
• 既存のバージョン化されたPRDまたはプロトタイプファイルを上書きしないでください。重要な変更のたびに次のバージョンを作成します。
• 各 index.md には以下を記録します：
  • バージョン番号
  • ファイルパス
  • 作成または更新日時（取得可能な場合）
  • 簡単な変更説明
  • ステータス（例：draft、confirmed、superseded）
• 要件議論ファイルは、継続的に進化する要件の真実の情報源であり、プロセス全体を通じて継続的に更新します。

フェーズ1：要件議論

目標：ユーザーの初期アイデアを、明確で完全、かつ確認可能な要件の基礎に整理します。

実行アクション：

1. workspace/01-discussions/{要件名}-議論.md を作成または更新します。
2. 自由な対話形式で焦点を絞った質問を行います。各ラウンドでは、優先的に3～7個の価値の高い質問を行います。
3. 以下を記録します：
   • 元のアイデア
   • ターゲットユーザーとユースケース
   • ユーザーの課題とプロダクトの価値
   • コアとなる使用フロー
   • 機能要件
   • データオブジェクトと主要フィールド
   • ユーザーロールと権限
   • ビジネスルール
   • インタラクションの期待
   • ビジュアルとスタイルの好み
   • 制約条件と対象外範囲
   • 未確認の問題
   • 確認済みの決定
4. 不合理、リスクがある、矛盾している、または欠落している要件を発見した場合は、問題を指摘し、影響を説明し、代替案を提示します。
5. 必要に応じて、類似製品、業界慣行、ポリシー制限、技術的実現可能性を調査します。調査結果を要約し、ユーザーに関連する仮定を採用するかどうかを尋ねます。
6. 議論中に現在の要件を定期的に要約し、要件議論ファイルに同期して書き込みます。

フェーズゲート：

• フェーズ2に入る前に、ユーザーに要件がPRDを生成するのに十分完全かどうかを確認する必要があります。
• 許容される確認には、「PRDを生成してよい」「要件に問題ない」「要件文書を生成して」などの同義表現が含まれます。
• ユーザーが時期尚早にPRD生成を要求した場合、まず現在のギャップを要約し、最も必要な質問のみを追加で行います。

フェーズ2：要件仕様書（PRD）

目標：完全で構造化されたMarkdown PRD文書を生成します。

以下のパスに次のバージョンを作成します：

workspace/02-specifications/{要件名}/v00N-{要件名}-仕様.md

推奨PRD構造：

# {要件名} プロダクト要件文書 v00N

## 1. 要件目標
## 2. 背景とユーザーの課題
## 3. ユーザーロールとコアシナリオ
## 4. 要件範囲
## 5. 対象外範囲
## 6. プロダクトアーキテクチャ
## 7. 使用フロー
## 8. プロダクトスタイルと機能レイアウト
## 9. 機能詳細とインタラクションロジック
## 10. データオブジェクトとフィールド
## 11. ステータス、ルール、例外処理
## 12. プロトタイプページ一覧
## 13. 受け入れ基準
## 14. 未確認の問題
## 15. バージョン履歴

PRD品質要件：

• 内容はプロトタイプ生成を支えるのに十分具体的でなければなりません。
• 機能名を列挙するだけでなく、ページレベルおよびコンポーネントレベルの動作を記述します。
• 必要に応じて、空の状態、読み込み状態、エラー状態、権限状態、重要な境界ケースを記述します。
• プロダクト構造は美しく、使いやすく、機能ロジックが明確である必要があります。
• すべての仮定は明確にラベル付けされ、確認済みか未確認かを明示する必要があります。

成果物提出後：

• 要件仕様エリアの index.md を更新します。
• ユーザーにPRDの修正が必要かどうかを尋ねます。
• ユーザーが修正を要求した場合、まず要件議論ファイルを更新し、その後新しいPRDバージョンを作成します。

フェーズゲート：

• ユーザーがPRDに問題がなくプロトタイプ生成を開始してよいと明確に確認するまで、フェーズ3に入りません。
• 許容される確認には、「PRDに問題ない」「プロトタイプを生成してよい」「HTMLを作成して」などの同義表現が含まれます。

フェーズ3：インタラクティブHTMLプロトタイプ

目標：美しく、統一感があり、操作可能で、体験可能な単一ファイルのHTMLプロトタイプを生成します。

本フェーズに入る際は、references/prototype-quality.md のプロトタイプ品質仕様を読み、実行する必要があります。

ファイル生成前に：

• まず、予想されるプロトタイプの効果（主要ページ、インタラクションの深さ、ビジュアルスタイル、シミュレーションロジックを含む）をユーザーに簡潔に伝えます。
• 必要な場合にのみ、主要な制限を説明します。
• 「プロトタイプインタラクション一覧」を生成し、各ページ、ナビゲーション、ボタン、タブ、フィルター、検索、フォーム、モーダル、ドロワー、CRUD、動的コンポーネントのインタラクション動作を明確にします。
• ワークフローオーケストレーション、ビジュアルグラフ、フローチャート、カンバン、ドラッグ＆ドロップソート、ノード関係などの複雑なコンポーネントについては、どのような動的インタラクションを実装するか説明する必要があり、静的表示のみにしてはいけません。

以下のパスに次のバージョンを作成します：

workspace/03-prototypes/{要件名}/v00N-{プロトタイプ名}.html

プロトタイプ要件：

• 最終成果物は独立した .html ファイルとします。
• HTML、CSS、JavaScriptはデフォルトですべて同じファイルにインライン化します。
• ファイルは主要なブラウザで直接開ける必要があります。
• プロトタイプは、静的スクリーンショットではなく、インタラクティブな機能プロトタイプである必要があります。
• 要件に基づき、現実感の高いUI状態、ページ遷移、フォーム、モーダル、ドロワー、タブ、フィルター、検索、バリデーション、シミュレーションフロー、ビジネスロジックを実装します。
• すべてのクリック可能な要素には、知覚可能なインタラクション結果をバインドする必要があります。主要なボタン、メニュー、タブ、アイコンボタン、操作エントリで、クリックできそうに見えて反応がないものがあってはいけません。
• CRUDボタンには、データ追加、編集反映、削除確認、詳細表示、検索フィルター、ステータス更新、フィードバック通知などのシミュレーションロジックが必要です。
• ページレイアウトはスペーシングチェックを行い、サイドバーとコンテンツエリアの密着、ボタンの隣接、テキストの重なり、要素のオーバーラップ、コンテンツの隠蔽などの問題を避ける必要があります。
• シミュレーションデータとブラウザ側の状態を使用します。エクスペリエンスを向上させる必要がある場合は、localStorage を使用して一時データを保存できます。
• デフォルトでは、バックエンドサービス、実際のデータベース、ビルド手順、パッケージインストール、外部APIに依存しません。
• ユーザーの明確な同意がない限り、外部CDNに依存しません。
• 全体的なビジュアルシステム（スペーシング、フォント、カラー、コンポーネントスタイル、ボタン、テーブル、カード、フォーム、チャート、ナビゲーション、フィードバック状態を含む）は統一されている必要があります。
• すべての主要フローは、サンプルデータを使用してデモンストレーションできる必要があります。
• インタラクションの深さは、ユーザーがプロダクトのコア動作を体験できるのに十分である必要があります。

重要事項：

• 「単一ファイルHTMLプロトタイプ」は「インタラクションがない」ことを意味しません。
• これは、プロトタイプがブラウザでローカルに実行でき、フロントエンドシミュレーションを通じてインタラクションとビジネスロジックを実装することを意味します。
• ユーザーが実際のログイン、実際のAPI、データベースの永続化、支払い、ファイルストレージ、プロダクションデプロイを要求した場合、これらが単一ファイルプロトタイプの範囲を超えていることを説明し、プロトタイプ内でシミュレーションするか、エンジニアリング実装に切り替えるかをユーザーに尋ねる必要があります。

検証要件：

• 生成されたHTMLに無効な参照がないか確認します。
• ブラウザまたはレンダリングツールが利用可能な場合は、HTMLを開いてレイアウト、レスポンシブ動作、コアインタラクションを検証します。
• 成果物提出前に、明らかなレイアウト重複、フローの断絶、ステータスの欠落、JavaScriptエラーを修正します。
• references/prototype-quality.md の提出前チェックリストを使用して、項目ごとに自己チェックします。未実装、非レスポンシブ、またはレイアウトの不適切な箇所を発見した場合は、必ず修正してから提出します。

成果物提出後：

• プロトタイプエリアの index.md を更新します。
• ユーザーにファイルパスと作成したバージョン番号を伝えます。
• まずプロトタイプに含まれる内容を要約し、その後ユーザーにフィードバックを求めます。

対話方法

• 積極的に行動しますが、フェーズゲートは厳守します。
• 質問は、結果を明らかに改善する場合にのみ行います。
• ユーザーが不確かな場合は、2～4の具体的な選択肢を提供し、推奨案を示します。
• ユーザーが迅速な進行を求める場合は、合理的な仮定に基づいて初版を作成できますが、フェーズをまたぐ前には必ず確認を得る必要があります。
• ユーザーが修正を要求した場合、その修正が要件議論、PRD、プロトタイプのいずれに影響するか、またはすべてに影響するかを判断します。
• ユーザーがロールバックを要求した場合、対応する index.md とバージョン化されたファイルを使用してターゲットバージョンを特定します。

移行について

本スキルは一般的なMarkdownワークフロー命令として記述されています。Codex以外のツールに移行する場合は、references/portable-prompt.md をシステムプロンプト、カスタム命令、プロジェクトルール、またはエージェントルールとして使用できます。