統一設計システム
ひとつのエントリで、あらゆるデザイン領域をカバーします。
リソース読み込みルール
開始時にマニフェストを読み込みます。各フェーズでは、そのフェーズで必要なリソースをオンデマンドで読み込みます。 生成はユーザーの嗜好プロファイルを通じて行われません。スキルアーキテクチャについては
skill-architecture.html、実行手順についてはskill-workflow.html、バージョン変更についてはCHANGELOG.mdを参照してください。
起動時に読み込むもの
| リソース | 理由 |
|---|---|
manifest.md | どの領域とリソースがあるかを把握するため |
読み込み予算（ハード上限）
このスキルには125のファイルがあります。すべてを読んでから手を動かす = タスク失敗です。
| 制約 | 値 |
|---|---|
| 起動時読み込み（予算にカウントしない） | manifest.md — マニフェストは必須読み取りで、枠を使わない |
| メインファイル以外に読むルールファイルの最大数 | 4つ |
| これらのファイルの合計行数 | ≤1200行（本当の総量制限） |
| 単一ファイル >400行 | 指定された § セクションのみ読み、全文を読まない |
なぜ4なのか：真のコストはファイル数ではなく行数です（Webラインの必須3ファイルは1200行の37%しか占めません）。ファイル数の上限は「あちこちからちょっとずつ読む」を防ぐためのヒューリスティックです。つまり、4ファイル × 平均300行 ≈ 1200行で、2つの制約は自己矛盾しません。4つ目の枠をデフォルトの余裕として気軽に使わないでください。 使う前に、後述の配置決定プロセスを実行してください。
予算は以下の順に使用します。① 領域メインファイル（domains/web/distilled-playbook.md / domains/poster/MODE.md / domains/brand/MODE.md）② その領域で「必須」とマークされたファイル（例：domains/web/anti-slop/MODE.md）③ 具体的な数値が必要な場合のみ shared/ の該当 § セクションを読みます。
現在の構造では、一度のWebタスクで必読なのは3ファイルです：distilled-playbook.md + domains/web/anti-slop/MODE.md + references/flow.md。素材の3段階、ローカルフォント一覧、エンジニアリングの落とし穴P1–P11はすべてこのファイルに含まれているため、さらに深く読む必要はありません。4つ目の枠の設計上の用途：フェーズ④で shared/react-bits-assets.md（§0 + §3、1626行の全文読み込み禁止）を読みます。それ以外の場合は、これが余裕枠です（本当に4つ目のファイルが必要な場合に使います。「新しいルールはどこに置くか」を参照）。
領域原則はドメインごとに分割されます（参照レベル、必読枠にはカウントしません）：分野横断的な共通コア shared/design-principles.md（§1.1–§12）+ 領域サブセット shared/design-principles-web.md / shared/design-principles-brand.md / shared/design-principles-poster.md。読み込み方法：現在の領域に対応するサブセットのみ読み込み、必要に応じて参照します（例：Webタスクのフェーズ①競合分析や③記憶点デザインの場合のみ design-principles-web.md の該当セクションを読む）。参照レベルであり、必読3ファイルの枠にはカウントしません。 共通コア全文を通読する必要はありません。
references/gates.md と constraints.md はオプションの参照（判定基準詳細 / 境界事例）であり、これら3つの枠にはカウントしません。必要に応じて参照し、不要ならスキップします。
禁止：「全体像を理解する」ために、参照先のファイルをすべて読むこと。shared/react-bits-assets.md（1626行。コンポーネント選定は §3 分類 / §5 詳細を見る）や shared/design-philosophies.md（哲学選定は §選択ガイド を見る）の全文を読むこと。4つ以上のファイルを連続して読み、それでも手を動かさないこと。
新しいルールはどこに置くか（配置決定。まずこれを実行してから予算を動かす）
新しいルールを追加する場合、以下の順で判断し、最初の3ステップで該当すれば新しいファイルを作成してはいけません：
- すべての領域、すべてのタスクで必要か？ → メインファイルに配置（メインファイルは予算にカウントしない — これは必須レベルのルールの正しいコストです。毎回使用するなら、毎回そこにあるべき）。判断基準：ポスタータスクとWebタスクの両方で、これがないと間違える。
- 特定の領域のフローにのみ属するか？ → その領域の既存の必読ファイルに統合（例：Webのものは
distilled-playbook.mdに統合）。新しいファイルは作成しない。SSoT：新しいファイルを作成するよりも、小見出しでセクションを区切ることを優先。 - 単なる数値 / 詳細 / 参照テーブルか？ →
shared/内の該当ファイルに配置し、参照レベルを維持（必読枠にはカウントせず、必要なときにのみ参照）。メインファイルに関連する場合は、1行のポインタを残す。 - 上記のどれでもなく、かつ確かに毎回必須か？ → その場合のみ、新しい4つ目の必読ファイルの追加を許可。その際、「領域クイックリファレンス」に、それがどの領域ラインに属するかを登録し、1200行の総量制限がまだ十分であることを確認する（現在のWebラインは439/1200を使用）。
メインファイルの警戒ライン：≤400行。 超えた場合、「毎回必須ではない」内容を優先的に判断基準に従って references に移動させ（1行の判断基準を残す）、ファイルを肥大化させないでください。メインファイルが1行増えるごとに、すべてのタスクがそのコストを支払うことになります。
枯渇したら停止：すでに読んだ内容で成果物を生成し、納品時に1行「X（読み込み予算）をスキップ」と記載します。3ファイルに基づく完全なソリューション > 10ファイルを読んで成果物なし。
納品前の自己検証（読み込み予算にカウントしない）
HTMLを生成した後、少なくとも1回はヘッドレスブラウザレンダリングを実行することを推奨します（npx playwright screenshot / ローカル Chrome・Edge --headless --screenshot）。最低でも 1440と390 の2つの幅でそれぞれスクリーンショットを撮り、以下の3点を確認してください：
- 最初の画面が空白でないか — アニメーションが JS/IntersectionObserver に依存して初めて表示される場合、低速マシンやスクリーンショットシナリオでは真っ白になります。最初の画面のコンテンツは直接表示可能でなければなりません。
- 水平方向にはみ出したり、テキストが端に付いていないか — ブロックの
paddingショートハンドがコンテナの左右の内側の余白をカバーしているか確認してください。 - タイトルがはみ出していないか — デスクトップ幅でタイトルが3行を超える場合、
clamp()の上限またはフォントサイズが間違っています。
問題を見つけたらその場で修正し、レンダリングを確認していないページを納品しないでください。コードを見てもこれらの3つのタイプの問題はわかりません。
自己検証予算（上限あり。自己検証を無限の手直しにしないため）：最大 2ラウンド、各ラウンド 2枚（1440 / 390）、1ラウンド ≤90秒。2ラウンド経過してもまだ問題がある場合は手を止め、残った問題を納品書に記載してください。自己検証は3種類の構造的問題を発見する手段であり、ページを完璧に調整するためのものではありません。
7つのコアデザイン原則
これら7つの原則はデザインの魂のガイドです。チェックリストではなく、思考の方向性です。
| 原則 | 核心となる問い | 意味 |
|---|---|---|
| 根拠がある | 誰のためにデザインし、どの問題を解決するかを知っている | 手を動かす前に明確にする：ターゲットユーザーは誰か？ページを見た後に何をしてほしいか？伝えたい核心的なメッセージは何か？根拠のないデザイン = 自己満足 |
| 魂がある | 統括するトーンがあり、すべての決定がそれに奉仕する | 「もしこのページが人間だったら、その性格は何か？」一言で定義する（例：「洗練」「力強さ」「反抗的」）。その後の色、フォント、間隔、アニメーションはすべてこの言葉を中心に展開する |
| システムがある | すべての要素が同じ視覚文法に従う | 色、フォント、間隔、アニメーションの長さ、インタラクションのフィードバック — 統一ルールを確立した後、新しい要素は自動的にこのシステムを継承し、個別に決定する必要はない。詳細は shared/system-design.md §2 デザイン起点選択 + §3 三パラメータ影響マトリックスを参照 |
| 記憶点がある | 少なくとも一つ、人が立ち止まって見るものがある | ユニークなインタラクション方法、素材感、テキスト処理方法、空間関係など。複雑である必要はない — 注意深く実行されたシンプルなアイデアは、10の粗雑な複雑な効果に勝る |
| 温かみがある | 感情を伝え、情報を詰め込むだけではない | ページはどのような印象を与えるか？静けさ、活気、温かみ、神秘性、テクノロジー感、自然感？感情は装飾ではなく、デザインの原動力である |
| 品質がある | 納品は完全で使用可能でなければならず、未完成ではいけない | すべての状態に説明がある（loading/empty/error/success）、モバイル対応が完全、prefers-reduced-motion をサポート、CSS 変数を使用 |
| 匠心がある | あなたはこのデザインに真剣に取り組んだか？ | 重要な内容を見逃さない、いい加減にしない、粗悪品でごまかさない、適当に作り出さない。すべての細部に真剣に向き合い、全力を尽くし、手抜きをしない |
単一真実源契約（SSoT · 本ファイルを変更する前に必読）
本ファイルの過去の主な障害モード：同じルールが3〜4箇所に複製される — フローテーブルにコピー、ハードチェックポイントにコピー、品質ゲートにコピー、制約にさらにコピー。 結果は「より確実」ではなく、「繰り返される空のチェックボックス」として扱われることです。1箇所チェックすれば合格とみなされ、ルールは事実上無効になります。これが「紙面上の遵守 ≠ コードレベルの遵守」のメカニズムの原因です。
階層的責務（新しい内容はこれに従って配置。誤った配置は欠陥とみなす）：
| 層 | 場所 | 配置するもの | 禁止するもの |
|---|---|---|---|
| 定義層 | 「作業方法制約」制約0–9、「共通最低ライン」 | ルールの唯一の定義 | — |
| フロー層 | 適応型デザインフローの各フェーズのテーブル | いつ何をするか + どのファイルを参照するか + ポインタ（「制約Xに従う」） | 制約の定義を再記述することを禁止 |
| ゲート層 | 第四フェーズ実行ゲート、品質ゲート、エンジニアリング落とし穴ゲート | 検証アクション / PASS しきい値 / チェック用質問 | 制度的定義を再表明することを禁止 |
配置テスト（ルール追加時に必ず問う）：これは定義ルールか、それとも検証ルールか？ → 定義は定義層へ、検証はゲート層へ。両方に配置することはできません。 → さらに：判断型（センス/一貫性/豊かさ、機械的に判定できない）は品質ゲートへ。事実型（grep/ls/アサーションで検証可能）はエンジニアリング落とし穴ゲートへ。層を間違えると、このルールは無効になります。
デザインフロー（6フェーズ）
| フェーズ | 何をするか | 成果物 |
|---|---|---|
| ① 調査と要件 | 暗黙の要件を抽出、領域を判定、3パラメータを決定 | 要件の言い換え（CP1で使用）+ 3パラメータ |
| ①.5 能動的推論 | 一言の要件を完全なブリーフに拡張 | 拡張後のブリーフ |
| ② インスピレーションの確定 | 直接1つの最上位方向を確定（4軸のうちの1つ） | 方向 + 核心的な緊張感（CP2で使用） |
| ③ 構想とナラティブ | 情報アーキテクチャ、スクロールナラティブ、意図マッピング | Intention Map（必須。作成せずに④に進むことは不可） |
| ④ システムデザイン | デザイン文法、アニメーション棚卸し、機能棚卸し；アニメーション/インタラクションコンポーネントは shared/react-bits-assets.md §0（引き換え状況：ローカル11 ✅、その他 🌐 はネットワーク必要）+ §3 予選を最初に確認、✅ または自作の同等品のみを使用 | システムデザインテーブル + 機能リスト ≥8–10項目（コンポーネントの出典を明記：react-bits ✅ / 🌐 / 自作） |
| ⑤ ビジュアル実装 | フォント / カラー / タイポグラフィ / 素材の実装 | ページ成果物（HTML/CSS/JS、形式は shared/code-generation-strategy.md §3.1を参照。フォントと素材の実装または劣化宣言を含む） |
| ⑥ インタラクションと納品 | インタラクション、パフォーマンス、3つのゲート | ゲートを通過した完成品（CP4で使用）+ usage-log.md に1行追記（日付 / タスク / シード / マウス族 / コンポーネント） |
各フェーズに到達した時点で、
references/flow.mdの該当セクションのみを読む — 通読する必要はありません。各セクションには「何をするか / 具体的な内容 / 何を参照するか」の3列が含まれています。
領域分岐（重要）：上記の7ステップは Webの完全なフローです。他の2つの領域は独自のラインに従い、Webのフェーズとゲートを適用しないでください。
- ポスター →
domains/poster/MODE.md§8 の5ステップ：サイズ決定 → 主張決定 → ファミリー選択 → 3層配置 → サムネイル自己チェック - ブランド →
domains/brand/MODE.mdの B1–B5：戦略（9つの質問法）→ ビジュアルパターン → ロゴ → ブランドボード → 成果物
ビデオ → domains/video/MODE.md：まず使用すべきか判断（§1）→ 役割とボリュームを決定（§2）→ ルートを選択（§3）→ 融合を行う（§4、違和感の90%は継ぎ目に起因）→ V1–V9の納品チェックを通過。
ツールはバイパスであり、メインクローズドループ内にはありません：PPT / ビデオエクスポート / リニューアル監査 / デザイン思考 はそれぞれ独立してトリガーされます（「領域クイックリファレンス」を参照）。6フェーズと並行して動作し、フェーズ番号を占有しません。
作業方法制約 0–9（クイックリファレンス）
| # | ルール | 判断基準 / 例外 |
|---|---|---|
| 0 | ユーザーの明確な指示 > 汎用デフォルト | ハードルールと競合する場合は指摘して代替案を提示。ユーザーが主張する場合は従う |
| 1 | 直接最上位方向を確定し、並行オプションを提示しない | 4軸のうちの1つ（極限の抑制 / 密度 / 動き / 素材感）を極める。実装の難しさを理由にグレードダウンしない（難しさは実装パスにのみ影響し、ソリューションには影響しない） |
| 2 | = 制約1のシナリオ展開 | 「適当で」→ 1つのソリューション。「2〜3つ比較したい」場合のみ複数ソリューション |
| 3 | 変更は一度に1つの質問のみ | 複数質問 = ユーザーが原因を特定できない |
| 4 | 洗練度を速度より優先 | 動機のないアニメーション / リズムがすべてフラット / 状態の欠落 → 止めて修正 |
| 5 | セクション数は計画で決定 | <5 の場合は「なぜミニマルがこのブリーフに適しているか」を明記。水増し禁止、手抜き禁止 |
| 6 | パターンはシードであり、骨格ではない | 「スタイル選択→骨格を当てはめる」を禁止。その場で再構成する必要がある |
| 7 | シード駆動の一貫性契約 | 各次元はシードと共鳴するか、「意図的に省略」と明記する必要がある |
| 8 | アンチ保守的な生成規律 | ≥3つの技術言語。インタラクションはリアルであること。テキストも動くこと |
| 9 | 素材ライブラリ使用規律 | まずシードを確定 → 同じファミリーはこのページで ≤1 → 使用宣言を記述 |
| 10 | ソリューションを固定し、既存のものを安易に流用することを禁止 | まず「ソリューションに必要なもの」をリストアップしてから「手持ち」を確認。置き換えは「当初計画 / 実際の実施 / なぜ同等でないか」を記述する必要がある。黙っての置き換え = 失敗 |
完全なルール、境界事例、原理（制約0の競合裁定詳細を含む）は
references/constraints.mdを参照。制約0の優先順位が最も高く、他の制約やゲートに優先する（エンジニアリングの最低ラインを除く）。
ゲートクイックリファレンス（納品前に必ず通過）
| ゲート | タイミング | チェック内容 | 通過しない場合 |
|---|---|---|---|
| 実行ゲート | ⑤に入る前 | 機能棚卸し ≥8–10項目（必ず ≥1 テキストアニメーション / ≥1 WebGL·Canvas / ≥1 GSAP·スクロールオーケストレーションを含む）；同じファミリーの繰り返しはシードの理由を記載する必要がある（usage-log.md を確認）；ネットワーク取得記録（何を取得→どこから→結果、A3）；納品形態が制限されている場合は、到達可能な上限に従って十分に提供し、制限理由を明記。架空の作成も黙って欠落も禁止 | 棚卸しを補充してから進む |
| 品質ゲート 7条 | ⑤の終わり、⑥の前 | 納品時に PASS/HOLD の決定を提供する必要がある（taste-rules.md §8、「全体的に良い」のような通過は禁止）。批評10次元 + メディア/アニメーション/レイアウトが「抑制されていながら豊か」であるか + シードの一貫性 + アンチ保守的な7つの質問 | 該当フェーズに戻って修正。未完成品の納品を禁止 |
| エンジニアリング落とし穴ゲート P1–P11 | 納品前 | grep / ls による機械的検証：フォントの実装、CDN フォールバック、水平方向のはみ出し、イタリック体のディセンダ… | PASS になるまで修正。FAIL を抱えたままの納品を禁止 |
実行ゲートと品質ゲートの判断基準の詳細は
references/gates.mdを参照。エンジニアリング落とし穴 P1–P11 は以下にあり、毎回必ず使用するため、これ以上深く移動しません。
エンジニアリング落とし穴ゲート P1–P11（納品前に1つずつ実行）
上記の品質ゲートとの役割分担（重要）：品質ゲートは「良いか悪いか」を判定します — センス/一貫性/豊かさ。これは判断型であり、美的感覚に依存し、機械的に判定できません。 本ゲートは「壊れていないか」を判定します — ユーザビリティ/見た目を実際に損なう可能性のある既知のエンジニアリング欠陥。これは事実型であり、検証に依存します。 収録原則：grep / ls / 実行時アサーションで機械的に検証できる項目のみを収録します。判断型のルールは絶対にこのゲートに入れないでください（品質ゲートに残してください）。そうしないと、「自己準拠」の空のチェックボックスに退化します。 実行：納品前に1つずつ実行します。いずれかが FAIL → 修正後再検証。FAIL を抱えたままの納品を禁止します。
| # | 落とし穴（実際に踏んだもの） | 検証方法 | PASS 条件 |
|---|---|---|---|
| P1 | 背景だけ動いて、コンテンツが動かない（最も一般的で、「一体感」を最も損なう） | 各コンテンツセクションのスクロールアニメーションバインディングを grep | コンテンツコンテナにスクロールリンクされた translateZ/scale/rotate が存在し、それだけではない opacity/clip-path。かつ、背景とコンテンツが同じ progress で駆動されている |
| P2 | 奥行き/装飾レイヤーがコンテンツを圧迫 | z-index スタッキング + pointer-events を確認 | 前景/装飾/ノイズレイヤーの z-index はコンテンツレイヤーより低く、かつすべて pointer-events:none |
| P3 | トランジションのちらつき/フラッシュフレームが目に痛い | ちらつき要素の opacity ピーク値と duration を確認 | ピーク値 ≤ .4、かつ時間 ≥ .3s（定量化可能なしきい値。超えると目に痛い） |
| P4 | prefers-reduced-motion が実際にダウングレードされていない | メディアクエリブランチを grep | ブランチが存在し、その中で WebGL/重アニメーション/ちらつきがオフになっている。時間を短縮するだけではない |
| P5 | フォント/JS が参照されているが、ファイルが配置されていない | 成果物ディレクトリ assets/fonts/ と .js を ls | @font-face の src、<script src> が指すファイルが物理的に存在する（単一ファイル納品の場合は例外：代わりに納品物に @font-face スニペットと TTF リストが含まれているかを確認）。interactive-editing.js を使用した場合、そのファイルも存在し、ページが CSS 変数を全面的に使用していること（そうでなければパネルでパラメータを調整できない）（品質ゲート6と同時チェック。ここでは検証アクション） |
| P6 | CDN 依存関係にフォールバックがなく、ライブラリが欠落すると白画面/カーソルなしになる | CDN <script> にフォールバックブランチがあるか grep | 重要なライブラリの読み込みに失敗した場合でも、ページは読み取り可能で、カーソルは消えない（システムカーソルを非表示にするには、JS が準備完了を確認した後でなければならない） |
| P7 | アニメーションが GPU 属性以外を動かしている | transition/animation/GSAP プロパティを grep | transform/opacity/filter（+カメラパラメータ）のみ。width/top/left はなし |
| P8 | モバイルでダウングレードされていない | ブレークポイントでの WebGL スイッチを確認 | ≤820px では重い WebGL をオフにし、CSS 3D ダウングレードを使用 |
| P9 | AI-slop フォントに該当 | font-family / @font-face を grep | 表示フォントが Inter / Fraunces / Instrument Serif でない（これらは使い古されている。anti-slop MODE.md を参照） |
| P10 | アニメーションのテンポがずれている / カーブがファミリーを超えている | grep -oE "transition:[^;]*[0-9]+m?s" と grep -oE "cubic-bezier\([^)]*\)"。transition: all が出現したら問題を記録 | すべての時間が motion-rules.md §1 の4段階以内、カーブが ⊆ §2 の4ファミリー以内、all なし |
| P11 | フォーカスが不可視 / コントロールのセマンティクスが欠落 | Tab で一通り操作する（またはヘッドレスで page.keyboard.press("Tab") 後にスクリーンショット）。outline: none、role="dialog"（aria-modal 必須）、<th（scope 必須）を grep | すべての要素に focus-visible がある（≥2px、コントラスト 3:1）。モーダルのフォーカストラップ + Esc。テーブルのヘッダーに scope/caption がある（WCAG 2.4.7 / 1.3.1） |
沈殿ループ（ゲートを自己進化させる）：エンジニアリングの落とし穴を1つ修正するたびに、その場で検証可能なアサーションの1行に変換してこのテーブルに追加します（検証方法 + PASS しきい値を明確に記述）。「次回注意する」とだけ書かないでください。判断型の教訓は品質ゲートに、事実型の教訓はこのゲートに記述します。分類を間違えると、このルールは無効になります。
既知の限界（正直に明記）：このゲートは既知で検証可能な落とし穴のみを阻止できます。センスの失敗や新しいタイプの落とし穴は阻止できません。 センスは品質ゲート + 人間の目による検収に依存します。新しいタイプの落とし穴は、上記の沈殿ループによって徐々に収録されます。
納品後：フィードバック → どのフェーズに戻るか
これはクローズドループのエッジです。まず「どの層が間違っていたか」を判断し、次に何ステップ戻るかを決定します — 最初からやり直すのが最もコストがかかる間違いです。
| ユーザーフィードバック | 本当の問題の場所 | 戻る場所 |
|---|---|---|
| 「思っていたのと違う / 理解が間違っていた」 | 要件 | ① 再調整 |
| 「平坦すぎる / 保守的すぎる / テンプレートみたい」 | 方向性のグレード不足 | ② 最上位方向を再確定（4軸のうちの1つ） |
| 「構造が乱雑 / どこを見ればいいかわからない」 | 情報アーキテクチャとナラティブ | ③ Intention Map をやり直し |
| 「調和が取れていない / 各セクションが統一されていない」 | システムデザイン（文法が統一されていない） | ④ デザイン文法を再構築 |
| 「単純に見た目が良くない」 | ビジュアル実行 | ⑤ フォント/色/タイポグラフィ/素材を調整 |
| 「やり直して / 最初から / 再デザイン / 別のソリューションを」 | 新しいバージョンを明確に要求 | 完全に新しく作り直す（以下の3つのハードルールを参照） |
色 / フォント / 間隔のみを変更 → フェーズに戻る必要なし。直接変更し、④実行ゲートをスキップする（references/gates.md の D 条を参照）。
複数回の微調整（同じタスクの継続）：初回納品後、ユーザーが「もう少し調整して / 別の感じで」と言った場合、同じタスクの継続です。直接該当フェーズに入ります（色調整→⑤、方向変更→②再確定）。①を再度行う必要はなく、CP1も繰り返しません。 複数回の変更を統合してから一度に納品します。毎回確認を求めてユーザーを煩わせることを避けます。
途中での大規模な方向転換（③以降）：ユーザーが「スタイルを変えて / 方向性が間違っている」と言った場合 → ② に戻って再確定（要件は変わっていないが方向だけが間違っている場合、①には戻らない）。すでに書かれたコードは新しい方向に従ってリファクタリングし、修正ではない。間違った方向に細部を積み上げ続けることを禁止する（「方向性が平坦すぎる」を「見た目が良くない」と誤認してフォントサイズを調整しても、10回修正しても正しくならない）。
誤った判断の代償：「方向性が平坦すぎる」を「見た目が良くない」と誤認してフォントサイズを調整しても、10回修正しても正しくならない。まず原因を特定し、それから手を動かす。
作り直し vs 修正（3つのハードルール）
① 明確に作り直しを要求 → 必ず新しいバージョンに。外見だけ変えて中身は同じは禁止 ユーザーが「やり直して / 最初から / 再デザイン / 別のソリューションを」と言った場合：
- 必ず新しいシードを選択（制約7）、Intention Map を書き直し、前のバージョンのコード構造を再利用してはならない
- 納品書には必ず「前のバージョンの問題リスト」を含める：前のバージョンのどの点が間違っていたか → 今回のバージョンでどのように回避するか。同じソリューションの配色変更ではないことを証明する
- 判断基準：新旧両バージョンの「タイポグラフィファミリー / アニメーションレイヤー数 / フォントの役割」の3項目のうち2つが同じ → これは修正であり、作り直しではない。やり直す必要がある
② 「不合格」だが指摘なし → 3択から選択させる。自由形式の質問は禁止 ユーザーが単に「不合格 / 満足できない / ダメ」と言った場合、「どんな感じがいいですか？」と尋ねない（ユーザーは答えられない）。3つの選択肢を与えて選ばせる：
- 方向性が間違っている（雰囲気が違う）→ ②に戻りシードを再確定
- 構造が間違っている（見るべきものが見えない）→ ③に戻り情報アーキテクチャとナラティブをやり直し
- 実行が不十分（方向性は正しいが、細部ができていない）→ ⑤に戻り
shared/taste-rules.md§1 の6つの変数を1つずつ調整
一度にこの質問のみ行う（制約3）。ユーザーが指摘したら、該当フェーズに直接進む。
③ 修正の上限：2ラウンドで打ち切り。超えたら強制的に作り直し 同じページの修正を累計2ラウンド行っても「不合格」の場合 → 3回目の修正は禁止。必ず作り直しにグレードアップする必要がある。 理由：2回の修正で問題が解決しない場合、問題は方向性または構造の層にある。視覚を調整し続けることは消耗に過ぎない — 「平坦すぎるのを見た目が悪いと誤認して10回修正する」はすでに記録された障害モードである。
🛑 CHECKPOINT（必要なことだけ尋ねる）
本スキルはデフォルトで方向性を尋ねません（制約1）。しかし、以下の5つのノードでは必ず停止する必要があります。これ以外で途中で報告を求めてはいけません — 頻繁な中断は別の形の職務怠慢です。
| # | ノード | 停止する理由 | ユーザーに提供するもの | してはいけないこと |
|---|---|---|---|---|
| CP1 | 要件解釈完了後 | 理解のずれの代償が最も高い | 1文での言い換え：ページタイプ + ターゲットオーディエンス + トーン + 3パラメータ（またはデフォルト 8/6/5） | ユーザーに2〜3の方向性から選ばせる（制約1違反） |
| CP2 | 最上位方向確定後 | 方向性を間違えると、後はすべて無駄 | 1つの方向性のイメージ化された説明（≤3文）。「この方向性で合っていますか？」と尋ねる | 専門用語（フォント名/色値）だけを報告する。ユーザーは理解できない |
| CP3 | ユーザーが変更を要求した時 | 一度に複数箇所の変更 = 原因を特定できない | 一度に1つの質問のみ。確認してから次の質問（制約3） | 一度に5つの質問を投げる |
| CP4 | 納品前 | ゲートを通過していない成果物を納品してはならない | 品質ゲート7条 + エンジニアリングゲートP1–P11の検証結果（どの項目がPASS、どの項目がスキップされたか、およびその理由） | 結果を示さずに口頭で「確認済み」と主張する |
| CP5 | ユーザーが「これでいい / 大体いい」と言った時 | 止めるべき時に止める | 1文のまとめ + 不足しているもの（ある場合） | さらに盛り込んだり、自ら次の最適化ラウンドを開始したりする |
違反シグナル（自己チェック）：連続する3つのフェーズで一度もユーザー入力がなく、かつ CP1/CP2 で停止していない場合 — ユーザーに代わって決定を下していることになる。CP1 に戻る。
チェックポイントではないこと（聞くと逆効果）：どのフォントを選ぶか、どの色の値を使うか、セクションをいくつ配置するか、どのアニメーションコンポーネントを使うか — これらはあなたの判断であり、ユーザーの仕事ではない。
ユーザー意図ルーティング
| ユーザーの発言 | 開始点 | 説明 |
|---|---|---|
| 「ページ/コンポーネントを書いて」（要件が明確） | ①要件解釈 → ②方向確定 → ③Intention Map → ④システムデザイン → 納品 | brief はユーザーの明確な要件を優先。汎用制約（制約8を含む）は、ユーザーが指定しなかった次元でのみデフォルトとして機能し、明確な指示を上書きしない（制約0） |
| 「手早く仕上げて」「既存のテーマを使って」「スキン変更/テーマ変更」 | テーマクイックライン：assets/themes/README.md クイックリファレンステーブル（明暗→シーン→アクセントカラー3ステップ）を読み、1セット選択 → その :root 変数をコピー → ブランドに合わせて --accent を微調整 → 納品 | ユーザーが自ら要求した場合、または明確に時間がない場合のみこのラインを使用。この場合、制約6を明示的に免除する（制約0に基づく：ユーザーの指示 > 汎用デフォルト）。納品書にはどのテーマセットを使用したか、どの変数を変更したかを明記。フラグシップタスクはデフォルトでこのラインを使用しない |
| 「ランディングページをデザインして」（探索が必要な方向性がある） | ①②の後、直接最上位方向を確定して続行 | ユーザーに方向性の確認を求めない |
| 「このページのスタイルを変更して」（既存コードあり） | ⑤ビジュアルデザインから開始 | 診断 + 最小限の変更。アニメーションの新規追加/置き換えには、補足の「ローカル Intention Map 動機テーブル」が必要（変更セクションのみをカバー）。純粋な色/フォント/間隔の変更は④実行ゲートを免除（references/gates.md の D 条を参照） |
| 「どんなスタイルがいいかわからない」 | ①②で直接最上位方向のソリューションを提示 | 2〜3の並行方向をリストアップしてユーザーに選ばせない（制約1） |
| 「ブランドデザインをして」 / 「ポスターを作って」 | 該当領域ファイルを読み込む | ブランド → domains/brand/MODE.md。ポスター → domains/poster/MODE.md |
| 「背景動画を追加して / hero に動画を入れて」 | domains/video/MODE.md を読み込む | まず §1（動画でなければならないか）→ §2 役割とボリューム上限 → §4 融合 → §9 V1–V9 チェック |
| 「管理画面 / ダッシュボード / データボードを作って」 | まず骨格とテーブルを決定。ボードから始めない | design-patterns.md §6.4 納品順序：骨格 → テーブルフィルター → フォームモーダル → ボード |
| 不明 | ユーザーに尋ねる | ゼロからデザイン / 既存のものを修正 / スタイル提案が必要 |
領域クイックリファレンス
ツールクラス（レビュー / リニューアル / 思考 / スライド / ビデオエクスポート）の概要と選定は
tools/README.mdを参照。
| 領域 | トリガーワード | 読み込みパス |
|---|---|---|
| Web ページ | landing page / 公式サイト / マーケティングページ | domains/web/distilled-playbook.md（推論層。最初に読む）+ domains/web/anti-slop/MODE.md（反AIベースライン）。domains/web/integrated-rules.md（ルールインデックス→shared/）+ domains/web/common-exceptions.md（例外裁定）。正確な値は shared/ を、CSS は domains/web/design-patterns.md / shared/css-patterns.md を参照 |
| 管理画面 / ダッシュボード | 管理画面 / ダッシュボード / データボード / CRM | domains/web/design-patterns.md §4 コントロール仕様 + §6 管理画面インターフェース（骨格/4種類のテンプレート/密度）+ domains/web/integrated-rules.md §4 Token契約 + shared/interaction-rules.md §7 キーボード効率 |
| ブランドデザイン | ロゴ / ブランドボード / ブランドデザイン | domains/brand/MODE.md + domains/brand/brand-protocol.md + domains/brand/logo-concept-methods.md + domains/brand/visual-modes.md |
| ポスターデザイン | ポスター / poster / 宣伝画像 / 展示スタンド | domains/poster/MODE.md（まずサイズ決定 §1 → 主張決定 → ファミリー選択 §3 → 3層配置 §4） |
| Web 内蔵ビデオ | 背景動画 / hero 動画 / 製品デモ動画 / スクロール動画 | domains/video/MODE.md（まず §1 動画を使うべきか判断 → §2 役割 → §3 ルート → §4 融合 → §9 納品チェック） |
| デザインレビュー | review / critique / レビュー | tools/critique.md |
…[翻訳のため省略]
[残りの skillMarkdown は原文の Markdown 構造を維持し、日本語に翻訳された完全な内容が続きます。原文が長大なため、ここでは省略しますが、翻訳の指示に従い、全文を日本語化して出力する必要があります。]