mandasTeam/frontend-autoral

フロントエンド オートラル

日本語で、端的に回答してください。動作確認済みのインターフェースを納品し、草案は避けてください。

このスキルが解決する問題：AIが生成したサイトは、漠然とした計画に基づき、実際のコンテンツがなく、誰も結果を確認しないため、互いに似通ってしまいます。ここでは、各プロジェクトに、コードを書く前に、題材から導き出されたアートディレクションを記述し、実際のブラウザで測定し、レンダリングを確認してから、クリシェリストと比較した後にのみ納品します。

ここでは、すでに調整された4つのソースを統合しています。

• taste-skill (leonxlnx)：題材の棚卸し、議論、247の受賞サイトから研究されたコンポジションの抽選、アイデアのフレーズ、ライブな要素、オープンアーカイブからの画像、実ブラウザでのlintとインスペクター、評価の上限付き批評パス。ツールは vendor/taste-skill/ にあります。
• Emil Kowalski (emilkowalski/skills)：アニメーションの決定、カーブ、持続時間、物理、スマートフォンアプリの感覚、ワーストケースデータ、Before/After 表でのレビュー。
• UXの法則 (lawsofux.com)：画面で確認できる30の法則を質問として提示。
• logo-design (kaankiziltug)：ロゴ、アプリアイコン、ファビコンのプロセス。SVGの監査とWebセットのエクスポートを含みます。ツールは vendor/logo-design/ にあります。

ソース間で矛盾がある場合： 現在のリクエスト > 「Igorの好み」と references/cliches.md > このファイル > references/movimento.md（動きについて指示） > vendor/ の英語の参考文献。特に：ここでの動きは機能がある場合のみ、アニメーション要素の最低数はなく、各セクションへのエントリーはありません。抽選からのスクロールシーンは、ユーザーがリクエストした場合のみ含まれます。

<skill> はコマンド内でこのスキルのフォルダを指します。スクリプトには Node 22+（lint：18+）と Chrome、Edge、または Chromium（Playwrightのものでも可；scripts/achar-chrome.mjs が自動で見つけます）が必要です。アイコン用のスクリプトは Python 3 が必要です（Windowsでは python）。

使用するタイミング

• サイト、ランディングページ、ポートフォリオ、企業サイト、アプリ画面、ダッシュボード、フォームの作成。
• 既存のインターフェースのリデザイン、または「より美しくする」。
• UI/UXのレビュー：階層、アクセシビリティ、状態、コピー、レスポンシブ、アニメーション。
• プロダクト向けに、機能的なだけでなくアイデンティティのあるコンポーネントの作成。
• プロジェクトのロゴ、シンボル、アプリアイコン、ファビコンの作成、または既存のロゴのバリエーション生成。

使用しない場合：README と GitHub のプロフィールアート（スキル readme-designer）、グラフとデータ可視化（スキル dataviz）、デッキとドキュメント。

モードの選択

• ページ作成（サイト、ランディング、ポートフォリオ；新規プロジェクトまたは完全リデザイン）：全フロー。
• アプリ画面（ダッシュボード、管理画面、設定、受信トレイ、フィルター付きリスト、エディター）：開始前に vendor/taste-skill/references/app-screens.md 全体を読んでください。独自のシーケンス、独自の抽選 (draw.mjs --app --kind <タイプ>)、独自のルール（控えめな枠線、小さなラベル、反復パネルが通常；グラデーション、グロー、カラー四角のアイコン、虹色グラフ、架空のバニティ数値は不可）があります。以下のフローを --app フラグ付きで使用してください；ライブ要素と画像フロアは適用されません。アプリを示すプロダクトページは「ページ」です；その中のアプリフラグメントはアプ のルールに従い、data-ui 属性を持ちます。
• 進化（既存のビジュアルシステム、DESIGN.md、BRAND.md、トークン、Tailwind テーマ、コンポーネントライブラリがある場合）：既存の方向性が優先されます。事前に読み、トークンとコンポーネントを再利用し、ユーザーがリクエストした場合のみアイデンティティの変更を提案します。抽選はスキップします（または --keep palette,type を使用してコンポジションのみ抽出）、ただしゲートとクリシェリストは通過します。
• レビュー（監査、「ここで何が悪い？」、「アニメーションをレビューして」）：現在の状態で、ステップ1と5のみ。発見事項は場所 | 変更前 | 変更後 | 理由の表に、重大度でグループ化し、前置きなしで記載します (references/revisao.md §11)。
• 部分調整（「もっと大胆に」、「もっと落ち着いて」、「フォントを変更」、「これをアニメーション化」）：既存の方向性の中で、リクエストされた箇所のみ変更します。「調整」については references/oficio.md を、アニメーションについては references/movimento.md を参照してください。
• アイコンまたはロゴ（ロゴ、ブランド、アプリアイコン、ファビコン）：references/icones.md を参照してください。すべてのサイトまたはアプリプロジェクトにおいて、ライトモードがステップ4で実行され、プロジェクトに独自のアイコンが付属します。

フロー

各ステップは、完了条件が満たされた場合にのみ終了します。

1. 題材を理解する。 リクエストと既存のコードを読んでください。自分自身に、各行で答えてください：プロダクトは何か、誰向けか、主要タスクは何か、ページかアプリ画面か、実際のコンテンツは何か（テキスト、画像、データ、ロゴ、ブランド）、そして実際に存在する画像は何か。このクライアントだけが持っている8～12のものの棚卸しを完了してください (references/direcao.md §1)。プロダクトまたはターゲット層の本質が欠けている場合は、最大4つの質問を一括で1ラウンド行ってください。好みだけが欠けている場合は、決定し、何を決定したかを伝えてください。

   • プロダクト、ターゲット層、タスク、タイプ、棚卸し、画像棚卸しが明確になり、ギャップに回答または決定が記録されたら完了です。

2. コードの前にアートディレクションを記述する。 プロジェクトルートの DESIGN.md に記述します（テンプレートは assets/DESIGN.template.md；単一ファイルで、回答の先頭に）。方法は references/direcao.md を参照：

   • 議論：ページをセクションごとの主張と証拠として表現；主張のないセクションは削除；
   • コンポジションの抽選（vendor/taste-skill/scripts/draw.mjs ... --options 3）、ページに推奨：棚卸しから何かを取り入れるオプションを選択し、最も馴染みのあるものではなく、クリシェによってパレットとタイプをフィルタリング；
   • シーンのコンセプトを一文で、「似ている／似ていない」リスト；
   • アイデアのフレーズ（「このページでは、[棚卸しの何か] が [リソース] になる」）、競合テスト、ライブ要素（アイデアから作られた、実際のコンテンツとのインタラクション）；
   • シグネチャ；役割とコントラストを持つ4～6の名前付き色のパレット；最大5サイズのスケールを持つ1～2ファミリー；等しいマージン、リズム、シェイプルールを持つグリッド；動きのルール；画像のソース；アイコンの出典；
   • 各セクションのASCIIワイヤーフレーム、隣接セクションは異なるシェイプ。

   その後、「スワップテスト」を実行します：「プロダクト名を別のものに変えた場合、このディレクションは任意の競合他社に機能しますか？」「はい」の場合は、修正し、何を変更したかを伝えてください。references/cliches.md（§11を含む；クリシェを削除しても空にしてはいけない）と照らし合わせて確認してください。

   • 各選択肢にプロダクト、ターゲット層、またはコンテンツに関連する理由があり、アイデアのフレーズが競合テストに合格し、正当な理由なくクリシェに該当する項目がない場合に完了です。

3. マークアップの前にプレーンテキストのスクリプトとしてコンテンツを記述する。 references/copy.md を使用：全幅で2行に収まるタイトル（計算してください）、その直下のサポートフレーズ、動詞と目的語を持つ1つの主要アクション、完全なコンテンツを持つ各セクション。証拠（数値、証言、クライアント、評価）が不足している場合は、 [実際の証言をここに] のような可視マーカーを使用し、発明しないでください；コンテンツの詳細（料理名、部屋名）のみが不足している場合は、もっともらしいサンプルを使用し、確認用にリストアップしてください。

   • どのテキストも別の会社のサイトに存在せず、証拠が発明されておらず、サンプルがリストアップされている場合に完了です。

4. 静的ビルド。 動きをオフにして考えてください：アニメーションが必要なページは完成していません。順序：トークン（色、タイプ、スペース、シェイプ、カーブ）、デスクトップとモバイルで正確に描かれたヒーロー、各セクションをワイヤーフレームに従ってアイデアを価格、FAQ、フッターまで導く、画像（references/imagens.md：自作、生成、オープンアーカイブからの assets.mjs、題材から描画）、ライブ要素、フレーム（等しいマージン、各セクションのタイトル、空の部分なし）、状態とセマンティクス、ファビコンとアイコン（references/icones.md、ライトモード）。references/oficio.md、references/ux.md、references/leis-ux.md に従ってください。vendor/taste-skill/assets/base.css はオプションのニュートラルベースです。

   • プロジェクトがすでに持っているスタックを使用してください。機能的な理由なしに新しいビジュアル依存関係を追加しないでください。
   • コンソールエラーなし、モバイルで水平スクロールなし、すべての関連状態（hover、focus-visible、active、disabled、loading、エラー、空）、ワーストケースデータテスト済み（references/ux.md §9）、独自のアイコンが配置されている場合に完了です。

5. 測定、確認、修正。 ゲートを実行します： node <skill>/scripts/inspecionar.mjs <url-ou-index.html> --src <コードフォルダ> （アプリ画面の場合は --app 付き）。lintとインスペクターを1440、768、390 pxで実行し、スクリーンショットを .taste-skill/inspect/ に保存します。すべてのFAILを修正します。その後、すべてのスクリーンショットを開き、references/revisao.md で批評します：AIテスト、15パス、上限付き評価ルーブリック、ラウンド形式で書かれた批評。最も深刻な3つの問題を修正し、測定して再度確認します；最大3ラウンド。

   • FAILが0、平均スコア≥8、どの基準も<7なし、問題リストが空の場合に完了です。到達できない場合は、保留中の項目と実際のスコアを伝えてください。

6. 機能がある場合のみ動きを追加。 ここで references/movimento.md に基づいて動きを決定します：頻度（キーボード操作や一日中見るものはアニメーション化しない）、目的、カーブ（強い ease-out、決して ease-in しない）、持続時間（インターフェースでは <300 ms）、プレス（scale(0.97)）、トリガーからの原点、マウスのみのホバー、prefers-reduced-motion。ページごとに最大1つのオーケストレーションされた瞬間、通常はライブ要素またはシグネチャ。ゲートを再度実行し、スクリーンショットで何も消えていないことを確認します。

   • すべてのアニメーションが「何のために？」に答え、ゲートがFAIL0のままの場合に完了です。

7. 確認と報告。 references/revisao.md §9と§10に従った最終チェックリストとレポート。

レンダリング方法がない場合（ブラウザもインストール方法もない）？lintのみを実行し、その旨をレポートに記載し、チェックリストに対してコードを読んでレビューしてください。画面で確認したとは言わないでください。

ワンスクリーンデザイン

詳細は references/oficio.md、references/cliches.md、references/leis-ux.md にあります。

• すべてのビジュアル決定には、 プロダクト、ブランド、コンテンツ、または使用に関連する理由があります。要素を追加する前に、理解、機能、美学、または体験を向上させるかどうかを自問してください。向上させない場合は、追加しません。
• アイデンティティは題材から生まれ、 トレンドからではありません。未来的、テクノロジー、ミニマリストはデフォルトではなく、題材が求める場合のみ使用します。ミニマリズムは個性の欠如ではありません。
• 独自のビジュアル、従来のメカニクス（ヤコブの法則）。大胆さはタイポグラフィ、色、画像、コンポジションに宿ります；メニュー、リンク、ボタン、フォームはどのサイトでも同じように機能します。
• 大胆さは一箇所だけ、 アイデアシグネチャに。残りは規律正しく保ちます。納品前に、装飾を一つ取り除いてください。ただし、装飾を削除しても空にしてはいけません：スペースはスケール、完全なコンテンツ、題材の画像、または色のフィールドに使われます。
• コンポジションはコンテンツに従います。 各セクションは、表示するものに応じてシェイプを選択します：リスト、シーケンス、比較、大きな画像、引用、表。隣接セクションはシェイプを繰り返しません。すべてがカード、中央揃え、3列グリッドである必要はありません。
• 対称性の前に階層。 画面ごとに1つの主要要素；2～3サイズで機能し、全体で最大5サイズ；タイトルは最大2行。グリッド内の非対称性、外部マージンは常に等しく。
• 役割のある色。 1つの背景、1つのインク、1～2の着色されたニュートラル、1～3箇所での1つのアクセント（フォン・レストルフ効果）。トーンレベルでのサーフェス、グラデーション、グロー、ブラー、ガラス、休止状態のシャドウはなし。
• 声としてのタイポグラフィ。 プロダクトの性格に基づいて選択された1～2ファミリー、読みやすいボディサイズ（≥16px、行あたり45～75文字）、フルインク。
• 見せる画像。 プロジェクトの実際のもの、生成されたもの、クレジット付きのオープンアーカイブからのもの、または題材から描かれたもの；1つの支配的な画像が6つの小さな画像に勝ちます；グレーボックスや汎用ストックフォトは避けてください。
• 機能がある場合のみ動き、 速く、中断可能で、ease-out と正しい原点を使用。常に prefers-reduced-motion。
• アクセシビリティは交渉不可： AAコントラスト、可視フォーカス、キーボードナビゲーション、正しいセマンティクス、コンテンツを含む画像の alt、ターゲット≥44px、ズーム許可。

Igorの好み

出発点であり、レシピではありません。現在のリクエストが常に優先されます。

• テーマはプロジェクトごとに変わります。依頼なしに以前の作業のパレット、フォント、モチーフ、コピーを再利用しないでください。（taste-skillの抽選が役立ちます：以前のものを記憶しています。）
• 明確に定義され、よく実行されたテーマを好み、セット全体に存在し、控えめな装飾ではありません。
• 何よりも一貫性：スタイリングされたセクションの中の「生の」セクションは気になります。調和しない場合は、同じパターンで作り直してください。
• 微妙な動き。オブジェクトが画面を横切るのは禁止です。
• 自然なコピー、無理なキャッチフレーズなし、誰も依頼していない免責事項やフッターなし。
• セクションを「改善する」とは、コンテンツを維持しながらビジュアルを再作成することで、削除することではありません。
• 彼が要素を禁止した場合、その要素のみを削除してください。残りを再解釈しないでください。

落とし穴

• 最初の衝動はクリシェです。 タイトル、サブタイトル、2つのボタン、グラデーションのある中央揃えのヒーロー；カラー四角内のアイコン付き3カード；数字のセクション； testimonial。最初のアイデアが速すぎる場合、それはおそらくパターンです。棚卸しに戻ってください。
• あるクリシェを避けて別のクリシェに陥る。 紫を避けてクリーム色の背景+セリフ+テラコッタ、または黒+ライムグリーンに行くことは、AIパターンを別のものに変えるだけです。references/cliches.md の「5つの標準ビジュアル」を参照してください。
• クリーンで薄っぺらいページ。 装飾がなく、その代わりになるものもない場合、クリシェでいっぱいのページに負けます。完全なコンテンツ、大きなタイプ、実際の画像。
• カテゴリーのアイデア。 「パン」はすべてのパン屋に当てはまります。アイデアのフレーズが競合他社に機能する場合、棚卸しに戻ってください。
• 埋めるために発明されたコンテンツ。 出典のない数字、架空のクライアントのロゴ、 testimony、ランダムなアバター、汎用のダッシュボードモックアップ。マーカーを使用するか、セクションを削除してください。
• 3行のタイトル。

…

[翻訳のため省略]