mingdui/AI-Product-Skills

プロダクトマネージャー向けフロントエンド高忠実度プロトタイプ Skill

一、目標

既存のフロントエンドプロジェクトのソースコード上に、高忠実度でクリック可能、かつ本番の業務エントリから隔離されたプロトタイプを作成します。これにより、プロダクトマネージャーが迅速に製品案を確認、デモ、議論できるようにします。

優先的に保証すること：

• 既存プロジェクトのスタイルとの一貫性。
• 一時的なデモではなく、実際の製品のように見えるページ。
• 業務に則したモックデータの使用。
• コアフローがクリック可能であること。
• インタラクションが要件レビューに使用できること。
• ページが容易に修正可能であること。
• ローカルですぐに実行・プレビュー可能であること。
• デフォルトで使用中の業務ページやルートに影響を与えないこと。

ユーザーが明示的に要求しない限り、タスクをシステム全体のゼロからの再構築として扱わないでください。

現在の目標が高忠実度プロトタイプである場合、バックエンドAPI、本番データリンク、複雑なアーキテクチャの開発を優先しないでください。

デフォルトの隔離ルール： まず既存プロジェクトのソースコード、レイアウト、コンポーネント、ビジュアルルールを再利用し、その後、独立したプロトタイプページ、ルート、または機能ディレクトリで実装します。デフォルトで、使用中の業務ページ、本番エントリ、既存のAPI呼び出しを変更してはなりません。ユーザーが明確に「元のページで直接デモする」または「プロトタイプを既存ページに上書きする」と要求した場合のみ、これを行うことができます。

---

二、適用シナリオ

ユーザーが以下のような要求をした場合に、このスキルを使用します：

• 既存のReact、Vue、HTML、またはその他のフロントエンドプロジェクトのソースコードを基に、独立したプロトタイプページまたはルートを作成する。
• ユーザーが明示的に要求した場合、既存の製品ページ内でプロトタイプのインタラクションをデモする。
• 管理画面ページ、CRMページ、SaaSページ、運用管理画面、または業務ワークベンチを追加する。
• 静的ページをクリック可能なプロトタイプに変更する。
• リアリティのあるモックデータやインタラクション状態を追加する。
• テーブル、フォーム、フィルター、タブ、ドロワー、モーダル、チャート、詳細ページ、または業務フローを追加・最適化する。
• 既存プロジェクトのスタイルに従って新機能を拡張する。
• バックエンドを開発せずに、まずレビュー用の高忠実度デモを完成させる。
• ビジュアル階層、情報密度、レスポンシブ対応、インタラクションフィードバックを最適化する。

よくある表現：

• 既存の管理画面に顧客一覧ページを追加する。
• 現在のプロジェクトスタイルに合わせて、経営データダッシュボードを追加する。
• 既存の詳細ページにフォローアップ記録モジュールを追加する。
• このページをクリック可能なプロトタイプに仕上げる。
• 検索、フィルター、ステータス切り替え、ドロワー、モーダルのインタラクションを追加する。
• この既存ページを最適化するが、システム全体のスタイルは変更しない。

---

三、非適用シナリオ

以下の場合、このスキルはデフォルトで使用しません：

• ユーザーが空のディレクトリから全く新しいプロダクトを作成したい場合。
• ユーザーがマーケティング用のコーポレートサイトやランディングページのみを必要としている場合。
• ユーザーがバックエンドAPI、データベース、または本番サービスの開発を要求する場合。
• ユーザーがプロトタイプではなく、技術アーキテクチャのドキュメントを必要としている場合。
• ユーザーがビジュアルイメージや静的なスクリーンショットの生成のみを要求する場合。
• 現在のタスクが主に要件分析やPRD作成である場合。

現在のディレクトリが空の場合は、このスキルが主に既存プロジェクト向けであることを説明し、「ゼロからHTML高忠実度プロトタイプ Skill」を優先的に使用します。

---

四、核心原則

1. プロジェクトを確認してから設計を始める

要件を受け取ったら、すぐにコードを書き始めないでください。

まず docs/product/ 内に、現在のプロジェクトおよび現在のエンド（c-end/ または admin/）に対応する製品エクスペリエンスベースラインが存在するか確認します。ベースラインが存在する場合は、その中の製品用語、ナビゲーション、ページパターン、ビジュアルおよびインタラクションルールを読み込みます。これはプロジェクトのソースコードに関する技術的な取り決めを補完するものであり、コンポーネントライブラリ、ルーティング、データアーキテクチャに取って代わるものではありません。

ユーザーが初版要件を開始している場合、または現在の機能がページをまたいで繰り返し現れるがまだ定義されていないプロダクトルールを露呈している場合は、まず product-experience-foundation を使用することを提案します。通常の単一機能プロトタイプは、グローバルなプロダクトベースラインを勝手に作成したり書き換えたりしてはいけません。

まず既存プロジェクト内の以下を確認します：

• 隣接するページ。
• ページレイアウトフレームワーク。
• ルーティング構造。
• コンポーネントディレクトリ。
• 共通フックとユーティリティ関数。
• CSS変数。
• テーマファイル。
• デザイントークン。
• アイコンの使用法。
• テーブルスタイル。
• フォームスタイル。
• モーダルとドロワーのスタイル。
• メッセージと通知のスタイル。
• 現在の状態管理の方法。

既存プロジェクトの以下を理解する必要があります：

• 情報密度。
• ページの余白。
• フォント階層。
• 角の丸みのサイズ。
• 色の使用方法。
• ナビゲーション構造。
• コンポーネントの呼び出し方。
• レスポンシブ戦略。

追加コンテンツは、システム全体を再作成するのではなく、既存システムから自然に拡張されたように見えるべきです。

2. 再利用を優先し、車輪の再発明をしない

プロジェクトに既存のものを優先的に再利用します：

• ボタン。
• テーブル。
• フォーム。
• ドロップダウン。
• 日付ピッカー。
• タブ。
• モーダル。
• ドロワー。
• ページネーション。
• ステータスタグ。
• メッセージ通知。
• ページレイアウトコンポーネント。
• アイコン。
• ユーティリティ関数。
• フック。
• デザイントークン。

既存プロジェクトがすでに相当する機能を備えている場合、第二のコンポーネントシステムを新たに作成しないでください。

3. デフォルトでプロトタイプエントリを隔離する

プロトタイプは、プロジェクトから切り離された静的サイトをコピーして作成するのではなく、既存のソースコードに基づいて実装する必要があります。同時に、デフォルトで本番の業務エントリから隔離します。

プロジェクトの既存のルールでサポートされている以下の方法のいずれかを優先的に選択します：

• 独立したプロトタイプルート（例：/__prototype/<feature> またはプロジェクトに既存のデモルートルール）。
• 独立したプロトタイプページまたは機能ディレクトリ。エントリは開発/プレビュー環境でのみ公開します。
• 元のページのデフォルト動作を変更しない明示的なプロトタイプエントリ（例：クエリパラメータ、開発メニュー、一時的なナビゲーション項目）。

プロトタイプエントリは、実際のページシェルとコンポーネントを再利用できなければなりませんが、デフォルトでオンラインエントリを置き換えたり、既存の業務データを変更したり、他の機能に影響を与えたりしてはいけません。プロジェクトにプロトタイプのルールが既に存在する場合は、それを優先的に遵守する必要があります。ルールがない場合は、本番コードへの影響が最小限で、かつ削除が容易な方法を選択し、最終的な返信でエントリの場所を説明します。

4. タスクを製品プロトタイプとして扱い、本格的なリファクタリングとして扱わない

以下を優先します：

• 製品レビュー。
• 業務デモ。
• 要件議論。
• 設計と開発の調整。
• 迅速なイテレーション。

直接的で修正が容易な実装方法を優先的に使用します。

既存プロジェクト自体がすでに該当するパターンを採用している場合を除き、以下を導入しないでください：

• 大規模なグローバルリファクタリング。
• 新しいアーキテクチャ層。
• 重量級の依存関係。
• 過度な抽象化。
• 複雑なステートマシン。

5. モックデータを使用し、バックエンド開発を急がない

ユーザーが明示的に要求しない限り、以下を行わないでください：

• 実際のAPIに接続する。
• バックエンドAPIを設計する。
• サービス層を作成する。
• 本番データリンクを処理する。

モックデータは、プロダクトマネージャーが調整しやすいように、ページまたは現在の機能の近くに配置するようにします。

ローカル状態を使用して以下をシミュレートします：

• 追加。
• 編集。
• 削除。
• 検索。
• フィルター。
• ソート。
• タブ切り替え。
• 選択。
• ステータス変更。
• ドロワーを開く。
• モーダルを開く。
• フォーム送信。
• 確認ダイアログ。
• 成功通知。
• エラー通知。

6. プロトタイプはクリック可能でなければならない

コアメインフローに加えて、要件に応じてプロダクトマネージャーがレビュー時に確認する必要がある状態も補充します：

• 検索。
• フィルター。
• タブ。
• 選択。
• 詳細表示。
• 空の状態。
• ローディング状態。
• フォームバリデーション。
• 無効状態。
• 確認ダイアログ。
• 成功フィードバック。
• エラーフィードバック。
• 戻るパス。
• マルチステップナビゲーション。

要件に複数のステップが含まれる場合、フローが完全にジャンプできるようにし、相互に関連のない複数の静的ページを残さないようにします。

7. 業務システムをマーケティング用コーポレートサイトにしない

ユーザーがアプリケーション、ツール、管理画面、CRM、運用システム、業務ワークベンチを必要とする場合：

• 巨大なファーストビューのタイトルを作成しない。
• マーケティング用のビジュアル構成を優先しない。
• 大量の装飾的なグラデーションや背景をメインビジュアルとして使用しない。
• 視覚効果のために情報密度を大幅に低下させない。
• 実際の業務コントロールの代わりにマーケティングカードを使用しない。

---

五、コーディング前に完了すべき分析

コードを書き始める前に、要件とプロジェクトから以下を抽出します：

• プロダクト目標。
• ターゲットユーザーまたはロール。
• ユーザーが達成すべきコアタスク。
• 新規追加または変更が必要なページ。
• 既存の類似ページ。
• ページエントリ。
• 主要なユーザーフロー。
• 必須フィールド。
• 必須ステータス。
• ロールごとの権限の違い。
• 必須のインタラクション。
• モックデータの要件。
• プロダクトの仮定。
• 未確定の業務ルール。

ユーザーがすでに提供した情報を繰り返し質問しないでください。

表示レイヤーの詳細が不足しているだけの場合は、妥当な仮定を使用できます。

製品範囲を変更するようなコアな業務ルールを勝手に補充してはいけません。

---

六、プロジェクト確認手順

ステップ1：技術スタックの特定

以下を確認します：

• フロントエンドフレームワーク。
• ビルドツール。
• ルーティング方法。
• UIコンポーネントライブラリ。
• アイコンライブラリ。
• スタイル方式。
• 状態管理方法。
• データリクエストのルール。
• テストまたはプレビュー方法。

ステップ2：類似ページの検索

以下を優先的に検索します：

• 同タイプの一覧ページ。
• 同タイプの詳細ページ。
• 同タイプのフォーム。
• 同タイプのデータダッシュボード。
• 同タイプのモーダルまたはドロワー。
• 同タイプの業務フロー。
• 同タイプの空、ローディング、エラー状態。

これらのページを新しいページの実装の参考とします。

ステップ3：再利用可能なコンテンツの特定

今回再利用すべきものをリストアップします：

• コンポーネント。
• フック。
• デザイントークン。
• ユーティリティ関数。
• ページレイアウト。
• インタラクション方法。

既存の機能を重複して実装しないようにします。

ステップ4：既存のビジュアルシステムの理解

以下を確認します：

• ページ幅。
• コンテンツエリアの内側の余白。
• モジュール間の間隔。
• フォント階層。
• ボタンスタイル。
• フォームの密度。
• テーブルの密度。
• ステータスカラー。
• ボーダースタイル。
• シャドウの使用。
• レスポンシブブレークポイント。

ステップ5：プロトタイプ範囲の確定

以下を明確にします：

• プロトタイプエントリをどこに配置するか、および本番エントリとの隔離方法。
• 新規追加が必要なプロトタイプページまたはモジュール。
• ユーザーが既存の業務ページの修正を明示的に要求しているかどうか。
• どのインタラクションをクリック可能にする必要があるか。
• どのデータにモックデータを使用するか。
• どの状態を表現する必要があるか。
• どのプロダクトの仮定が必要か。
• 現在の機能がどの製品レベルのページパターンを再利用しているか。
• どの新しいパターンが現在の機能に限定され、どのパターンが後続の昇格候補となるか。

---

七、モックデータ標準

モックデータは実際の業務言語を使用する必要があります。

以下は避けます：

• Test User。
• Lorem ipsum。
• Company A。
• Sample Data。
• User 001。

モックデータは可能な限り以下をカバーするようにします：

• 異なるステータス。
• 長いテキスト。
• 欠損値。
• 警告情報。
• 境界データ。
• 異なるユーザーの意思決定。
• 異なる業務段階。
• 空の結果。
• 無効な操作。

モックデータの役割はページを埋めることではなく、プロダクトマネージャーがページとインタラクションの問題を発見するのを助けることです。

---

八、プロダクト仮定のルール

AIは表示レイヤーの詳細を合理的に補完できます。例：

• サンプル名。
• サンプル日付。
• サンプルリストデータ。
• 空の状態のテキスト。
• 成功およびエラー通知。
• 一般的なフィルター条件。
• 既存プロジェクトの習慣に合ったインタラクション方法。

AIは以下のコアな業務ロジックを黙って補完してはいけません：

• 新しい業務ステータス。
• 新しいロール権限。
• 新しい承認ルール。
• 新しい業務計算方法。
• 新しい管理モジュール。
• 新しい製品範囲。
• 新しい外部システム依存。

デモのために仮定が必要な場合は、最終的な返信で集中的に説明する必要があります。

新しいインタラクションが製品エクスペリエンスベースラインと競合する場合、黙って上書きしないでください。確認済みのベースラインに従うか、逸脱の理由と「ベースラインに書き戻す必要があるか」を確認待ち項目としてリストアップする必要があります。

---

九、UI とインタラクション標準

1. 情報アーキテクチャ

以下を優先的に保証します：

• 階層が明確。
• グループ化が適切。
• フィールド選択が効果的。
• 主要な操作が明確。
• 情報密度が安定。
• ページがスキャンしやすい。

2. コントロールの選択

ユーザーが使い慣れたコントロールを優先的に使用します：

• ツール操作にはアイコンボタン。
• モード切り替えにはセグメントコントロール。
• 二値設定にはスイッチまたはチェックボックス。
• 数値設定には入力ボックス、スライダー、またはステッパー。
• 複数選択肢にはメニューまたはドロップダウン。
• 同階層ビューにはタブ。
• セカンダリタスクにはドロワーまたはモーダル。

3. カードの使用

カードの入れ子は避けてください。

カードは以下に適しています：

• 繰り返されるリスト項目。
• モーダル。
• ドロワー。
• 独立したツール。
• 明確に枠付けする必要があるデータグループ。

ページのすべてのブロックをカードで包まないでください。

4. 装飾の制御

以下を避けます：

• 装飾的なグラデーションの光の塊。
• 浮遊する球体。
• ボケ効果。
• 無意味なSVG装飾。
• 純粋な雰囲気背景。
• マーケティング用ファーストビュー。
• 単一色調でページを埋め尽くす。

実装後にCSSを確認し、ページがほぼ一つの色系統のみになっている場合は、適切に調整する必要があります。

特に以下を避けるように注意します：

• 広範囲の紫または青紫のグラデーション。
• 広範囲のベージュまたは砂色。
• 広範囲の濃い青または灰青。
• 広範囲の茶色またはオレンジ色。

5. テキストとレイアウトの安定性

テキストが以下に適応できることを確認します：

• ボタン。
• テーブルセル。
• カード。
• サイドバー。
• ドロワー。
• モーダル。
• モバイル端末のコンテナ。

必要に応じて以下を使用します：

• 自動改行。
• テキスト切り詰め。
• 最小および最大幅。
• 安定したグリッド。
• aspect-ratio。
• コンテナ相対サイズ。

ビューポート幅に応じてフォントサイズを動的にスケーリングしないでください。

既存のデザインシステムが要求しない限り、文字間隔は 0 に保ちます。

6. 製品インターフェース内でプロトタイプを説明しない

ページ内に以下の説明を表示しないでください：

• このプロトタイプがどのように作られたか。
• どのような一時的な方法が使用されたか。
• レビュアーがページをどのように理解すべきか。
• どのインタラクションがシミュレートされているか。

製品自体が本当にヘルプコンテンツを必要とする場合にのみ、インターフェース内に説明を追加します。

---

十、レスポンシブ範囲

デスクトップ管理システム

プロジェクトが明らかにデスクトップ管理システムの場合：

• デスクトップ版を優先的に作り込む。
• 安定した情報密度を維持する。
• 小画面で完全に崩れないことを確認する。
• 重要な操作にアクセスできなくならないようにする。
• 不必要な横スクロールを可能な限り避ける。

モバイルまたはコンシューマー製品

製品がコンシューマー向け、モバイルファースト、またはユーザーが明示的にモバイル対応を要求する場合：

• モバイル版のレイアウトとインタラクションも同様に真剣に設計する。
• タップ領域のサイズを確認する。
• コントロールのクリッピングを確認する。
• 固定位置要素を確認する。
• 安全な余白を確認する。
• 必要に応じてキーボードとフォームの動作を確認する。

すべてのページで確認が必要

• テキストの重なり。
• コントロールのクリッピング。
• 操作エントリの隠蔽。
• ページナビゲーションの途切れ。
• 横方向のはみ出し。
• テーブルが読めない。
• ドロワーまたはモーダルが使用できない。

---

十一、実装手順

ステップ1：既存プロジェクトの読み取り

関連するプロジェクト構造と類似ページを確認します。

ステップ2：プロトタイプエントリと範囲の明確化

以下を整理します：

• プロトタイプページ、ルート、または機能ディレクトリの場所。
• 本番業務エントリとの隔離方法。
• ユーザーが明示的に要求した場合にのみ変更する既存ページまたはモジュール。
• コアユーザーフロー。
• 必須のインタラクション。
• モックデータの状態。
• 再利用可能なコンポーネント。

ステップ3：既存プロジェクトの方法に沿って独立したプロトタイプを実装

以下を維持します：

• 技術フレームワーク。
• コンポーネントシステム。
• スタイル方法。
• ルーティング方法。
• アイコン。
• ユーティリティ関数。
• 状態管理の習慣。

ステップ4：モックデータとインタラクションの追加

ローカル状態を使用して、今回のレビューに必要な完全なフローを実装します。

ステップ5：必要な状態の補充

現在の機能に関連する状態のみを追加します：

• 空の状態。
• ローディング状態。
• バリデーション状態。
• 無効状態。
• 成功状態。
• エラー状態。
• 確認ダイアログ。
• 権限なし状態。
• データ利用不可状態。

ステップ6：プロジェクトの実際の実行

必要に応じて、既存のローカル開発サーバーを起動します。

プロジェクトがプレビューできるようになる前に、タスクが完了したと宣言しないでください。

ステップ7：ビジュアルとインタラクションのチェック

以下を確認します：

• ページが空白でない。
• スタイルが正常に読み込まれている。
• アイコンとリソースが正常に表示されている。
• テキストが明らかに溢れていない。
• レイアウトが異常に跳ねない。
• コアインタラクションが使用できる。
• ナビゲーションに行き止まりがない。
• レスポンシブのパフォーマンスが許容範囲内。

可能であれば、ブラウザのインスペクタやスクリーンショットを使用して確認します。

---

十二、最終デリバラブル

タスクの実際の状況に応じて、最終的に以下を含める必要があります：

• 新規追加または変更されたフロントエンドソースコード。
• 独立したプロトタイプページ、機能ディレクトリ、またはルート、およびエントリの説明。
• ユーザーが明示的に要求した場合にのみ変更された既存の業務ページ。
• 再利用された共通コンポーネント。
• ローカルモックデータ。
• クリック可能なコアインタラクション。
• 関連する空、ローディング、バリデーション、無効、成功、エラー状態。
• 正常に使用可能なページナビゲーション。
• プロジェクトの実行またはプレビューの説明。
• プロダクト仮定の説明。
• 未確定の業務ルールのリスト。
• demo.md を作成した場合、レビュー結果と確認待ち事項を記録します。これは引き継ぎマーカーとしてのみ機能し、プロジェクト自身のエンジニアリング成果物を置き換えるものではありません。

実行やレビューに役立たない限り、大量のドキュメントやアーキテクチャファイルを追加で作成しないでください。

---

十三、完了基準

以下の条件を満たした場合に、プロトタイプは完了と見なされます：

• プロトタイプページまたはモジュールが現在のプロジェクト内に存在し、本番の業務エントリから隔離されている（ユーザーが明示的に元のエントリの上書きを要求した場合を除く）。
• ビジュアルスタイルが既存プロジェクトと一致している。
• 既存のコンポーネントとデザイントークンが適切に再利用されている。
• コアユーザーフローが開始から終了までたどれる。
• すべての主要な操作に明確なフィードバックがある。
• ページナビゲーションに行き止まりがない。
• 重要な操作後にモックデータが更新される。
• 関連するページ状態が表現されている。
• テキストが明らかに溢れていない。
• プロジェクトがローカルで正常に実行でき、ブロッキングエラーがない。
• 確認済みの製品範囲を勝手に拡大していない。
• 最終的な返信で、プロダクト仮定と確認待ちルールが明確に説明されている。

---

十四、最終返信要件

完了後、プロダクトマネージャーが理解しやすい方法で以下を説明します：

• 新規追加または変更されたページ、モジュール、フロー。
• プロトタイプエントリの場所、および本番業務エントリとの隔離方法。
• どのインタラクションがクリック可能になったか。
• 追加されたモックデータとページ状態。
• 再利用された既存のコンポーネントとプロジェクトルール。
• 行われたプロダクト仮定。
• どの業務ルールが未確定か。
• プロトタイプの実行またはプレビュー方法。
• 完了したビジュアルおよびインタラクションチェック。
• 再利用された製品エクスペリエンスベースライン。新しいパターンが繰り返し出現する場合、それが単なる候補であり、確認されるまではグローバルルールとして抽出しないことを説明する。
• レビュー確認後は開発者がプロトタイプに従って実装する。プロトタイプ段階でエンジニアリング成果物を偽造したり、勝手に本番コードを実装したりしない。

最終的な返信は簡潔に、プロダクトマネージャーがレビューする必要がある内容に重点を置く必要があります。