Communitygithub.com

フロントエンドをゼロから作成

プロダクトの概要とターゲットユーザーから、インタラクションデザイン、実装、レンダリング検証を経て、空のプロジェクトまたは明示的に要求された新しいインターフェース用にフロントエンドを作成します。ランディングページ、ストアフロント、ダッシュボード、アプリケーションインターフェースをゼロから構築する場合に使用します。

フロントエンドをゼロから作成 とは?

このスキルは、新しいフロントエンドをゼロから作成するための包括的なガイドです。プロダクトの要件とターゲットユーザーを理解することから始まり、具体的なプロポーザルの定義、構築計画、実装、検証、そして最終的な納品レポートまで、6つのステップで構成されています。このスキルは、既存のインターフェースの監査(`audit-frontend-designer-konvert`を使用)や、既存のインターフェースへの参考デザインの適用(`design-por-referencia-konvert`を使用)とは明確に区別されており、新規作成に特化しています。品質基準として、主要なタスクのエンドツーエンドの機能、セマンティックなHTML、アクセシビリティ(キーボード操作、フォーカス、コントラスト)、レスポンシブデザイン、およびデータのプライバシーとセキュリティの重視が挙げられます。また、合成データの使用、実際のユーザーテストやパフォーマンス指標の虚偽の主張の回避など、倫理的なガイドラインも定められています。このスキルは、Claude Code、Cursor、CodexなどのAIエージェント向けに設計されており、参照資料として複数のドキュメント(例: discovery-brief.md, stack-choice.md, visual-foundation.md)が用意されています。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/andreischuaste12-ctrl/frontend-designer-konvert/tree/main/skills/create-frontend-from-zero-konvert

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

フロントエンドをゼロから作成 は何をしますか?

プロダクトのニーズを、機能的でアクセシブル、かつ検証可能なインターフェースに変換します。このスキルは、空のプロジェクトまたは明示的に要求された新しいエリアに新しいフロントエンドを構築することが主な目的である場合に主導権を握ります。実装し、可能であればプロジェクトを実行し、実際に検証した内容を報告します。

境界と連携

  • 新しいフロントエンド: このスキルが主導します。参考デザインがオリジナルの作成を導く場合も含みます。サードパーティのブランド、コンテンツ、アセットをコピーせずに、原則を抽出します。
  • 既存のインターフェースを監査する: audit-frontend-designer-konvert を使用します。これは読み取り専用です。「監査して修正する」場合は、このスキルから始め、承認契約に従います。
  • 参考デザインを適用する、既存のインターフェースを直接改良する、または承認されたレポートを実装する: design-por-referencia-konvert を使用し、そのスコープ、承認、外部依存関係のルールを尊重します。
  • 混合プロジェクトでは、許可された新しいエリアのみを実装し、既存の統合とインターフェースを特定して保持します。他のスキルの知識とツールを重複させることなく活用するには、連携ガイド を参照してください。

フロー

  1. 依頼とコンテキストを理解する。 プロジェクトの指示、関連ファイル、スタック、既存の規約を読みます。プロダクト、ターゲットユーザー、メインタスク、ページ、データ、アイデンティティ、制約、および作業の配信先を特定します。提供された事実と仮説を区別し、ペルソナや調査結果をでっち上げないでください。不可欠な選択が推論できず、取り返しのつかない影響がある場合は、明確化を求めます。その他の決定では、前提を宣言して先に進みます。結果を 発見とブリーフ に記録します。
  2. 具体的な提案を定義する。 関連するジャーニーと状態(初期、ローディング、空、成功、エラー、および該当する場合はリカバリ)を選択します。 状態とコンポーネント を使用して、画面ごとにコンポーネントと状態をリストアップし、監査ユニットを完了条件として使用します。複数のページやカテゴリがあるプロジェクトの場合は、 コンテンツ構造とナビゲーション を使用してパスを定義します。ターゲットユーザーと目的に沿ったコンテンツ、階層、ナビゲーション、ビジュアルディレクションを、 ビジュアルファンデーション に従って決定されたトークンで定義します。2つのオプションが結果を実質的に変える場合は、 ビジュアルディレクションの探索 を使用します。既存のローカルマテリアルと、利用可能で関連性がある場合は、監査スキルのカタログと知識ユニットを使用します。実際に参照した参考文献のみを引用します。ビジュアルリファレンスはインスピレーションであり、ユーザビリティの証拠ではありません。
  3. 構築を計画する。 既存のフレームワーク、ルーティング、コンポーネント、トークンを再利用します。空のプロジェクトでは、 スタックの選択 を使用して、依頼と環境に最も適した最もシンプルなソリューションを選択します。新しい依存関係を正当化し、実行する前にバージョンとスクリプトを確認します。有料サービス、公開、外部アカウント、実際のデータに関する権限を推測しないでください。バックエンド、認証、統合のスコープは依頼に従って維持し、ない場合は合成データを使用して制限を明確に示します。
  4. 実装する。 許可されたスコープ内で、実際のコンテンツ、セマンティック構造、スタイル、コンポーネント、インタラクションを構築します。動作のないボタンや、機能しているように見せかけた架空のリンクは避けてください。要求されたアクションを実装するか、利用できないことを明確に示します。一貫性のあるトークン、可視状態、レスポンシブレイアウトを使用します。 コンテンツ、SEO、パフォーマンス、測定 のルールを適用します。識別された架空のコンテンツ、公開ページでの基本的なSEO、依頼なしのアナリティクスはなしです。 セキュリティとローカライゼーション を参照してフロントエンドを保護し、プロダクトに複数の言語や地域がある場合は、定義されたロケールにインターフェースを適応させます。必要なく、該当する許可なしに、ユーザーのコード、データ、統合、ファイルを削除または置換しないでください。
  5. 検証する。 プロジェクトに関連するチェックを実行し、可能な場合はローカルでインターフェースを実行し、レンダリング結果を開きます。メインタスク、コンテンツ、ナビゲーション、キーボード、フォーカス、フォーム、関連する状態、狭い画面とデスクトップをチェックします。該当する場合は、コントラストとモーションの低減を評価します。利用可能な場合は、参照スキルのスクリプトを、許可された出力と合成データで使用します。以前のバージョンがない作成の場合、Before/Afterをでっち上げないでください。最初のキャプチャを初期参照として記録し、実際に存在する状態またはバージョンのみを比較します。 検証 を参照してください。
  6. 納品して報告する。 完了の定義 を確認し、そのレポートテンプレートを使用します。変更したファイル、関連する決定と前提、実行方法、実行したチェックとその結果、シミュレートした機能、検証できなかったことを報告します。タスク、検査した領域、決定、検証した基準を、許可された出力ディレクトリ内の execution-record.json に、 実行記録 とそのバリデーターに従って記録します。プロンプトやプライベートURLを保存しないでください。証拠なしに、ユーザーテスト、完全な準拠、パフォーマンス、または商用結果を主張しないでください。ブラウザが利用できない場合は、インターフェースが視覚的に検査されていないことを明示的に報告します。

プライバシーとセキュリティ

許可されたターゲットと環境のみを使用します。不必要な .env、認証情報、セッション、個人データを読み取ったり公開したりしないでください。合成コンテンツを使用し、共有前にキャプチャを確認します。キャプチャツールの保護と制限を尊重します。検査はJavaScriptを実行し、信頼できないサイト向けのサンドボックスではありません。許可され、Gitで無視されるディレクトリ、またはチェックアウト外にのみアーティファクトを記録します。必要なくプロジェクトのプライバシー設定を変更しないでください。許可なく、第三者にデータを送信したり、アカウントを作成したり、公開したりしないでください。

品質基準

インターフェースは、明確さ、視覚的階層、一貫性のあるコンテンツ、有用なフィードバックをもって、メインタスクをサポートする必要があります。コンテキストに応じて、セマンティクス、フォーカス、アクセシブルな名前、ラベル、リフローに注意してください。自動チェックのみに基づいてアクセシビリティ認定を主張しないでください。コンバージョン指標、推薦文、バッジ、価格、統合、機能をでっち上げないでください。壊れたアクションで見た目を良くしようとするよりも、スコープ内で完全でテスト可能な実装を優先します。

完了の定義

納品は、メインタスクが合意されたスコープでエンドツーエンドに機能し、 完了の定義 の各項目が満たされているか、理由があって適用外か、理由があって未検証の場合にのみ完了します。ゼロからの作成で最も頻繁に失敗するポイント:

  • 通常以外の状態(ローディング、エラー、空、成功、リカバリ)が観察可能な形で実装されていない。
  • フォーカスが削除または隠されている、ラベルがプレースホルダーのみ、エラーが色だけで示されている。
  • コントラストとタッチターゲットがレンダリング上で測定されていない。
  • 機能しているように見えるが、何もしないボタンやリンク。
  • でっち上げられた商用データ、推薦文、統合。
  • 記録された決定なしに追加されたアナリティクスや外部ソース。

参考文献と例

資料使用するタイミング
発見とブリーフ構築前:パターンと前提の記録に関する質問。
スタックの選択空のプロジェクト、プラットフォーム未定義。
ビジュアルファンデーション検証可能なコントラスト、ターゲット、フォーカスのトークンと制約。
ビジュアルディレクションの探索オリジナルディレクション、重要なオプション、レンダリングでの確認。
コンテンツ構造とナビゲーション新しいプロジェクトにおけるパス、ラベル、ページ構成。
状態とコンポーネント画面ごとのインベントリと、完了条件としての監査ユニット。
コンテンツ、SEO、パフォーマンス、測定公開ページ、ブラジルフォーマット、Core Web Vitals、プライバシー。
セキュリティとローカライゼーション可変コンテンツ、外部リソース、該当する場合は複数言語または地域。
検証チェックの実行と記録方法。
連携監査スキルと実行スキルを使用するタイミング。
完了の定義と納品納品の報告前。
ランディングページブリーフ、 Eコマースブリーフ、 納品レポート期待される詳細レベルの合成例。

関連スキル