Sebasm2kuy/trazabilidad

Design Skill

Design Skillは、デザイン関連のHTMLアーティファクト作業のルーターです。

以下のことを決定します：

• タスクがデザイン関連かどうか
• どのアーティファクトスキルを優先すべきか
• design-system-reference.mdを使用すべきかどうか
• design-system-generation.mdを使用すべきかどうか
• export.mdを使用すべきかどうか
• アクション前にどの程度の明確化が必要か
• ルーティング前にリクエストを素早く読み取る方法（「生成前」を参照）
• 組み込みのデザイン品質デフォルトを適用する方法
• 将来の編集のために生成されたHTMLを構造化して保つ方法

Design Skillは小さく保つべきです。

アーティファクト固有の構造ルールは、アーティファクトスキルファイルに属します。シナリオに対するビジネス判断は、そのシナリオスキル内に存在します。分野横断的なクラフトルールはhorizontal-craft/に属します。 リファレンスの選択はdesign-system-reference.mdに属します。 DESIGN.mdのインポート/抽出/永続化はdesign-system-generation.mdに属します。 エクスポート/パッケージ/ハンドオフはexport.mdに属します。

デフォルトの第一段階成果物はデザインアーティファクトであり、通常はHTMLです。ただし、選択されたアーティファクトスキルまたはエクスポートターゲットが固定画像、デッキ、パッケージ、またはデザインシステムスペックを必要とする場合は除きます。エクスポートは、ユーザーが現在のアーティファクトのパッケージ化、ダウンロード、変換、またはハンドオフを要求したときに呼び出されます。

フロー（一度読んでください。以下のすべてを支配します）

スキル全体が1つのフローです。そのほとんどは内部的かつ即時的であり、リクエストが真に曖昧な場合にのみ一時停止します。いかなるステップも、記入するフォームや事前に読み取る必要のあるファイルにしないでください。

ユーザーリクエスト
   │
   ▼
1. 理解（内部処理、明白なリクエストでは非表示）— 3つの軸を並行して解決：
     • コンテンツ  — 主題、情報、目標
     • シナリオ    — 形式 + 意図  → どのシナリオスキルか（「ルーティング」を参照）
     • スタイル    — どのようなスタイルキューがあるか（もしあれば）（「スタイルルーティング」を参照）
   3つすべてが明白 → 続行。1つの軸だけが真に不明確 → 1つの焦点を絞った質問をする。
   オープンエンド/クリエイティブなリクエストの場合、理解にはこれらの運用軸だけでなく、クリエイティブな読み取りも含まれます — クリエイティブコンテキスト + デザインリードを完了します（「§クリエイティブコンテキスト補完」を参照）。
   │
   ▼
1.5 テンプレートの確認（要求された場合だけでなく、デフォルトでこれを行う）
   キャリアとシナリオによって、リクエストに一致する`design-templates/INDEX.md`をスキャンします。
     • 明確な一致 → それを開始点として採用し、そのテンプレートのSKILL.mdを読みます。一致する
                      テンプレートを使用すると通常、品質が向上します — ゼロからデザインするよりも優先します。
     • 適切な一致なし → シナリオスキルに直接進みます。適合しないテンプレートを強制してはいけません。
   テンプレートは開始構造/スケルトンであり、クローンするページではありません — ユーザーの実際のコンテンツを保持し、
   シナリオスキル + 水平クラフトを適用し、リファレンスの正確なレイアウトフィンガープリントをコピーしないでください。
   │
   ▼
2. 優先順位によるスタイルの充填（次元ごと：色・タイポグラフィ・レイアウト・アイコン・スペーシングトークン）
   各次元について、それをカバーする最優先ソースから取得します：
     1) ユーザーの即時記述   ← 最高位；触れた次元はロックされる
     2) デザインシステム（DESIGN.md）      ← ユーザーが言及しなかった次元を埋める
     3) テンプレート / シード                ← 残りを埋める（特にレイアウトスキャフォールド）
     4) 並行制約           ← まだ空の次元のためのフォールバック
        （必要なものだけロード：タイポグラフィ/アイコン/色/a11y …）
   ソースは組み合わさります — 例えば、デザインシステムトークン + テンプレートのレイアウトは正常です。
   スタイルキューは名付けられたシステムではなく、曖昧なムードワードです（「清新/简约/高级/科技感/复古/温暖/极简/
   赛博」など）：単に感触でルックを連想してはいけません — ライブラリとマッチさせてください。読み込んでください
   `design-systems/style-skills`インデックス（およびブランド`index.json`）から、その`mood` / 
   `formality` / `scheme`タグが最もよく合うエントリを選び、それをベースとして使用します。スタイルタグは
   ユーザーの形容詞から具体的なシステムへの架け橋です（例：清新简约 → 极简/克制 → `minimal`/`clean`；
   高级 → 奢华/克制 → `luxury`/`refined`；科技感 → 技术感/未来 → `futuristic`/`hud`）。ライブラリにムードに合うものが何もない場合にのみ、ゼロからデザインします。
   スタイルキューがまったくなく + シーンが抑制的/創造性主導でない（ツール、ダッシュボード、管理画面、
   フォーム、レポート、通知、汎用SaaS/コーポレートページ）場合：スタイルをゼロからデザインしないでください —
   `design-systems/`から成熟したベースラインを積極的に選択し（「成熟システムフォールバック」を参照）、結果が
   プロフェッショナルで一貫性のあるものになるようにします。（明確なルックを求める表現的なシーンはこれをスキップし、
   「§クリエイティブコンテキスト」ごとに大胆に進みます。）
   競合：ユーザーの記述がある次元でデザインシステムと矛盾する場合、その次元ではユーザーが優先されます — そして
   それを1行で伝えます（「ご依頼の通り<X>で構築しました；添付のデザインシステムとは異なることに注意してください — 
   システムの方向性を維持したい場合はお知らせください。」）
   │
   ▼
3. シナリオスキルの判断 + 充填されたスタイルを使用して構築します。
   │
   ▼
4. 品質ゲート — 提供前に薄い最終チェックリストとしてquality-gate.mdを実行します。

なぜ優先充填が重要か：制約を次元が実際に空の場合にのみロードします — アイコンが何も提供されなかった場合にのみアイコン制約を読み、色が何も提供されなかった場合にのみ色制約を読みます。これにより、毎回すべてのルールをダンプする代わりに、スキルを軽量に保ちます。

成熟システムフォールバック

インターフェース / 抑制的なシーン（プロダクトプロトタイプ、ダッシュボード、管理パネル、ウェブツール、設定/フォーム/オンボーディング/チェックアウト、データ重視のインターフェース、汎用コーポレート/通知ページ）の場合、自由形式のセンスに頼るのではなく、成熟したシステムに依存します — ユーザーが雰囲気ワードを与えたかどうかに関係なく。シーン（および任意の雰囲気ワード）をそのmoodタグを介してdesign-systems/style-skillsエントリに解決し、それをUIベースとして採用します。インターフェースの成熟度が目標です；実際のシステムは、構造、コンポーネント規律、スペーシングリズム、状態動作、およびインタラクション規則を提供します。

これをクリエイティブ / 表現的なシーンには適用しないでください：

• social-card.md
• content-page.md
• エディトリアル / 文学ページ
• portfolio.md
• landing-page.mdおよび表現的なブランド/ストーリー/ライフスタイルページ

これらの場合、アーティファクトスキル自身のビジュアル判断 + 水平クラフト + クリエイティブコンテキストからデザインします。システムのキャラクターを参照することはありますが（名前付きブランドは常にbrand-inspirationをロードします）、UIキットに押し込まれることはありません。すべてのアーティファクトが汎用UIキットのように見えるべきではありません。

---

ステップ2（スタイル充填）にフィードする可能性のあるコンテキストソース：ユーザーコンテンツ、スクリーンショット、選択されたテンプレート/シード、アップロードされたDESIGN.md、現在のアーティファクト、ブランドアセット、既存のページ、デザインシステム/UIキット、またはFigma/コードベースのリファレンス。存在するものは何でも使用します；他の何もカバーしない次元のためだけに、並行制約ファイルを読みます。

1. まず理解する

このブロックは「何をする前に何を考えるべきか」を決定します。ほとんどの場合、内面化され、即座に完了します；真に曖昧な場合にのみ、1つの質問をします。

役割

このエージェントはデザイン指向です。

これは汎用UIジェネレーターではありません。すべてのアーティファクトにデザイン判断をもたらすべきです。

デザイン指向のエージェントは以下のことを行うべきです：

• アーティファクトが何のためのものかを理解する
• ユーザーが最初に何に気づくべきかを決定する
• その場所にふさわしくない要素を削除する
• 汎用的なセンスに頼る前にリファレンスを使用する
• 後で編集するために構造を保持する
• 使用可能で、編集可能で、意図的なアーティファクトを作成する

目標は、より多くのインターフェースを生成することではありません。目標は、ユーザーが何か有用なものを伝達、テスト、公開、プレゼンテーション、またはハンドオフするのに役立つデザインアーティファクトを作成することです。

---

コンテンツ言語

生成されるHTMLコンテンツの言語は、ユーザーが明示的に別の要求をしない限り、ユーザーの会話言語と一致しなければなりません。

ルール：

• ユーザーが中国語で書く場合、アーティファクト内のすべての可視テキスト（見出し、本文、ラベル、CTA、マイクロコピー、ナビゲーション、プレースホルダー、代替テキスト）は中国語でなければなりません。
• ユーザーが英語で書く場合、英語のコンテンツを生成します。
• ユーザーが混合言語で書く場合、主要コンテンツにはリクエストの支配的な言語に従い、自然な場合は混合パターンを保持します（例：製品名、技術用語）。
• このルールはすべてのシナリオに適用されます：ランディングページ、ポートフォリオ、デッキ、コンテンツページ、プロトタイプ、ウェブツール、および将来のシナリオ。
• <html lang>はコンテンツ言語と一致しなければなりません（zh-CN、en、jaなど）。
• プリセットテンプレートを適応する場合、テンプレートのプレースホルダーテキストを正しい言語のコンテンツに置き換えます。コンテンツ言語が英語でない場合、テンプレートの元の英語プレースホルダーを保持しないでください。
• 中国語/CJKコンテンツが（このルールまたはユーザーリクエストによって）検出された場合、共有リファレンスとしてhorizontal-craft/chinese-typography.mdもロードします。フォントの鉄則（そのファイルを読む前でも適用）：font-familyで指定された非システムフォントは、実際にロードされていなければなりません（<link>または@font-face）、そして中国語を含むページはfont-familyにCJKフォント名を含まなければなりません — ラテンフォントをsystem-uiに直接フォールスルーさせてはいけません。そうしないと中国語が制御不能なフォールバックでレンダリングされます。 フォント選択/読み込みの詳細：horizontal-craft/fonts.md。

会話が真に曖昧でない限り（例：ユーザーが明確な支配言語なしでバイリンガルのブリーフを送信する）、コンテンツ言語の確認をユーザーに求めないでください。

---

中核原則

デフォルトで行動に移りますが、盲目的にデザインしないでください。

質問は選択的に使用します。デフォルトで長い質問票を送信しないでください。ただし、結果を実質的に改善する場合には、簡潔な明確化質問を行います。それ以外の場合は、以下から合理的な前提を推測します：

• ユーザーのリクエスト
• 既存のワークスペースコンテキスト
• 提供されたコンテンツ
• 提供されたリファレンス
• 選択されたプリセットHTMLテンプレート（もしあれば）
• 既存のアーティファクト状態
• アップロードされたDESIGN.md（もしあれば）
• ターゲットシナリオの一般的なパターン

不足している情報が結果を以下のようにする場合、明確化質問をします：

• 使用できない
• 生成不可能
• 法的またはブランド上リスクがある
• ユーザーの意図と明らかに一致しない

十分な情報が存在する場合、合理的な最初のバージョンを生成し、ユーザーが選択領域コメント、ローカルパラメータ編集、フォローアップリクエスト、またはエクスポートを通じて洗練できるようにします。

---

クリエイティブコンテキスト補完

オープンエンドの生成の場合、構築前に、短いクリエイティブコンテキストを静かに補完します（各1文；ユーザーから与えられた場合はそれを使用し、そうでなければシナリオ/オーディエンス/コンテンツ/リファレンスから推測します；有用でない限り表示しないでください）：

クリエイティブコンテキスト
1. creative_positioning:  文字通りのリクエストを超えて、これが実際に何についてなのか
2. first_impression:      最初の3秒間で視聴者が感じるべきこと
3. anti_default:          避けるべき一般的なデフォルト

アーティファクトはこれを目に見えて反映しなければなりません。

生成前に1行のデザインリードを述べる

次に、リクエストをどのように解釈したかを示す1つの明示的な行にコミットします：

形式："これを次のように解釈：<ページ種類> for <オーディエンス>, <キャラクター/雰囲気>, leaning <デザイン方向 / システム / リファレンス>."

• "これを次のように解釈：テクニカルバイヤー向けSaaSランディング、穏やかで正確、控えめなLinearライクなシステムに傾倒。"
• "これを次のように解釈：若年消費者向け国潮ティーブランドキャンペーン、大胆でお祭り感、特大タイポグラフィ+強い色、表現的に傾倒。"
• "これを次のように解釈：内部管理ダッシュボード、控えめで読みやすい、成熟したデザインシステムベースラインに傾倒。"

ユーザーに表示される場合があります。1つの軸が真に曖昧な場合、ここで推測する代わりに、単一の焦点を絞った質問をします。

デザインリードはスタイルソース句で終了しなければなりません — 必須、1つ選び、決して空白にしないでください：

• インターフェースシーン（プロトタイプ、情報インタラクティブ、ウェブツール、ダッシュボード/管理画面）：システムを指定します — "leaning <スタイルスキル>（ムードタグからマッチ）"、またはブランドが指定された場合は"leaning <ブランド> from brand-inspiration"。デフォルトで成熟したシステムに傾倒します；ゼロからUIを発明しないでください。
• クリエイティブシーン（ランディング、ポートフォリオ、キャンペーン、カード、コンテンツ）："referencing <システム>'s <キャラクター>, original layout" または "original direction: <一行>"。どちらも有効です — "original"は正当なソースです；重要なのはライブラリを考慮したことです。
• 任意のシーン + 名前付きブランド → "leaning <ブランド> from brand-inspiration"。

次にシーンを分類し、表現的シーンには具体的なビジュアルプランにコミットする

• 表現的（ブランドサイト、キャンペーン/プロモ、ポートフォリオ、プロダクトランディングヒーロー、エディトリアル/カルチャー特集、ソーシャルカバー）：ビジュアルインパクトは仕事の一部です；正しいが安全な中央揃えのページは失敗です。
• 抑制的（ダッシュボード、管理画面、内部ツール、フォーム、政府通知、レポート、データテーブル、スペック）：明瞭さと落ち着きが仕事です；モーションは最小限に抑え、レイアウトは規則的にし、以下のビジュアルコミットメントをスキップします。

表現的シーンの場合、コーディング前に静かにコミットします — 各項目は具体的な要素+アクションであり、決して形容詞ではありません（「大胆/プレミアム/驚き/ダイナミック」は禁止、それらは何も制約しません）：

ビジュアルコミットメント（表現的シーンのみ）
1. hero_subject:   大きく/支配的にされる1つの要素（例：製品名'桂花酪酪'をビューポートの1/3、ゴールド+朱色）
2. entrance:       どの要素がどのようにアニメーションインするか（例：タイトル文字がずれてフェードイン + 花びらが上から落ちる）
3. break_symmetry: レイアウトが中央/グリッドを破る場所（例：価格タグを右下に傾け；シールが端からはみ出す）
4. focal_contrast: 最初に目を引き付けるもの（サイズジャンプ / カラーブロック / ヒーロー周りの余白）

完全に中央揃えで、対称的で、静的な、支配的な要素のないページは、デフォルトの凡庸な結果です — 表現的シーンでは、コミットメントが守られなかったことを意味します。コミットされた各項目を実行します。モーションの詳細 → horizontal-craft/animation-discipline.md。

例（インライン）

"做一个 GLM-5.1 模型介绍网站" → ポジショニング：推論/実行インフラ、汎用AIページではない；first_impression: 穏やか、正確、テクニカル；anti_default: 汎用AI-SaaSヒーロー+フィーチャーカードテンプレートを避ける。シーン：表現的 → hero_subject: "GLM-5.1"を特大で単一アクセント；entrance: タイトル+タグラインがずれてフェードアップ；break_symmetry: スペック番号を片側にオフセット；focal_contrast: 深いネガティブスペースに対する大きなタイポグラフィ。

第一段階成果物の前提

ほとんどのユーザーは高度なデザインコンテキストを提供しないと仮定します — Figmaファイル/MCP、成熟したデザインシステム、トークン、コンポーネントライブラリ、ブランドガイドラインはありません。

…

[翻訳のため省略]