uplift

stardust:uplift

1 つのエントリーポイント。1 つの URL。プリセールス品質の再デザイン案を 3 種類。

uplift は、extract → direct → prototype × 3 の流れを、すべての可変要素をユーザーに尋ねるのではなく、取得したブランドの表層から選ぶ、単一の独自判断型コマンドにまとめます。出力は長い手順と同じです（state.json、brand-review.html、提案ファイル 3 つ、モーション検証）。ユーザーはその調整を行う必要がありません。

独自判断型のデフォルト

• 1 ページのみ抽出 — --page <slug> で上書きしない限り、デフォルトではホームページ（ブランドオーナーが最初に見せる表層）を対象にします。
• ブランドに忠実な Mode A — カラーパレットとタイポグラフィを固定します。新しい色を考案せず、取得した表層にないフォントも使用しません。
• 3 つのバリエーション、固定の役割契約 — A は承認を得る案、B はデザインチームの意欲をかき立てる案、C は先見的でシネマティックな提案です。
• シネマティックな表現を自動選択 — C のモーション表現は、取得した PRODUCT.md の Brand Personality に基づき、../prototype/reference/motion-registers.md § Selection heuristic に従って選択されます。
• 「What if...」候補はエビデンスに基づく — B と C はそれぞれ、取得済みだが十分に活用されていない特性を 1 つ選びます。reference/what-if-candidates.md にある 8 つの具体例から選ぶか、§ Extension rule に従って候補を導出します。バリエーションごとに異なる特性を選びます。
• 検証カスケードを実行 — prototype/SKILL.md の Phases 2.5～2.8 にあるすべてのゲートが実行され、バリエーション C ではシネマティックな Pass 6 も含まれます。

入力

• <URL> — 必須です。再デザインするページです。URL にパスがない場合は、ホームページがデフォルトになります（https://example.com/ → ホーム）。
• --page <slug> — 任意です。URL が別のページを指している場合、またはユーザーが別の表層を希望する場合に、スラッグを上書きします。
• --cinematic-register <name> — 任意です。バリエーション C に自動選択された表現を上書きします。arrival、kinetic-display、live-systems、editorial、kinetic-grid のいずれかを指定します。C の由来情報に registerSource: "user-override" として記録されます。
• --two-variants — 任意です。A と C のみをレンダリングし、B を省略します。ブランドの表層が薄く、3 案を無理に差別化すると中間案が弱くなる場合に便利です（下記の停止条件に従います）。
• --re-extract — 任意です。同じ URL の以前の抽出が 7 日未満であっても、新たにクロールします（§ Setup の reuse-if-fresh を参照）。

これ以外のフラグはありません。それ以外のすべては、取得したブランドの表層から導出されるか、基盤となるスキルの契約によって定められます。

セットアップ

1. マスタースキルのセットアップを実行します（../stardust/SKILL.md § Setup）：依存関係を厳密に確認し、コンテキストを読み込み、状態を読み取ります。
2. Playwright が利用可能であることを確認します（利用できない場合、extract は失敗します。extract が表示するものと同じインストールメッセージを表示します）。
3. 存在する場合は stardust/state.json を読み取ります。新しければ再利用： 同じ URL の以前の抽出から 7 日未満の場合、Phase 1 を省略し、既存の取得データに対してレンダリングします。その際、1 行で通知します（「 の抽出を再利用しています。新たにクロールするには --re-extract を指定してください」）。--re-extract を指定すると、経過日数にかかわらず新たにクロールします。7 日以上前の抽出は、確認を求めずに再抽出します。

手順

6 つのフェーズに、参照情報に基づく中間フェーズを加えて実行します。Phase 1、4、5 は既存のスキルに委譲し、Phase 2、2.5、3、6 は uplift が担当します。

フェーズ 1 — 抽出（stardust の extract スキルに委任）

$stardust extract <URL> --single を呼び出します（単一ページモード）。 extract の担当範囲：

• 標準の待機レシピを使用した、Playwright によるライブレンダリング。
• stardust/current/_brand-extraction.json（パレット＋タイポグラフィ＋モチーフ＋ブランドの語り口＋システムコンポーネント＋写真）。
• stardust/current/pages/home.json（ページごとの全キャプチャ）。
• 緊張関係の検出機能を適用した stardust/current/brand-review.html — フェーズ 2 の重要な入力です。
• stardust/current/PRODUCT.md と DESIGN.md（記述的な内容 — 目標ではなく現状）。

uplift は 1 ページを超えてクロールしません。単一のホームページから得られるブランドの表層情報で 3 種類のバリエーションには十分です。複数ページの抽出には stardust の extract スキル（--single を付けないもの）を使用します。

フェーズ 2 — 緊張関係と特性の特定（uplift の担当）

stardust/current/brand-review.html の § Tensions surfaced と _brand-extraction.json を読み込みます。次の 2 つの成果物を作成します。

2a — stardust/uplift-improvements.md

キャプチャしたサイトで確認された具体的な弱点を 3 つ以上 記載します — 根拠が裏付ける限り、数に上限はありません。既存のプリセールスワークフローと同じ重要な契約です。具体性がなければ、「改善する」という主張には根拠がありません。カテゴリタグは、根拠が裏付ける場合、複数の項目で繰り返し使用できます。

• [dated-pattern] — デザインの世界では時代遅れになったパターン（具体的に：「ストック写真＋2 つの CTA をメインの青で配置した中央揃えのヒーローは、2019 年頃の SaaS テンプレートに見える」）
• [ia-clutter] — 情報アーキテクチャの煩雑さ／不明瞭な階層構造／弱い CTA／重複するセクション
• [contrast-or-density] — コントラストの問題、アクセシビリティの不足、情報密度の問題
• [cliché] — ブランドらしさを保ちながら、脱却できる慣習
• [missed-opportunity] — キャプチャした画面が、独自の強みを活かしきれていない（「撮影された写真は優れているのに、レイアウトではサムネイルサイズにトリミングされている」）

具体性の基準 — すべての項目に適用。 各項目では、キャプチャの測定値、緊張関係 ID、またはスクリーンショットで確認できる事実を引用し、問題のパターンを明示して、具体的な修正案を 1 つ提示します。この基準を満たさない項目は、内容を水増しせず削除します。

監査結果の活用。 このオリジンの stardust/audit/<domain-slug>/audit.json（stardust の audit スキルが作成）が存在する場合、デザインに関する指摘を一から導き出すのではなく、改善候補として活用します。項目の根拠に指摘 ID を記載し、readArtifacts に監査ファイルを追加します。

具体的な弱点を 3 つ未満しか挙げられない場合は、続行を拒否します（§ Stop conditions を参照）。

形式（stardust の他の部分で使用されている来歴の形式に合わせます）。

---
_provenance:
  writtenBy: stardust:uplift
  writtenAt: <ISO-8601>
  againstInput: <URL>
  readArtifacts:
    - stardust/current/_brand-extraction.json
    - stardust/current/pages/<slug>.json
    - stardust/current/brand-review.html
---

# Improvements — <URL>

1. **[<category-tag>]** <one-line headline> — <measurement /
   tension ID / screenshot observation> · <pattern at fault> ·
   fix: <one concrete fix>.
2. **[<category-tag>]** … (≥ 3 items; tags may repeat)

各弱点の前に付ける角括弧のタグは、上記のリストにあるカテゴリです。見出しは、バリエーション A の形状ブリーフで修正を適用する際に、エージェントが言い換える 1 文の要約です。

2b — stardust/uplift-questions.md

取得したブランドの特徴から導き出した、「もし〜を強調したら」という候補を6〜8個挙げます。各候補には、具体性を裏付ける取得済みの根拠を引用します。候補は reference/what-if-candidates.md のカタログから選びます。このカタログにある8つの実例は、最低ラインであり、上限ではありません。

1. ディスプレイ書体の強調
2. 写真の再前景化
3. ライブデータの昇格
4. 特徴的なジェスチャーの拡張
5. 音声レジスターの転換
6. カラーレイヤーの重み付け変更
7. オーディエンスへのルーティングの再構成
8. モチーフの語彙の入れ替え

カタログ外の派生候補は、カタログの項目と同じ根拠の形を備えている場合に採用できます。つまり、取得済みの引用が2件以上あり、明示的な不採用テストがあり、さらに候補が担うバリアントの役割（reference/what-if-candidates.md § 拡張ルールに準拠）が示されている必要があります。候補リストには、各候補の出典（catalog | derived）を記録します。

エージェントが生成する候補ごとに、「もし〜したら」という1行の表現、候補の具体性を裏付ける取得済みの根拠、最も適したバリアントの役割（Bの構成上の賭けか、Cのシネマティックな賭けか）、そしてその候補がこのブランドに不適格かどうかを記載します（例：「写真の再前景化は不適格 — 取得した写真は汎用的なストック素材であり、強調すると弱点が露呈する」）。

不採用の判定により、エージェントがどのブランドにも反射的に同じ候補を選ぶことを防ぎます。

Phase 2.5 — 参考資料による根拠付け（uplift が担当）

参考資料の調査が利用できる場合（いつ実施するか、参考資料の予算3〜5件、根拠の形式、出典の記録方法は skills/stardust/reference/reference-research.md に定義されています）、Phase 3で方向性を選ぶ前に、Phase 2の主張を実例となる参考資料で根拠付けします。

(a) uplift-improvements.md 内の各 [dated-pattern] の主張を、パターンが属する分野の現在の方向性を示す、名前を明記した現代の反例で根拠付けます。パターンの世界がどこへ移行したかを示す、実際のサイトまたは画面を引用します。 (b) バリアントBの構成上の賭けを、構成がその賭けに似ている実際の画面を挙げて根拠付けます。 (c) Cで選んだレジスターを、その分野で実際に使われているモーションと照合して検証します。そのレジスターは、この種のブランドに関する現代の実践で観察されるものと一致していますか？

各根拠付けに使用した参考資料は、reference-research.md の出典記録の規約に従って記録します（根拠付けの対象となる成果物の _provenance.referencesUsed[]）。参考資料の調査を利用できない場合は、その出典記録に1行で注記してスキップし、次に進みます。このフェーズは、支障なく省略できます。

このフェーズが、取得済みの根拠を重視する原則に取って代わることはありません。参考資料は変更を正当化し、取得済みの根拠は特徴を正当化します。 変更がどれだけ多くの参考資料で裏付けられていても、取得済みの引用がない候補は採用できません。

Phase 3 — 3つのバリアントの方向性を選ぶ（uplift が担当）

デフォルトは3つのバリアント（A + B + C）です。--two-variants が有効な場合は、§ 3c（Bの候補選択）をスキップし、§ 3dで作成する direction.md にはA + Cのみを記載します。その後、Phase 4ではプロジェクトのルートに DESIGN-A と DESIGN-C のファイルのみを書き込み、Phase 5ではそれに応じてレンダリングします。以降のすべての規約（バリアントの差別化、Cのモーション検証、Phase 6の要約）は、変更せずに縮小されたバリアントセットに適用されます。

3a — バリアントCのシネマティックなレジスターを選ぶ

PRODUCT.md の Brand Personality（stardust/current/PRODUCT.md から）を読み、../prototype/reference/motion-registers.md § 選択ヒューリスティックを適用します。選択したレジスターと、その理由を1行で記録します。

3b — C の「もしも」候補を選ぶ

選ぶ候補は、選択したレジスターが動きを通じて自然に増幅するものでなければなりません。reference/what-if-candidates.md の候補ごとの C に自然なレジスターフィールドが、レジスター→候補の対応関係に関する唯一の信頼できる情報源です。そこに記載された対応関係を確認してください（§ Extension ルールに従って派生候補を採用する場合は、同じフィールドを宣言する必要があります）。このファイルでは対応表を重複して記載しません。

C に自然な候補がすべて除外されている場合のフォールバック： 2 番目の候補レジスター、つまり ../prototype/reference/motion-registers.md § Selection heuristic に従った次点のレジスターを選び直し、そのレジスターに自然な候補を選択します。2 番目の候補レジスターに自然な候補もすべて除外されている場合は、停止条件 (d) に従って --two-variants に進みます。B を取り下げ、C に残った候補のうち最も有力な、除外されていない候補を選ばせます。

3c — B の「もしも」候補を選ぶ

uplift-questions.md にある、残りの（除外されておらず、C に選ばれていない）候補から選びます。次の候補を優先してください。

1. brand-review.html § Tensions で明らかになった緊張関係に対処する候補。
2. 動きではなく、構成／IA／トーンに関する視覚的な変更を伴う候補（B と C を強度だけでなく、軸によって差別化します）。

3d — stardust/direction.md を作成する

以下の 3 つのバリアント宣言を含めて、確定した方向性を記述します。

## Variant A — Faithful + improvements

Role: risk-averse green-light. "Yes, that's us, with the obvious
fixes."
Composition: same as captured.
Motion: static (no cinematic layer).
Improvements applied: <list from uplift-improvements.md>.

## Variant B — What if we amplified <captured trait>?

Role: design-team motivator. The brand's underused capability
foregrounded.
What if: "<one-line "what if…" framing>"
Captured trait amplified: <trait from uplift-questions.md>
Evidence: <captured citation>
Composition: <specific layout strategy that amplifies the trait>
Motion: static (no cinematic layer).

## Variant C — What if motion was part of the identity?

Role: visionary pitch. The brand's third dimension — kinetic.
What if: "<one-line "what if…" framing tied to the register>"
Cinematic register: <register> (auto-picked from PRODUCT.md
Brand Personality)
Captured trait amplified: <trait — the one register naturally
amplifies>
Evidence: <captured citation>
Composition: identical IA to A; the bet is motion, not layout.
Motion: cinematic, register <register>.

Phase 4 — Direct（stardust の direct スキルに委任）

確定した方向性を指定して、stardust の direct スキルを呼び出します。3 バリアントの宣言を入力フレーズとして渡してください（"uplift presales redesign — three variants per stardust/direction.md"）。Direct の担当範囲は以下のとおりです。

• PRODUCT.md、DESIGN.md、DESIGN.json（ルート）の Mode A 作成。
• バリアントごとの DESIGN-A / DESIGN-B / DESIGN-C ファイル。
• DESIGN-C.json のモーションレジスターブロック（direction.md の宣言を読み取ります）。
• IA 優先度の維持に関する監査。
• 密度の下限の適用。
• ツールボックス化防止の監査。
• バリアントの差別化に関する契約。

uplift はこれらのチェックを重複して実行せず、バリアントがブランドに忠実であるという契約に違反している場合は、direct の既存のバリデーターが処理を拒否する仕組みに依存します。

フェーズ 5 — プロトタイプを 3 つ作成（stardust の prototype スキルに委任）

まず A、次に B と C をレンダリングします。

1. A をレンダリング — $stardust prototype <slug> をバリアント A のみに適用して実行します。A で正準設定（トークン、クローム、モジュールのレンダリング）を確立して固定し、B と C はそれを引き継ぎます。最初に A をレンダリングすることで、順序の競合を防ぎます。
2. B、次に C をレンダリング（デフォルトは逐次実行です。Claude Code の Agent ツールや Copilot CLI の task ツールなど、ハーネスがサブエージェントのプリミティブを提供する場合に限り並列実行できます）。B と C は同じスラッグのプロトタイプを作成します。同じスラッグの同時実行では、../stardust/reference/state-machine.md § Concurrency に従い、state.json は後勝ちで上書きされるため、同じ場所での並列レンダリングは安全ではありません。並列実行が許可されるのは、ワークスペースを分離したコピーを使う場合に限ります。各サブエージェントには、自分の DESIGN-<id>.json だけをルートに置き（兄弟ファイルは退避）、プロジェクトのコピー（git worktree またはディレクトリコピー）を渡します。これにより、prototype のファイル存在検出がそのバリアントだけをレンダリングします。サブエージェントは <slug>-<id>-shape.md、<slug>-<id>-proposed.html（C は -cinematic.html も）と来歴情報を返します。親側で成果物をコピーして戻し、両バリアントに対する state.json の更新を一度だけ行います。
3. 各プロトタイプは完成次第開きます。3 つすべてが完成するのを待たず、フェーズ 6 の手順 1 に記載された open の仕組みを使います。

Prototype は、フェーズ 4 で direct が書き込んだバリアントごとの DESIGN-A、DESIGN-B、DESIGN-C ファイルからバリアントのセットを検出します。バリアント収束検出器の契約（../prototype/SKILL.md § Phase 2.5 / Discipline 10）に従い、<slug>-A-shape.md／-B-shape.md／-C-shape.md を作成し、<slug>-A-proposed.html／<slug>-B-proposed.html／<slug>-C-proposed.html を出力します。

シネマティックモーションは CLI フラグではなく、バリアントごとの DESIGN ファイルに基づいて適用されます。uplift から prototype に --cinematic を渡すことは絶対に避けてください。フェーズ 4 では extensions.motion.register が DESIGN-C.json にのみ書き込まれ（A と B にはありません）、prototype のフェーズ 2.4（モーション適用）はバリアント C にのみ適用されます。バリアント C は <slug>-C-proposed.html（静的な参照用）と <slug>-C-cinematic.html（register を適用したサーフェス）の両方を出力します。バリアント A と B は静的にレンダリングされ、モーションランタイムは導入されません。

Prototype の担当範囲：

• prototype のフェーズ 1 に従ったページ形状の概要作成。
• バリアントごとの $impeccable craft 委任によるレンダリング。
• DESIGN-<id>.json で extensions.motion.register が宣言されているバリアントへの、フェーズ 2.4 のモーション適用。
• バリアントごとのフェーズ 2.5～2.8 の品質ゲート（批評、監査、調整、モーション）。
• ../prototype/reference/motion-validation.md に従った、バリアント C のシネマティックモードのゲート（Pass 6）。
• Discipline 10 に従ったバリアント収束検出器（ペアごとに構造上の変更が 2 つ以上）。

複数バリアントのレンダリングは、CLI セレクターではなく、プロジェクトルートにある複数の DESIGN-<id>.json ファイルの存在によって決まります。prototype には --variant <id> の入力はありません。そのため、手順 2 の並列実行では、それぞれに単一の DESIGN-<id>.json だけを配置した、分離済みのワークスペースコピーが必要です。prototype でバリアントを選択する方法は、ファイルの存在だけだからです。上記の A を先にする順序により、どちらの実行方法でも B と C のレンダリングで正準設定の一貫性が保たれます。

フェーズ 6 — 開いて要約（uplift の担当）

3 つのプロトタイプすべてで state.json のステータスが prototyped になったら：

1. 3 つすべてがブラウザーで開いていることを確認します — 各バリアントは完成時に開いています（フェーズ 5 の手順 3）。開いていないものがあれば、シェルコマンドの open（playwright-cli open ではありません）を使って開きます。VFS パスはプレビューサービスワーカー経由で配信されます。

   open stardust/prototypes/<slug>-A-proposed.html
   open stardust/prototypes/<slug>-B-proposed.html
   open stardust/prototypes/<slug>-C-cinematic.html
   

   playwright-cli open はプレビューサービスワーカーを迂回するため、VFS パスでは FILE NOT FOUND エラーが発生します。ローカルのプロトタイプファイルには必ず open <vfs-path> を使ってください。

2. チャットに3 案の要約を出力します。

   uplift complete — three variants for <URL>
   
   A · Tomorrow's version of the site you have today.
      Improvements applied: <count>.
      File: stardust/prototypes/<slug>-A-proposed.html
      Pitch: "yes, that's us, fixed."
   
   B · What if we amplified <captured trait>?
      Trait: <name>.
      Composition bet: <one-line summary>.
      File: stardust/prototypes/<slug>-B-proposed.html
      Pitch: "the brand's underused capability, foregrounded."
   
   C · What if motion was part of the identity?
      Cinematic register: <register>.
      Motion bet: <one-line summary>.
      File: stardust/prototypes/<slug>-C-cinematic.html
      Pitch: "the brand's third dimension."
   
   Differentiation: A vs B ≥ 2 changes (✓), A vs C ≥ 2 changes (✓),
   B vs C ≥ 2 changes (✓).
   
   Validation: all three pass critique + audit + adapt; C additionally
   passes motion validation Pass 6.
   
   Next: iterate any variant via chat ("make B's hero quieter") or
   approve via the standard prototype approval flow (records the
   approval in state.json).
   

この要約は、ユーザーが 3 つのバリアントに直接触れる唯一の機会です。簡潔にしてください。成果物はディスク上にあり、開いて確認できます。

3種類のバリアントに関するロール契約（厳守）

バリアント	狙い	構成	モーション	ステークホルダー
A	「明日の姿です。」	同じIA＋改善を反映	静的	リスクを避けたい承認者
B	「<captured trait>を際立たせたらどうなるでしょうか？」	捉えたものの十分に活用されていない特性を1つ、IA／構成／語り口で前面に出す	静的	ブランドの可能性を探りたいデザインチーム
C	「モーションをアイデンティティの一部にしたらどうなるでしょうか？」	Aと同じIA	ブランドの表現領域から着想した、映画のようなモーション	先見性のある承認者＋デザインリード

この契約は交渉の余地がありません。「Cは映画のように」というルールにより、upliftはAやBとは明確に異なる3つ目の提案を安定して提供できます（「Bのすべてを、さらに大げさにする」というCの失敗パターンではなく）。

捉えたブランド表現から差別化された3種類のバリアントを作れない場合（例：パレットに色が1色しかない、捉えたページにセクションが2つしかない、ブランドの表現領域をどのモーション表現領域にも無理なく対応付けられないなど）は、弱いバリアントを3つ出すのではなく、--two-variantsを使って2種類（A＋C）に減らしてください。

厳守する制約

基盤となるスキルから引き継ぐ制約です。upliftは再掲しませんが、これらの適用を前提としています。

• モードAの固定 — 捉えたブランド表現のパレット＋タイポグラフィ。direct/SKILL.mdの§ Mode Aで適用されます。
• IAの優先順位の維持 — コンフィギュレーターをファーストビュー内に配置する、危機対応の操作要素を最初のビューポートに置くなど。direct/SKILL.mdの§ IA-priority preservation auditで適用されます。
• 密度の下限 — セクションが5つを超えるブランド表現のページでは、sectionPadding.desktopを最大≤ 64pxに制限します。direct/SKILL.mdの§ Hard floor enforcementで適用されます。
• バリアントの差別化 — 各バリアントは、他のバリアントと2つ以上の変更点で異なる必要があります。direct/SKILL.mdの§ Variant differentiation contractで適用されます。
• 捉えた画像を意味上の適切な位置で再利用 — ヒーローはヒーローのまま、ストーリー画像はストーリー画像のままとします。prototype/reference/proposed-file-shell.mdの§ Content sourcing hierarchyで適用されます。
• コンテンツを捏造しない — 統計、住所、引用、人物名は創作せず、[data-placeholder]としてレンダリングします。prototype/SKILL.mdのPhase 2 § Content sourcing scanで適用されます。
• すべてのバリアントのheadにサイトのファビコンを指定 — stardust/current/assets/favicon.<ext>が存在する場合、各バリアントのページでファビコンをdata: URIの<link rel="icon">としてインライン化します。prototype/reference/proposed-file-shell.mdの§ Hard requirements #8で適用されます。
• バリアントCでCの失敗パターンを回避 — バリアントCはモーションを軸にし、「Bのすべてを、さらに大げさにする」案にはしません。prototype/reference/motion-validation.mdの§ Pass 6f motion C-cliff detectorで適用されます。
• バリアントCで動きを減らす設定に対応 — prefers-reduced-motion: reduceのとき、すべてのモーション要素を無効化します。prototype/reference/motion-validation.mdの§ Pass 6bで適用されます。

これらのゲートのいずれかで拒否された場合、upliftは基盤となるスキルからの拒否理由をそのまま表示します。ユーザーには具体的な違反内容が示され、一般的な「upliftに失敗しました」というメッセージは表示されません。

停止条件

次の場合に限り、停止して確認します。

(a) 抽出に失敗した場合 — サイトにアクセスできない、構造を解析できない、 または headed-Chrome フォールバックを使用しても ボット管理によるブロックを回避できない。 (b) ブランドの表層情報が不足している場合 — クラスタリング後の パレットの色が 2 色未満、または取得したページのセクションが 3 つ未満、または取得した PRODUCT.md のブランドパーソナリティが 5 つのモーションレジスターのいずれにも該当しない。 正直に伝えます。「取得したブランド情報が薄く、差別化した 3 つのバリエーションを作るには不十分です。代わりに、強力な バリエーションを 1 つ作成しますか？」 (c) 改善点のリストが空の場合 — Phase 2a で具体的な弱点を 3 つ挙げられない。具体性がなければ、バリエーション A の ブリーフを作成できず、「向上」の主張もできません。正直に伝えます。 (d) 2 つの候補が同程度に弱い場合 — B の「もしも…」候補と C のシネマティック候補が、取得した同じ特性を強調する場合、 バリエーションに差が生まれません。--two-variants に切り替え、 A と C のみを使用します。 (e) 厳格なルールが衝突する場合 — 取得したパレットの色が 1 色のみ、 取得したタイポグラフィにディスプレイ用のレジスターがない、 取得したサイトにシステムコンポーネントがない場合。独自に作り出さずに ブランドに忠実であるという制約を満たせません。その旨を伝えて確認します。

通常のフローでは、このスキルは確認のために停止しません。 元の presales プロンプトの「続行。すべてのフェーズを止まらずに実行」 という特性は維持されます。

出力

stardust/
├── state.json                              ← extracted + 3× prototyped
├── direction.md                            ← resolved direction + 3 variant declarations
├── uplift-improvements.md                  ← load-bearing weakness list (≥ 3 items)
├── uplift-questions.md                     ← 6–8 "what if…" candidate list with disqualifications
├── current/                                ← from extract
│   ├── PRODUCT.md
│   ├── DESIGN.md
│   ├── DESIGN.json
│   ├── brand-review.html
│   ├── _brand-extraction.json
│   ├── _crawl-log.json
│   ├── pages/<slug>.json
│   └── assets/
└── prototypes/
    ├── <slug>-A-shape.md
    ├── <slug>-A-proposed.html              ← faithful + improvements
    ├── <slug>-B-shape.md
    ├── <slug>-B-proposed.html              ← "what if amplifying <trait>"
    ├── <slug>-C-shape.md
    ├── <slug>-C-proposed.html              ← static fallback for C
    ├── <slug>-C-cinematic.html             ← cinematic variant C
    ├── lenis.min.js                        ← copied from skill assets
    └── lenis.min.css

PRODUCT.md                                  ← shared (Mode A)
DESIGN.md / DESIGN.json                     ← shared
DESIGN-A.md / DESIGN-A.json
DESIGN-B.md / DESIGN-B.json
DESIGN-C.md / DESIGN-C.json                 ← carries motion.register

スコープ

• 1 回の実行につき 1 ページです。複数ページの再設計では、標準の extract → direct → prototype チェーンを使用します。
• デプロイ可能なバンドルではなく、3 つのレビュー用画面を作成します。 ブランドオーナーがバリエーションを選んだ後、チャット主導の impeccable コマンドで反復し、標準の prototype 承認フローで承認します。 移行には stardust の migrate スキルを使用します。

参考資料

• reference/what-if-candidates.md — B と C が選択する、取得した特性を 強調する 8 つの具体的な候補と、証拠に基づく派生候補のための § Extension ルール。
• skills/stardust/reference/reference-research.md — 実世界のデザイン参照を 収集する手順（Phase 2.5）：実行するタイミング、3～5 件の参照予算、 証拠の形式、出典の記録方法。
• ../prototype/reference/motion-registers.md — Phase 3a で使用する レジスターカタログと選択ヒューリスティック。
• ../prototype/reference/motion-validation.md § Pass 6 — バリエーション C で実行されるシネマティックモードの検証ゲート。
• ../prototype/SKILL.md — 複数バリエーションのレンダリングとモーションは、 CLI セレクターやフラグではなく、Phase 4 で direct が作成した バリエーションごとの DESIGN-<id>.json ファイルによって制御されます （uplift は --cinematic を渡しません）。
• ../direct/SKILL.md § Phase 2.6 — 複数バリエーションへの分岐。 uplift は 3 バリエーションの宣言をそのまま渡します。
• ../stardust/reference/data-attributes.md — prototype が 3 つの バリエーションすべてに適用する構造セクション属性。
• ../prototype/reference/proposed-file-shell.md — コンテンツの ソース階層とプレースホルダーの規約。