UIUXプロトタイプ
実際のタスクを中心に製品インターフェースを設計します。アプリケーション実装前にレビュー可能なHTMLを提供します。ユーザーの言語で作業し、必要に応じて英語の専門用語を使いながら、説明はデフォルトで中国語を使用します。このスキルは自己完結型です。上位スキルや有料のリファレンスサービスはオプションであり、依存関係ではありません。
1. 製品を確立し、そのベースラインを維持する
該当するAGENTS.md、HANDOFF.md、既存のDESIGN.md、および現在のプロトタイプファイルを最初に読みます。ユーザー、シナリオ、エントリー、メインタスク、結果、ビジネスバリュー、要求された画面、およびこのバージョンの範囲外を特定します。既存のブランド決定や他の人の編集を維持します。日常的な詳細は自分で解決し、デザインを大きく変更する不足情報のみを質問します。
ブリーフから、任意のページ数ではなく、範囲を限定した画面/フローインベントリに合意します。要求された各画面(ウェブ、ミニプログラム、モバイル、デスクトップ)をカバーします。無関係なアプリを発明しないでください。画面範囲が不明でプロジェクトがそれを確定できない場合は、先に進む前に一度質問します。継承されたUIは、監査と上書きしないバージョンを取得します。無断のリデザインは行いません。
source-synthesis.mdの該当する決定ルールセクション(§1–7)を読み、そのソースマップ(§8–10)をトレードオフの説明に使用します。これにより7つのソースリポジトリすべてが統合されます。製品タスクの明確さ、既存のデザイン契約、ユーザーの選択が、ランディングページの慣習、スタイル禁止、ランダムなテーマよりも優先されます。
2. リファレンスを調査し、スタイル決定のためにSTOPする
reference-research.mdを読みます。Dribbbleから始め、フォールバックまたは補足として即时设计とBehanceを使用します。「美しいUI」だけでなく、製品カテゴリ、ユーザータスク、および関連プラットフォームを検索します。利用可能なブラウザ/検索ツールを使用し、実際に検査したページと画像を記録します。検索スニペットをビジュアルレビューと呼んではいけません。アクセス制限を遵守し、実際のケースを表示できない場合は、その旨を報告し、参照資料の提供または調査の明示的な放棄を求めます。
docs/prototype/versions/vX.Y.Z/(またはプロジェクトの確立されたプロトタイプルート)の下に新しいバージョンを作成します。以下のCLIを使用して安全に開始します。最初にstyle-reference.htmlを作成します。通常、差別化されたタスクに適した2~3の方向性、実際のケースのリンク/クリエイター、観察された証拠とあなたの解釈、トークンサンプル、比較用の同じタスクのオリジナルの小さなUIスタディを含めます。プラットフォーム適合性、制限事項、およびあなたの推奨事項を含めます。既知のブランドの選択を維持し、ユーザーがすでに1つの方向性を提供している場合は、代替案を強制するのではなく、それを検証します。
実際のstyle-reference HTMLを提供し、ユーザーに選択または修正を依頼します。ここで停止します。 ユーザーが名前付きの方向性を明示的に承認する(または現在のタスクでその正確な選択を委任する)までは、完全なアプリ画面、design-system.html、または最終的なDESIGN.mdを作成しません。ローカルで選択されたラジオ/カード、推奨事項、経過時間、またはCLIレコードはユーザー承認ではありません。承認されたHTMLのSHA-256とともに承認証拠を保持します。そのボードへの重要な変更には、新たな決定が必要です。このゲートを、承認済みで無関係な作業について再度質問する許可として扱わないでください。
3. 承認後、完全なHTMLプロトタイプを構築する
prototype-contract.mdと、platforms-and-quality.mdの関連セクションのみを読みます。ユーザーの実際の決定を記録します。ヘルパーは証拠を記録しますが、誰がそれを与えたかを検証することはできません。次に、生成されたスキャフォールドを準備し、設計された実用的なアーティファクトに置き換えます。
index.html: バージョン、画面エントリ、コアフロー、スタイルリファレンス、ビジュアル仕様へのリンクを含むプロトタイプホーム/ナビゲーション。各アプリには、タスク指向の独自のホームもあります。実装/ステータスの詳細は、製品クロームではなく、このレビューハブに保持します。design-system.html: このバージョンで使用されるコンポーネントの完全なビジュアル仕様:セマンティックカラー、タイポグラフィ、スペーシング、レイアウト/密度、アイコン、画面、該当するコンポーネントの状態、インタラクション/モーション、レスポンシブ/プラットフォームの違い。名前のテーブルだけでなく、実際のレンダリング例を示します。DESIGN.md: 確定的な決定、トークン値、画面/フローインベントリ、インタラクション、プラットフォームオーバーライド、アクセシビリティ、来歴、既知のプロトタイプ制限事項。画面ごとのDESIGN.mdは、関連するバリエーションのみを説明します。- 要求された各画面のHTMLスクリーン:合意された重要なパス、もっともらしいラベル付き合成データ、ナビゲーション、意味のある状態変化。共有セマンティックトークン。プラットフォームに適したインタラクションであり、縮小されたデスクトップスクリーンショットではありません。
デフォルトでセマンティックHTML、CSS変数、小さなローカルスクリプトを使用します。複雑さを軽減する場合は既存のフレームワーク/コンポーネントを再利用します。必須のReact、Tailwind、shadcn、またはネットワーク依存はありません。静的HTMLプロトタイプはローカルHTTPサーバーを介して開く必要があり、可能な場合はファイルURLでもナビゲート可能である必要があります。プロトタイプのレビューに必要なアセットはローカルにあり、ライセンスが付与されている必要があります。プロトタイプをアプリケーションソースから分離してください。
4. 検証、バージョン管理、ハンドオフ
platforms-and-quality.mdを使用して、狭いおよび広いビューポート、キーボードフォーカス、ズーム、モーション削減でレンダリング結果を確認します。該当するデバイス/プラットフォームの動作を検査します。実際の主要パスと、空/読み込み中/エラー/成功、および重要な極端なコンテンツの状態をテストします。ブラウザシミュレーションからデバイスまたはネイティブSDKの受け入れを主張しないでください。観察された問題を修正し、影響を受けたパスを再確認します。
構造的検証を実行し、ブラウザの証拠、ビューポートサイズ、テスト済みフロー、未解決の問題をQA.mdに記録します。構造的検証は、ビジュアル品質、ビジネス完全性、権限適用、外部統合、または本番環境 readiness を証明できません。明示的に未テストの項目を報告します。デプロイメント作業の場合は、機能チェックのみを報告するのではなく、関連する読み込み/ランタイム/リソースコストを測定します。通常のローカルプロトタイプは、本番ベンチマークスイートを必要としません。
以前のバージョンはそのままにしておきます。承認の無効化、改訂、封印されたスナップショット、変更ログ、最新バージョンナビゲーションについてはversioning.mdを読みます。承認されたボードを黙って編集したり、古いプロトタイプを上書きしたりしないでください。実際のファイルへのリンク、それらを開く方法、検証された内容、およびシミュレートされたままの内容を提供します。
ヘルパー(Python 3、標準ライブラリ)
<skill-dir>をこのインストールされたスキルのディレクトリに解決します。コマンドは指定されたプロジェクトに対してのみ動作し、アプリケーションソースを公開または変更しません。
python3 <skill-dir>/scripts/prototype.py init --project <project> --version v0.1.0 --surfaces web miniapp mobile desktop
# 実際のリサーチでstyle-reference.htmlを編集し、ユーザーの決定を得ます。
python3 <skill-dir>/scripts/prototype.py record-approval --project <project> --version v0.1.0 --direction "B" --evidence "この会話での正確なユーザーの決定"
python3 <skill-dir>/scripts/prototype.py prepare --project <project> --version v0.1.0
# 保留中のすべてのスキャフォールドを置き換え、合意されたフローを実装し、レンダリング/レビューします。
python3 <skill-dir>/scripts/prototype.py validate --project <project> --version v0.1.0 --complete
python3 <skill-dir>/scripts/prototype.py seal --project <project> --version v0.1.0 --summary "スコープと重要な変更をレビューしました"
record-approvalはワークフローレコードを保存します。IDやセキュリティ境界ではありません。その証拠を決して偽造しないでください。prepareはスキャフォールドを生成しますが、完成したプロトタイプは生成しません。sealはファイルハッシュを記録します。ビジュアルサインオフや不変のストレージではありません。マニフェストとQA証拠を一緒に使用してください。