uplift

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

stardust:uplift

One entry point. One URL. Three presales-quality redesign variants.

uplift

collapses the

extract → direct → prototype × 3

chain into a single opinionated command that picks every variability axis from the captured brand surface rather than asking the user. The output is the same as the long-form chain (state.json, brand-review.html, three proposed files, motion validation) — the user just doesn't have to coordinate it.

一个入口，一个URL，三套售前级别的重设计方案。

uplift

将

extract → direct → prototype × 3

的流程整合为一个独立的指令，所有可变维度均从捕获的品牌视觉信息中自动选取，无需用户额外干预。输出内容与完整流程一致（state.json、brand-review.html、三套设计文件、动态验证报告）——用户无需自行协调各环节。

Opinionated defaults

预设默认规则

Single-page extract — the homepage by default (the brand owner's first surface) unless
```
--page <slug>
```
overrides.
Brand-faithful Mode A — palette + typography pinned. No invented colors, no fonts outside the captured surface.
Three variants, fixed role contract — A is the green-light, B is the design-team motivator, C is the visionary cinematic pitch.
Cinematic register auto-picked — C's motion register is selected from the captured PRODUCT.md Brand Personality per
```
../prototype/reference/motion-registers.md
```
§ Selection heuristic.
"What if..." candidates are evidence-shaped — B and C each pick one captured-but-underused trait, from the eight worked candidates in
```
reference/what-if-candidates.md
```
or a derived candidate per its § Extension rule. Different traits per variant.
Validation cascade runs — every gate in
```
prototype/SKILL.md
```
Phases 2.5–2.8 fires, including cinematic Pass 6 for variant C.

单页提取 — 默认提取首页（品牌方的核心展示页面），可通过
```
--page <slug>
```
参数覆盖。
贴合品牌的A模式 — 固定配色方案与字体体系，不使用捕获范围外的颜色或字体。
三种方案，固定角色定位 — A方案为稳妥的“绿灯”方案，B方案用于激发设计团队灵感，C方案为富有远见的动态视觉提案。
自动选择动态视觉风格 — C方案的动态风格将根据捕获到的PRODUCT.md中的品牌个性，按照
```
../prototype/reference/motion-registers.md
```
中的《选择启发式规则》自动选取。
“如果……会怎样”候选方案基于证据 — B和C方案各选取一个已捕获但未充分利用的品牌特质，候选来源为
```
reference/what-if-candidates.md
```
中的8个成熟选项，或根据其《扩展规则》衍生的新选项。两个方案选取的特质互不重复。
验证流程全量执行 — 执行
```
prototype/SKILL.md
```
中第2.5至2.8阶段的所有验证关卡，包括针对C方案的动态视觉第6轮验证。

Inputs

输入参数

```
<URL>
```
— required. The page to redesign. Defaults to homepage when the URL has no path (
```
https://example.com/
```
→ home).
```
--page <slug>
```
— optional. Override the slug if the URL points elsewhere or the user wants a different surface.

--cinematic-register <name>

— optional. Override the auto-picked register for variant C. One of

arrival

kinetic-display

live-systems

editorial

kinetic-grid

. Recorded as

registerSource: "user-override"

in C's provenance.

```
--two-variants
```
— optional. Render only A and C (skip B). Useful when the brand surface is thin and a forced three-way differentiation would produce a weak middle (per the stop condition below).
```
--re-extract
```
— optional. Force a fresh crawl even when a prior extraction of the same URL is < 7 days old (see § Setup, reuse-if-fresh).

There are no other flags. Everything else is derived from the captured brand surface or governed by the underlying skills' contracts.

```
<URL>
```
— 必填。待重设计的页面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方案）。适用于品牌视觉信息不足，强行生成三套方案会导致中间方案质量不佳的场景（详见下文终止条件）。
```
--re-extract
```
— 可选。强制重新抓取页面，即使同一URL的上次抓取时间小于7天（详见《设置》中的“新鲜内容复用”规则）。

无其他参数。所有其他逻辑均基于捕获的品牌视觉信息或底层工具的规则执行。

Setup

设置步骤

Run the master skill's setup (
```
../stardust/SKILL.md
```
§ Setup): impeccable dep check, context loader, state read.
Verify Playwright is available (
```
extract
```
will fail without it — surface the same install message extract would).
Read
```
stardust/state.json
```
if present. Reuse-if-fresh: when a prior extraction of the same URL is < 7 days old, skip Phase 1 and render against the existing capture, with a one-line notice ("reusing extraction from <date> — pass
```
--re-extract
```
for a fresh crawl").
```
--re-extract
```
forces a fresh crawl regardless of age; extractions ≥ 7 days old re-extract without asking.

运行主工具的设置流程（
```
../stardust/SKILL.md
```
《设置》章节）：完成依赖检查、上下文加载、状态读取。
验证Playwright是否可用（若无则
```
extract
```
流程会失败——显示与
```
extract
```
相同的安装提示）。
若存在
```
stardust/state.json
```
则读取该文件。新鲜内容复用：若同一URL的上次抓取时间小于7天，跳过阶段1，基于已有抓取内容生成方案，并显示一行提示信息（“复用<日期>的抓取内容——添加
```
--re-extract
```
参数可重新抓取”）。
```
--re-extract
```
参数会强制重新抓取，不受时间限制；抓取时间≥7天的内容会自动重新抓取，无需询问。

Procedure

执行流程

Six phases plus a reference-grounding interphase. Phases 1, 4, 5 delegate to existing skills; phases 2, 2.5, 3, 6 are owned by

uplift

共六个阶段，外加一个参考基准阶段。阶段1、4、5委托给现有工具执行；阶段2、2.5、3、6由

uplift

自行处理。

Phase 1 — Extract (delegate to

stardust:extract

)

阶段1 — 提取（委托给

stardust:extract

）

Invoke

stardust:extract <URL> --single

(single-page mode). Extract owns:

Live Playwright render with the standard wait recipe.
```
stardust/current/_brand-extraction.json
```
(palette + type + motifs
- voice + system components + photography).
```
stardust/current/pages/home.json
```
(full per-page capture).
```
stardust/current/brand-review.html
```
with the tensions detectors applied — this is the load-bearing input for Phase 2.
```
stardust/current/PRODUCT.md
```
and
```
DESIGN.md
```
(descriptive — the current state, not the target).

uplift

does not crawl beyond one page. The brand surface from a single homepage is sufficient for three variants; multi-page extract is what

stardust:extract

(without

--single

) is for.

调用

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

仅抓取单个页面。单个首页的品牌视觉信息已足够生成三套方案；多页提取需使用不带

--single

参数的

stardust:extract

。

Phase 2 — Tension and trait identification (owned by

uplift

)

阶段2 — 问题与特质识别（由

uplift

处理）

Read

stardust/current/brand-review.html

§ Tensions surfaced and

_brand-extraction.json

. Produce two artifacts:

读取

stardust/current/brand-review.html

中的《已发现问题》章节和

_brand-extraction.json

文件，生成两个产物：

2a —

stardust/uplift-improvements.md

2a —

stardust/uplift-improvements.md

At least 3 specific weaknesses observed in the captured site — as many as the evidence supports, no fixed count. Same load-bearing contract as the existing presales workflow: without specifics, "make it better" has no claim. Category tags (MAY repeat across items when the evidence supports it):

```
[dated-pattern]
```
— patterns the design world has moved past (be specific: "centered hero with stock photo + double CTA in primary blue reads as the SaaS template circa 2019")
```
[ia-clutter]
```
— cluttered IA / unclear hierarchy / weak CTAs / redundant sections
```
[contrast-or-density]
```
— contrast failures, accessibility gaps, density issues
```
[cliché]
```
— conventions the brand could move past while staying recognisably itself
```
[missed-opportunity]
```
— the captured surface doesn't capitalise on its own strengths ("captured photography is excellent but the layout crops it to thumbnail-size")

Specificity bar — every item. Each item cites a measurement, tension ID, or screenshot observation from the capture, names the pattern at fault, and proposes one concrete fix. An item that fails the bar is cut, not padded.

Audit consumption. When

stardust/audit/<domain-slug>/audit.json

exists for this origin (written by the

stardust:audit

skill), consume its design findings as candidate improvements instead of re-deriving them from scratch — cite the finding IDs in the item's evidence and add the audit file to

readArtifacts

Refuse to proceed if fewer than 3 specific weaknesses can be named (see § Stop conditions).

Format (mirrors the provenance shape used by the rest of stardust):

markdown

---
_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
---

记录捕获页面中至少3个具体问题——数量根据实际证据而定，无固定限制。遵循现有售前工作流的核心规则：若无具体问题，“优化”需求无据可依。每个问题需添加分类标签（证据支持时可重复使用标签）：

```
[dated-pattern]
```
— 设计领域已淘汰的模式（需具体化：“居中英雄区+库存图+蓝色主按钮的双CTA设计，属于2019年左右的SaaS模板风格”）
```
[ia-clutter]
```
— 信息架构混乱/层级不清晰/CTA弱/冗余模块
```
[contrast-or-density]
```
— 对比度不足、无障碍缺陷、内容密度问题
```
[cliché]
```
— 品牌可突破的常规设计，同时保持品牌辨识度
```
[missed-opportunity]
```
— 品牌未充分利用自身优势（“捕获的图片质量极佳，但布局将其裁剪为缩略图尺寸”）

具体性要求——每个问题都需满足：每个问题需引用抓取数据中的测量值、问题ID或截图观察结果，指出问题模式，并提出一个具体修复方案。不符合要求的问题需删除，不得凑数。

审计结果复用：若该域名存在

stardust/audit/<domain-slug>/audit.json

（由

stardust:audit

工具生成），则直接复用其设计发现作为候选改进点，而非重新推导——在问题的证据部分引用发现ID，并将审计文件添加到

readArtifacts

中。

若无法列出至少3个具体问题，终止流程（详见《终止条件》）。

格式（与stardust工具的溯源格式一致）：

markdown

---
_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>

改进建议 — <URL>

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


The bracketed tag preceding each weakness is a category from the
list above. The headline is the one-sentence summary the agent will
restate when variant A's shape brief applies the fix.

[<category-tag>] <一行标题> — <测量值/问题ID/截图观察结果> · <问题模式> · 修复方案：<具体修复措施>。
[<category-tag>] …（至少3项；标签可重复）


每个问题前的方括号标签来自上述分类列表。标题为一句话总结，用于A方案的设计 brief 中说明修复点。

2b —

stardust/uplift-questions.md

2b —

stardust/uplift-questions.md

Six to eight "what if we leaned into…" candidates derived from the captured brand surface. Each candidate cites the captured evidence that makes it concrete. Candidates are drawn from the catalog in

reference/what-if-candidates.md

— eight worked examples that are the floor, not a ceiling:

Display-typography amplification
Photography re-foregrounding
Live-data promotion
Signature-gesture extension
Voice-register pivot
Color-ladder re-weighting
Audience-routing reframe
Motif vocabulary swap

An out-of-catalog derived candidate is admissible when it carries the same evidence shape as the catalog entries: ≥ 2 captured citations + an explicit disqualification test + the variant role it serves (per

reference/what-if-candidates.md

§ Extension rule). Record each candidate's source —

catalog | derived

— in the candidate list.

For each candidate the agent generates: a one-line "what if…" phrasing, the captured evidence that makes the candidate concrete, the variant role it best serves (B's composition bet vs C's cinematic bet), and whether the candidate is disqualified for this brand (e.g. "Photography re-foregrounding disqualified — the captured photography is generic stock; amplifying it would expose the weakness").

The disqualification step is what keeps the agent from reflexively picking the same candidate for every brand.

从捕获的品牌视觉信息中推导6-8个“如果我们强化……会怎样”的候选方案。每个候选方案需引用捕获的证据使其具体化。候选方案来自

reference/what-if-candidates.md

中的目录——8个成熟示例是基础，而非上限：

标题字体强化
图片素材前置
实时数据突出
标志性交互拓展
文案风格调整
配色权重重构
用户路径重定义
视觉元素替换

若候选方案不在目录中，衍生方案需满足与目录方案相同的证据要求：至少2个捕获引用+明确的 disqualification 测试+方案角色定位（根据

reference/what-if-candidates.md

的《扩展规则》）。需在候选列表中记录每个方案的来源——

catalog | derived

。

针对每个生成的候选方案：提供“如果……会怎样”的一行表述、支撑该方案的捕获证据、最适合的方案角色（B方案的布局尝试或C方案的动态视觉尝试）、以及该方案是否不适用于当前品牌（例如：“图片素材前置方案不适用于当前品牌——捕获的图片为通用库存图，强化后会暴露短板”）。

disqualification 步骤用于避免工具对所有品牌都选择相同的候选方案。

Phase 2.5 — Reference grounding (owned by

uplift

)

阶段2.5 — 参考基准（由

uplift

处理）

When reference research is available (per

skills/stardust/reference/reference-research.md

— when to fire, the 3–5 reference budget, the evidence shape, and provenance recording are all defined there), ground the Phase 2 claims in real-world references before Phase 3 picks directions:

(a) Ground each
[dated-pattern]
claim in

uplift-improvements.md

with a named contemporary counter-example — a real site / screen citation showing what the pattern's world moved to. (b) Anchor variant B's composition bet with a named real-world compositional anchor — a real screen whose composition the bet resembles. (c) Verify C's register pick against how motion is actually used in the vertical — does the register match observed contemporary practice for this kind of brand?

Record the references per reference-research.md's provenance contract (

_provenance.referencesUsed[]

on the artifact each grounding serves). When reference research is unavailable, skip with a one-line note in that provenance and proceed — the phase degrades gracefully.

This phase never replaces captured-evidence discipline: references justify the MOVE, captured evidence justifies the TRAIT. A candidate without captured citations is inadmissible no matter how well-referenced its move is.

若有参考研究可用（根据

skills/stardust/reference/reference-research.md

——触发时机、3-5个参考上限、证据格式、溯源记录规则均已定义），则在阶段3确定方向前，将阶段2的结论与真实案例关联：

(a) 为
uplift-improvements.md
中的每个
[dated-pattern]
结论提供当代反例——引用真实网站/界面案例，说明该模式已被何种设计取代。 (b) 为B方案的布局尝试提供真实案例参考——引用一个布局风格相似的真实界面。 (c) 验证C方案的动态风格选择——该风格是否符合当前品牌所属领域的当代设计实践？

根据reference-research.md的溯源规则，在每个关联的产物中记录参考信息（

_provenance.referencesUsed[]

）。若无参考研究可用，在溯源信息中添加一行说明后跳过该阶段——该阶段可降级处理。

该阶段绝不替代捕获证据的严谨性：参考案例证明方向合理性，捕获证据证明特质合理性。无论参考案例多充分，无捕获引用的候选方案均不被采纳。

Phase 3 — Pick three variant directions (owned by

uplift

)

阶段3 — 确定三套方案方向（由

uplift

处理）

Default: three variants (A + B + C). When

--two-variants

is active, skip § 3c (B's candidate selection) and the direction.md authored in § 3d declares only A + C. Phase 4 then writes only

DESIGN-A

and

DESIGN-C

files at the project root, and Phase 5 renders accordingly. All downstream contracts (variant differentiation, motion validation on C, summary in Phase 6) operate over the reduced variant set without modification.

默认生成三套方案（A+B+C）。若启用

--two-variants

参数，跳过§3c（B方案候选选择），并在§3d生成的direction.md中仅声明A+C方案。随后阶段4仅在项目根目录生成

DESIGN-A

和

DESIGN-C

文件，阶段5据此渲染。所有下游规则（方案差异化、C方案动态验证、阶段6总结）均适配简化后的方案集，无需修改。

3a — Pick the cinematic register for variant C

3a — 为C方案选择动态视觉风格

Read PRODUCT.md Brand Personality (from

stardust/current/PRODUCT.md

) and apply the heuristic in

../prototype/reference/motion-registers.md

§ Selection heuristic. Record the picked register + the one-line rationale.

读取

stardust/current/PRODUCT.md

中的品牌个性，按照

../prototype/reference/motion-registers.md

中的《选择启发式规则》选取风格。记录所选风格及一行理由。

3b — Pick C's "what if" candidate

3b — 为C方案选择“如果……会怎样”候选方案

The candidate must be the one the picked register naturally amplifies through motion. The per-candidate Natural register for C fields in

reference/what-if-candidates.md

are the single source of truth for the register→candidate mapping — read the mapping there (a derived candidate admitted per its § Extension rule must declare the same field). This file does not duplicate the table.

Fallback when C's natural candidates are all disqualified: re-pick the second-choice register — the next-best match from

../prototype/reference/motion-registers.md

§ Selection heuristic — and take its natural candidate. If the second-choice register's natural candidates are also all disqualified, fall through to

--two-variants

via stop condition (d): drop B and let C take the strongest remaining non-disqualified candidate.

候选方案需是所选动态视觉风格能通过动态效果自然强化的特质。

reference/what-if-candidates.md

中每个候选方案的C方案适配动态风格字段是风格→候选方案映射的唯一依据——请参考该文件中的映射（根据《扩展规则》采纳的衍生方案需声明相同字段）。本文件不重复该映射表。

** fallback 逻辑：若C方案的适配候选方案均被 disqualify**——重新选择次优风格（

../prototype/reference/motion-registers.md

《选择启发式规则》中的下一个匹配项），并选取其适配候选方案。若次优风格的适配候选方案也均被 disqualify，则触发终止条件(d)：切换为

--two-variants

模式（仅A+C方案），让C方案选取剩余未被 disqualify 的最强候选方案。

3c — Pick B's "what if" candidate

3c — 为B方案选择“如果……会怎样”候选方案

Pick from the remaining (non-disqualified, non-C) candidates in

uplift-questions.md

. Prefer:

A candidate that addresses a tension surfaced in
```
brand-review.html
```
§ Tensions.
A candidate whose visual move is composition / IA / voice rather than motion (so B and C are differentiated by axis, not just intensity).

从

uplift-questions.md

中剩余的（未被 disqualify、未被C方案选取的）候选方案中选取。优先选择：

能解决
```
brand-review.html
```
《已发现问题》章节中提及的问题的方案。
视觉调整方向为布局/信息架构/文案风格而非动态效果的方案（确保B和C方案的差异化维度不同，而非仅强度差异）。

3d — Author

stardust/direction.md

3d — 生成

stardust/direction.md

Write the resolved direction with three variant declarations:

markdown

undefined

写入最终确定的方案方向，包含三套方案的声明：

markdown

undefined

Variant A — Faithful + improvements

方案A — 贴合品牌+优化改进

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>.

定位：低风险的“绿灯”方案。“对，这就是我们的品牌，只是做了一些明显的优化。” 布局：与原页面一致。动态效果：静态（无动态视觉层）。应用的改进：<来自uplift-improvements.md的列表>。

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

方案B — 如果我们强化<捕获的特质>会怎样？

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).

定位：激发设计团队灵感的方案。将品牌未充分利用的能力前置展示。假设：“<一行‘如果……会怎样’的表述>” 强化的捕获特质：<来自uplift-questions.md的特质> 证据：<捕获引用> 布局：<强化该特质的具体布局策略> 动态效果：静态（无动态视觉层）。

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

方案C — 如果动态效果成为品牌标识的一部分会怎样？

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>.

undefined

定位：富有远见的提案。展现品牌的第三维度——动态视觉。假设：“<与所选风格绑定的一行‘如果……会怎样’的表述>” 动态视觉风格：<风格>（根据PRODUCT.md中的品牌个性自动选取）强化的捕获特质：<特质——所选风格自然强化的特质> 证据：<捕获引用> 布局：与方案A的信息架构完全一致；核心差异为动态效果，而非布局。动态效果：全动态，采用<风格>。

undefined

Phase 4 — Direct (delegate to

stardust:direct

)

阶段4 — 指导设计（委托给

stardust:direct

）

Invoke

stardust:direct

with the resolved direction. Pass the three-variant declaration as the input phrase ("uplift presales redesign — three variants per stardust/direction.md"). Direct owns:

Mode A authoring of PRODUCT.md, DESIGN.md, DESIGN.json (root).
Per-variant DESIGN-A / DESIGN-B / DESIGN-C files.
The motion register block in DESIGN-C.json (read from the direction.md declaration).
IA-priority preservation audit.
Density floor enforcement.
Anti-toolbox audit.
Variant differentiation contract.

uplift

does not duplicate any of those checks; it relies on direct's existing validators to refuse if the variants violate the brand-faithful contract.

调用

stardust:direct

并传入最终确定的方案方向。将三套方案的声明作为输入短语（“uplift售前重设计——三套方案遵循stardust/direction.md”）。

direct

负责：

以A模式生成PRODUCT.md、DESIGN.md、DESIGN.json（根目录）。
生成每个方案对应的DESIGN-A/DESIGN-B/DESIGN-C文件。
在DESIGN-C.json中写入动态风格配置块（读取自direction.md的声明）。
信息架构优先级保留审计。
内容密度下限执行。
反工具化审计。
方案差异化规则执行。

uplift

不重复上述任何检查，依赖

direct

的现有验证器拒绝违反贴合品牌规则的方案。

Phase 5 — Prototype × 3 (delegate to

stardust:prototype

)

阶段5 — 生成三套原型（委托给

stardust:prototype

）

Render A first, then B and C:

Render A — invoke
```
stardust:prototype <slug>
```
scoped to variant A. A establishes and freezes the canon (tokens, chrome, module renderings) that B and C inherit; rendering it first removes the ordering race.
Render B, then C (default: sequential). B and C prototype the same slug, and same-slug concurrent runs are last-write- wins on
```
state.json
```
per
```
../stardust/reference/state-machine.md
```
§ Concurrency — so in-place parallel rendering is unsafe. Parallel is permitted only via isolated workspace copies: each subagent gets a copy of the project (git worktree or directory copy) containing only its own
```
DESIGN-<id>.json
```
at the root (siblings stashed), so prototype's file-presence detection renders exactly that variant. The subagent returns its
```
<slug>-<id>-shape.md
```
,
```
<slug>-<id>-proposed.html
```
(and C's
```
-cinematic.html
```
) plus provenance; the parent copies the artifacts back and performs the single
```
state.json
```
update for both variants.
Open each prototype as it completes (via the
```
open
```
mechanics in Phase 6 step 1) rather than waiting for all three.

Prototype detects the variant set from the per-variant

DESIGN-A

DESIGN-B

DESIGN-C

files that

direct

wrote in Phase 4 — authoring

<slug>-A-shape.md

-B-shape.md

-C-shape.md

and emitting

<slug>-A-proposed.html

<slug>-B-proposed.html

<slug>-C-proposed.html

per the variant-convergence detector contract (

../prototype/SKILL.md

§ Phase 2.5 / Discipline 10).

Cinematic motion fires per-variant from the per-variant DESIGN file, not from a CLI flag. Never pass
--cinematic
to prototype from uplift. Because Phase 4 wrote

extensions.motion.register

into

DESIGN-C.json

only (A and B omit it), prototype's Phase 2.4 (motion application) fires only for variant C. Variant C emits both

<slug>-C-proposed.html

(the static reference) and

<slug>-C-cinematic.html

(the register-applied surface). Variants A and B render static, never acquiring the motion runtime.

Prototype owns:

Page-shape brief authoring per Phase 1 of prototype.
Render via
```
$impeccable craft
```
delegation, per variant.
Phase 2.4 motion application for variants whose
```
DESIGN-<id>.json
```
declares an
```
extensions.motion.register
```
.
Phases 2.5–2.8 quality gates (critique, audit, adapt, motion) per variant.
Variant C's cinematic-mode gates (Pass 6) per
```
../prototype/reference/motion-validation.md
```
.
Variant-convergence detector (≥ 2 structural changes per pair) per Discipline 10.

Multi-variant rendering is driven by the presence of multiple

DESIGN-<id>.json

files at the project root, not by a CLI selector — prototype has no

--variant <id>

input. That is exactly why the parallel path in step 2 requires isolated workspace copies with a single pinned

DESIGN-<id>.json

each: file presence is the only variant selector prototype has. The A-first ordering above is what keeps canon consistent across the B and C runs in either path.

按先A，再B，最后C的顺序渲染：

渲染方案A — 调用
```
stardust:prototype <slug>
```
并限定为A方案。A方案确立并固化标准（设计令牌、导航栏、模块渲染规则），供B和C方案继承；先渲染A方案可避免顺序冲突。
渲染方案B，再渲染方案C（默认顺序执行）。B和C方案渲染同一页面标识，根据
```
../stardust/reference/state-machine.md
```
《并发规则》，同一页面标识的并发执行会导致state.json的最后写入覆盖结果——因此原位并行渲染不安全。仅通过独立工作区副本支持并行渲染：每个子工具获取项目副本（git工作区或目录副本），仅保留自身的
```
DESIGN-<id>.json
```
在根目录（其他方案文件暂存），这样原型工具的文件存在检测会仅渲染该方案。子工具返回
```
<slug>-<id>-shape.md
```
、
```
<slug>-<id>-proposed.html
```
（以及C方案的
```
-cinematic.html
```
）和溯源信息；父工具将产物复制回原项目，并一次性更新state.json以记录两个方案的状态。
每个原型完成后立即打开（通过阶段6步骤1中的
```
open
```
机制），无需等待所有方案完成。

原型工具根据阶段4中

direct

生成的DESIGN-A、DESIGN-B、DESIGN-C文件检测方案集——根据方案收敛检测规则（

../prototype/SKILL.md

§阶段2.5 /规则10），生成

<slug>-A-shape.md

-B-shape.md

-C-shape.md

，并输出

<slug>-A-proposed.html

<slug>-B-proposed.html

<slug>-C-proposed.html

。

动态效果根据每个方案的DESIGN文件触发，而非通过CLI参数。绝不要从uplift向prototype传递
--cinematic
参数。因为阶段4仅在DESIGN-C.json中写入了

extensions.motion.register

（A和B方案不含该配置），所以原型工具的阶段2.4（动态效果应用）仅对C方案触发。C方案会同时输出

<slug>-C-proposed.html

（静态参考版）和

<slug>-C-cinematic.html

（应用动态风格的版本）。A和B方案仅渲染静态页面，不加载动态运行时。

原型工具负责：

根据原型阶段1生成页面设计 brief。
按方案委托
```
$impeccable craft
```
进行渲染。
对DESIGN-<id>.json中声明了
```
extensions.motion.register
```
的方案执行阶段2.4的动态效果应用。
对每个方案执行阶段2.5-2.8的质量关卡（评审、审计、适配、动态效果）。
对C方案执行动态视觉关卡（第6轮验证），遵循
```
../prototype/reference/motion-validation.md
```
。
根据规则10执行方案收敛检测（每两个方案之间至少有2处结构变化）。

多方案渲染由根目录中多个DESIGN-<id>.json文件的存在驱动，而非通过CLI选择器——原型工具没有

--variant <id>

输入参数。这正是阶段2中并行路径需要独立工作区副本且仅保留单个DESIGN-<id>.json的原因：文件存在是原型工具唯一的方案选择依据。上述先渲染A方案的顺序确保了在任何路径下，B和C方案的标准都是一致的。

Phase 6 — Open and summarize (owned by

uplift

)

阶段6 — 打开与总结（由

uplift

处理）

After all three prototypes mark

prototyped

state.json

Confirm all three are open in the browser — each variant was opened as it completed (Phase 5 step 3); open any that weren't, using the
```
open
```
shell command (not
```
playwright-cli open
```
) so VFS paths are served via the preview service worker:
```
open stardust/prototypes/<slug>-A-proposed.html
open stardust/prototypes/<slug>-B-proposed.html
open stardust/prototypes/<slug>-C-cinematic.html
```
```
playwright-cli open
```
bypasses the preview service worker and produces a FILE NOT FOUND error for VFS paths. Always use
```
open <vfs-path>
```
for local prototype files.

Print the three-pitch summary in the chat:

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).

The summary is the user's only direct touchpoint with the three variants. Keep it short — the work is on disk and openable.

当所有三个原型在state.json中标记为

prototyped

后：

确认三个原型均已在浏览器中打开——每个方案完成后已自动打开（阶段5步骤3）；若有未打开的，使用
```
open
```
命令打开（而非
```
playwright-cli open
```
，否则虚拟文件系统路径会因绕过预览服务工作线程而显示“文件未找到”错误）：
```
open stardust/prototypes/<slug>-A-proposed.html
open stardust/prototypes/<slug>-B-proposed.html
open stardust/prototypes/<slug>-C-cinematic.html
```
```
playwright-cli open
```
会绕过预览服务工作线程，导致虚拟文件系统路径出现“文件未找到”错误。本地原型文件请始终使用
```
open <vfs-path>
```
命令打开。

在聊天窗口输出三套方案的总结：

uplift完成 — <URL>的三套方案已生成

A · 现有网站的优化版。
   应用改进项：<数量>。
   文件：stardust/prototypes/<slug>-A-proposed.html
   提案话术：“对，这就是我们的品牌，只是做了优化。”

B · 如果我们强化<捕获的特质>会怎样？
   特质：<名称>。
   布局尝试：<一行总结>。
   文件：stardust/prototypes/<slug>-B-proposed.html
   提案话术：“将品牌未充分利用的能力前置展示。”

C · 如果动态效果成为品牌标识的一部分会怎样？
   动态视觉风格：<风格>。
   动态尝试：<一行总结>。
   文件：stardust/prototypes/<slug>-C-cinematic.html
   提案话术：“展现品牌的第三维度。”

差异化验证：A与B差异≥2处（✓），A与C差异≥2处（✓），B与C差异≥2处（✓）。

验证结果：三套方案均通过评审+审计+适配；C方案额外通过动态视觉第6轮验证。

下一步：通过聊天窗口迭代任意方案（例如“让B方案的英雄区更简洁”），或通过标准原型审批流程确认（审批结果会记录在state.json中）。

该总结是用户与三套方案的直接交互入口。请保持简洁——具体设计文件已存储在本地并可打开。

The three-variant role contract (hard)

三套方案的角色定位规则（硬性要求）

Variant	Pitch	Composition	Motion	Stakeholder
A	"Tomorrow's version."	Same IA + improvements applied	Static	Risk-averse green-light buyer
B	"What if we amplified `<captured trait>` ?"	One captured-but-underused trait foregrounded in IA / composition / voice	Static	Design team that wants brand exploration
C	"What if motion was part of the identity?"	Same IA as A	Fully cinematic, register from brand surface	Visionary buyer + design lead

This contract is non-negotiable. The "C is cinematic" rule is how

uplift

reliably ships a third proposition that's defensibly different from A and B (rather than the C-cliff failure mode of "everything from B but bigger").

If the captured brand surface can't support three differentiated variants (e.g. the palette has only one color, the captured page has only two sections, the brand register doesn't map cleanly to any motion register), reduce to two variants (A + C) via

--two-variants

rather than ship three weak ones.

方案	提案话术	布局	动态效果	目标受众
A	“现有网站的优化版。”	与原页面信息架构一致+应用改进项	静态	低风险偏好的决策者
B	“如果我们强化 `<捕获的特质>` 会怎样？”	将一个已捕获但未充分利用的特质在信息架构/布局/文案风格中前置展示	静态	希望探索品牌可能性的设计团队
C	“如果动态效果成为品牌标识的一部分会怎样？”	与A方案信息架构一致	全动态，风格来自品牌视觉信息	富有远见的决策者+设计负责人

该规则不可协商。“C方案为动态视觉”的规则确保

uplift

能可靠地生成与A、B方案明显不同的第三套提案（避免出现“B方案的放大版”这种失败模式）。

若捕获的品牌视觉信息无法支持三套差异化方案（例如：配色仅有一种颜色、捕获页面仅含2个模块、品牌风格无法匹配任何动态视觉风格），则通过

--two-variants

参数简化为两套方案（A+C），而非生成三套质量不佳的方案。

Hard constraints

硬性约束

Inherited from the underlying skills —

uplift

does not re-state them but relies on them being enforced:

Mode A pinning — palette + typography from captured brand surface. Enforced by
```
direct/SKILL.md
```
§ Mode A.
IA priority preservation — configurator stays above the fold, crisis affordances stay first-viewport, etc. Enforced by
```
direct/SKILL.md
```
§ IA-priority preservation audit.
Density floor — brand-register pages with > 5 sections cap
```
sectionPadding.desktop
```
at ≤ 64px. Enforced by
```
direct/SKILL.md
```
§ Hard floor enforcement.
Variant differentiation — each variant differs from the others by ≥ 2 changes. Enforced by
```
direct/SKILL.md
```
§ Variant differentiation contract.
Captured images reused in semantic positions — hero stays hero, story image stays story image. Enforced by
```
prototype/reference/proposed-file-shell.md
```
§ Content sourcing hierarchy.
No fabricated content — stats, addresses, quotes, named persons rendered as
```
[data-placeholder]
```
not invented. Enforced by
```
prototype/SKILL.md
```
Phase 2 § Content sourcing scan.
Site favicon in every variant's head — when
```
stardust/current/assets/favicon.<ext>
```
exists, each variant page inlines it as a data: URI
```
<link rel="icon">
```
. Enforced by
```
prototype/reference/proposed-file-shell.md
```
§ Hard requirements #8.
C-cliff refusal for variant C — variant C bets on motion, not on "everything from B but more." Enforced by
```
prototype/reference/motion-validation.md
```
§ Pass 6f motion C-cliff detector.
Reduced-motion fallback for variant C — every motion element is neutralized under
```
prefers-reduced-motion: reduce
```
. Enforced by
```
prototype/reference/motion-validation.md
```
§ Pass 6b.

When any of these gates refuses,

uplift

surfaces the refusal verbatim from the underlying skill — the user sees the specific violation, not a generic "uplift failed" message.

继承自底层工具——

uplift

不重复声明这些约束，但依赖底层工具执行：

A模式固定规则 — 配色与字体来自捕获的品牌视觉信息。由
```
direct/SKILL.md
```
§A模式执行。
信息架构优先级保留 — 配置器保持在首屏内，紧急操作入口保持在视窗顶部等。由
```
direct/SKILL.md
```
§信息架构优先级保留审计执行。
内容密度下限 — 品牌风格页面若包含>5个模块，
```
sectionPadding.desktop
```
上限为≤64px。由
```
direct/SKILL.md
```
§硬性下限执行。
方案差异化 — 每个方案与其他方案的差异≥2处。由
```
direct/SKILL.md
```
§方案差异化规则执行。
捕获图片语义复用 — 英雄区图片仍用于英雄区，故事图片仍用于故事模块。由
```
prototype/reference/proposed-file-shell.md
```
§内容来源层级执行。
无虚构内容 — 统计数据、地址、引用、人物名称均渲染为
```
[data-placeholder]
```
，不得虚构。由
```
prototype/SKILL.md
```
阶段2 §内容来源扫描执行。
每个方案的头部均包含网站图标 — 若
```
stardust/current/assets/favicon.<ext>
```
存在，每个方案页面会将其作为data: URI内联为
```
<link rel="icon">
```
。由
```
prototype/reference/proposed-file-shell.md
```
§硬性要求#8执行。
C方案避免“放大版”失败模式 — C方案聚焦于动态效果，而非“B方案的放大版”。由
```
prototype/reference/motion-validation.md
```
§第6轮验证f项的动态效果失败模式检测执行。
C方案的动态效果降级 — 当系统设置为
```
prefers-reduced-motion: reduce
```
时，所有动态元素均失效。由
```
prototype/reference/motion-validation.md
```
§第6轮验证b项执行。

若任何关卡拒绝执行，

uplift

会直接显示底层工具的拒绝信息——用户会看到具体违规内容，而非通用的“uplift失败”提示。

Stop conditions

终止条件

Stop and ask only if:

(a) Extract fails — site unreachable, structure unparseable, bot-management blocks past the headed-Chrome fallback. (b) Brand surface insufficient — palette has fewer than 2 distinct colors after clustering; OR the captured page has fewer than 3 sections; OR the captured PRODUCT.md Brand Personality maps to none of the five motion registers. Surface honestly: "the captured brand surface is too thin for three differentiated variants — render one strong variant instead?" (c) Improvements list empty — Phase 2a cannot name 3 specific weaknesses. Without specifics, variant A has no brief and "uplift" has no claim. Surface honestly. (d) Two candidates equally weak — if B's "what if…" candidate and C's cinematic candidate would amplify the same captured trait, the variants would not differentiate. Switch to

--two-variants

(A + C only). (e) Hard rule conflict — captured palette has a single color, captured typography has no display register, captured site has no system components. Brand-faithful constraint impossible without invention. Surface and ask.

The skill does not stop for confirmation in normal flow. The "PROCEED. Run all phases without stopping" property of the original presales prompt is preserved.

仅在以下情况终止并询问用户：

(a) 提取失败 — 网站无法访问、结构无法解析、反爬机制阻止抓取（即使使用带界面的Chrome fallback也无法绕过）。 (b) 品牌视觉信息不足 — 聚类后配色不足2种；或捕获页面不足3个模块；或捕获的PRODUCT.md品牌个性无法匹配5种动态视觉风格中的任何一种。需如实告知：“捕获的品牌视觉信息不足以生成三套差异化方案——是否改为生成一套高质量方案？” (c) 改进建议为空 — 阶段2a无法列出3个具体问题。若无具体问题，A方案无设计 brief，“优化”需求无据可依。需如实告知。 (d) 两个候选方案同质化 — 若B方案的“如果……会怎样”候选方案与C方案的动态视觉候选方案强化的是同一捕获特质，方案将无差异化。切换为

--two-variants

模式（仅A+C方案）。 (e) 硬性规则冲突 — 捕获的配色仅有一种颜色、捕获的字体无标题风格、捕获的网站无系统组件。无法在不虚构内容的前提下满足贴合品牌的约束。需如实告知并询问用户。

在正常流程中，工具不会暂停等待确认。保留原始售前需求中的“直接执行所有阶段，无需暂停”特性。

Outputs

输出产物

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

stardust/
├── state.json                              ← 提取数据+三套原型状态
├── direction.md                            ← 最终方案方向+三套方案声明
├── uplift-improvements.md                  ← 核心问题列表（至少3项）
├── uplift-questions.md                     ← 6-8个“如果……会怎样”候选方案（含 disqualification 标记）
├── current/                                ← 来自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              ← 贴合品牌+优化改进版
    ├── <slug>-B-shape.md
    ├── <slug>-B-proposed.html              ← “强化<特质>”版
    ├── <slug>-C-shape.md
    ├── <slug>-C-proposed.html              ← C方案的静态 fallback
    ├── <slug>-C-cinematic.html             ← C方案的动态视觉版
    ├── lenis.min.js                        ← 从工具资源复制而来
    └── lenis.min.css

PRODUCT.md                                  ← 共享文件（A模式）
DESIGN.md / DESIGN.json                     ← 共享文件
DESIGN-A.md / DESIGN-A.json
DESIGN-B.md / DESIGN-B.json
DESIGN-C.md / DESIGN-C.json                 ← 包含motion.register配置

Scope

适用范围

One page per run. Multi-page redesigns use the standard
```
extract
```
→
```
direct
```
→
```
prototype
```
chain.
Three review surfaces, not a deployable bundle. After the brand owner picks a variant, iterate via chat-driven impeccable commands and approve via the standard
```
prototype
```
approval flow. Migration is
```
stardust:migrate
```
.

每次运行仅处理一个页面。多页面重设计需使用标准的
```
extract
```
→
```
direct
```
→
```
prototype
```
流程。
生成三套用于评审的页面，而非可部署的包。品牌方选定方案后，可通过聊天驱动的impeccable命令迭代，或通过标准原型审批流程确认。迁移需使用
```
stardust:migrate
```
工具。

References

参考文档

```
reference/what-if-candidates.md
```
— the eight worked captured-trait amplification candidates that B and C pick from, plus the § Extension rule for evidence-shaped derived candidates.
```
skills/stardust/reference/reference-research.md
```
— procedure for sourcing real-world design references (Phase 2.5): when to fire, the 3–5 reference budget, the evidence shape, provenance recording.
```
../prototype/reference/motion-registers.md
```
— register catalog and selection heuristic used in Phase 3a.
```
../prototype/reference/motion-validation.md
```
§ Pass 6 — cinematic-mode validation gates that fire for variant C.
```
../prototype/SKILL.md
```
— multi-variant rendering and motion driven by the per-variant
```
DESIGN-<id>.json
```
files
```
direct
```
wrote in Phase 4, not by a CLI selector or flag (uplift never passes
```
--cinematic
```
).
```
../direct/SKILL.md
```
§ Phase 2.6 — multi-variant fork; uplift passes the three-variant declaration through.
```
../stardust/reference/data-attributes.md
```
— structural section attributes applied by prototype to all three variants.
```
../prototype/reference/proposed-file-shell.md
```
— content sourcing hierarchy and placeholder convention.

```
reference/what-if-candidates.md
```
— B和C方案选取的8个成熟捕获特质强化候选方案，以及衍生方案的《扩展规则》。
```
skills/stardust/reference/reference-research.md
```
— 真实设计参考案例的获取流程（阶段2.5）：触发时机、3-5个参考上限、证据格式、溯源记录规则。
```
../prototype/reference/motion-registers.md
```
— 动态视觉风格目录及阶段3a使用的选择启发式规则。
```
../prototype/reference/motion-validation.md
```
§第6轮验证 — 针对C方案的动态视觉验证关卡。
```
../prototype/SKILL.md
```
— 多方案渲染及动态效果触发逻辑：基于阶段4中
```
direct
```
生成的DESIGN-<id>.json文件，而非CLI选择器或参数（uplift绝不传递
```
--cinematic
```
参数）。
```
../direct/SKILL.md
```
§阶段2.6 — 多方案分支逻辑；uplift会传递三套方案的声明。
```
../stardust/reference/data-attributes.md
```
— 原型工具为所有方案添加的结构模块属性。

../prototype/reference/proposed-file-shell.md

— 内容来源层级及占位符规则。

uplift

Original

Translation

stardust:uplift

stardust:uplift

Opinionated defaults

预设默认规则

Inputs

输入参数

Setup

设置步骤

Procedure

执行流程

Phase 1 — Extract (delegate to stardust:extract)

阶段1 — 提取（委托给stardust:extract）

Phase 2 — Tension and trait identification (owned by uplift)

阶段2 — 问题与特质识别（由uplift处理）

2a — stardust/uplift-improvements.md

2a — stardust/uplift-improvements.md

Improvements — <URL>

改进建议 — <URL>

2b — stardust/uplift-questions.md

2b — stardust/uplift-questions.md

Phase 2.5 — Reference grounding (owned by uplift)

阶段2.5 — 参考基准（由uplift处理）

Phase 3 — Pick three variant directions (owned by uplift)

阶段3 — 确定三套方案方向（由uplift处理）

3a — Pick the cinematic register for variant C

3a — 为C方案选择动态视觉风格

3b — Pick C's "what if" candidate

3b — 为C方案选择“如果……会怎样”候选方案

3c — Pick B's "what if" candidate

3c — 为B方案选择“如果……会怎样”候选方案

3d — Author stardust/direction.md

3d — 生成stardust/direction.md

Variant A — Faithful + improvements

方案A — 贴合品牌+优化改进

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

方案B — 如果我们强化<捕获的特质>会怎样？

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

方案C — 如果动态效果成为品牌标识的一部分会怎样？

Phase 4 — Direct (delegate to stardust:direct)

阶段4 — 指导设计（委托给stardust:direct）

Phase 5 — Prototype × 3 (delegate to stardust:prototype)

阶段5 — 生成三套原型（委托给stardust:prototype）

Phase 6 — Open and summarize (owned by uplift)

阶段6 — 打开与总结（由uplift处理）

The three-variant role contract (hard)

三套方案的角色定位规则（硬性要求）

Hard constraints

硬性约束

Stop conditions

终止条件

Outputs

输出产物

Scope

适用范围

References

参考文档

Phase 1 — Extract (delegate to
`stardust:extract`
)

阶段1 — 提取（委托给
`stardust:extract`
）

Phase 2 — Tension and trait identification (owned by
`uplift`
)

阶段2 — 问题与特质识别（由
`uplift`
处理）

2a —
`stardust/uplift-improvements.md`

2a —
`stardust/uplift-improvements.md`

2b —
`stardust/uplift-questions.md`

2b —
`stardust/uplift-questions.md`

Phase 2.5 — Reference grounding (owned by
`uplift`
)

阶段2.5 — 参考基准（由
`uplift`
处理）

Phase 3 — Pick three variant directions (owned by
`uplift`
)

阶段3 — 确定三套方案方向（由
`uplift`
处理）

3d — Author
`stardust/direction.md`

3d — 生成
`stardust/direction.md`

Phase 4 — Direct (delegate to
`stardust:direct`
)

阶段4 — 指导设计（委托给
`stardust:direct`
）

Phase 5 — Prototype × 3 (delegate to
`stardust:prototype`
)

阶段5 — 生成三套原型（委托给
`stardust:prototype`
）

Phase 6 — Open and summarize (owned by
`uplift`
)

阶段6 — 打开与总结（由
`uplift`
处理）