用途
该技能把已批准的简报转化为灰色、结构化的线框图——方框、条块、形状——让用户能在投入视觉设计之前验证页面结构（区块顺序、层级、密度、空间关系）。此阶段是可选的；如果用户已有清晰的结构设想，可以直接跳到 /stardust:prototype。
何时使用
- 用户希望在视觉设计之前验证页面结构——区块顺序、层级、密度、空间关系。
- 用户要求为线框图添加注释，或标记跨页面可复用的片段。
- 用户要求更改、细化、审查、评审或迭代 stardust/wireframes/**/*.html 下的任何文件。
- 用户输入 /stardust:wireframes。
何时不要使用
- 用于品牌视觉设计、颜色、字体或最终比例时，应交给 prototype。
- 用于页面文案或意图时，应交给 briefings。
- 当用户明确希望直接跳到品牌化设计时，建议改用 /stardust:prototype。
前置检查
先运行 ../_shared/preflight.md 中的流程。
契约
需要（若存在则读取）：
- stardust/briefings/{page}.md（一个或多个）
- .impeccable.md（注释的语气）
产出：
- stardust/wireframes/{page}.html（灰色、带注释）
若缺失：
- 没有简报 → 提示用户给出一行页面意图，合成一份最小简报，在简报和线框图上都标注来源，然后继续。
- 没有 .impeccable.md → 注释使用中性技术语气。
- 此阶段有意不读取品牌。
阶段 1：规划
对每个有已批准简报的页面：
- 从 stardust/briefings/{page}.md 读取页面简报。
- 若存在，从 stardust/briefings/_site.md 读取站点简报（包括 Content Reuse Map）。
- 规划页面的区块——UX 探索：
- 若安装了 impeccable 插件（/impeccable shape 已注册），将区块规划委托给 /impeccable shape。
- 否则，使用 ../_shared/fallback-brainstorm.md 中的 “For wireframe section planning” 模式。根据 ../_shared/soft-deps.md，impeccable 回退静默运行。
- 两条路径都要回答：这个页面需要哪些区块、视觉层级是什么、用户如何流经内容。
- /shape 会产出一份设计简报——将其作为结构规划。
- 对于多页面站点，在逐个页面画线框图之前，先规划所有页面的信息架构：
- 若本会话中 /write-plan 已注册（按 ../_shared/soft-deps.md 检测）：将 IA 规划委托给 /write-plan，以站点简报和页面列表作为输入。使用其输出作为多页面结构规划。
- 否则（未安装 superpowers）：按 ../_shared/soft-deps.md 中的原文（“superpowers announcement”）每会话仅宣布一次回退——除非本会话早前已宣布过。然后内联草拟 IA：列出页面、各自主内容类型以及它们之间共享的区块，并在继续前与用户确认。
阶段 2：渲染（灰色模式）
将每个线框图渲染为灰色模式的视觉 HTML：
- 纯灰色布局：方框、条块、形状。无品牌色，无真实字体（system-ui 即可）。
- 背景：浅灰（#f5f5f5）；元素使用不同深浅的灰色。
- 占位文本用灰色条块；图片用带标签的灰色矩形。
- 注释是必需的——每个块都配一个简短的斜体 .note 或 .caption，说明它代表什么，以便评审者无需猜测即可评估流程。重复项（流水线节点、主机磁贴、卡片网格）带有可识别标签（“01 · brand”、“Claude Code”），而非通用编号。参见 wireframe-guide.md 的 Annotations 部分。
- 展示：区块顺序、相对尺寸、内容密度、空间关系。
- 每个区块带有 data-section、data-intent、data-layout 属性，以便设计阶段能接续该结构。
- 对于多页面站点：为可复用内容区块添加 data-fragment、data-fragment-role 和 data-fragment-source 属性——参见 wireframe-guide.md 的 Content Reuse & Fragments 部分。
- 包含链接到简报的 JSON 元数据块（多页面站点带 fragments map）。
- 写入 stardust/wireframes/{page}.html。
- 若上游简报是合成的（存在来源注释，或在本前置检查期间生成），按 ../_shared/skill-contract.md 在线框图上保留来源块。
- 遵循 wireframe-guide.md 中的完整渲染规则。
阶段 3：打开
线框图是自包含的 HTML 文件。按 ../_shared/skill-contract.md 的 Opening HTML artifacts，写入后立即在设计者的默认浏览器中打开每个文件。在 macOS 上：open stardust/wireframes/{page}.html。不要依赖设计者手动打开。
若本阶段渲染了多个线框图（多页面运行），逐个打开，以便设计者在标签页中审阅。
在流水线自动化模式（无设计者在场）下，跳过打开。
阶段 4：批准关卡
软关卡——用户批准的是结构，而非视觉。
展示线框图并询问：“这个结构符合你的设想吗？需要改什么？”
常见反馈：
- “交换这些区块” → 重新排序，重新渲染。
- “为 [X] 添加一个区块” → 添加带数据属性的新区块，重新渲染。
- “这个区块相对其他太大/太小” → 调整比例，重新渲染。
- “我想在这里加点可交互的东西” → 添加 data-interactive 属性。
迭代直到用户批准。然后：
- 若 stardust/brand-profile.json 存在：“线框图已批准。运行 /stardust:prototype 将它们升级为品牌化原型。”
- 若不存在：“线框图已批准。运行 /stardust:brand 捕获你的品牌，然后运行 /stardust:prototype 将其叠加到这些线框图上。”
流水线自动化：当作为完整流水线运行的一部分被调用时，自动批准并继续。
为什么先线框图后设计
线框图让你在不被视觉决策（什么颜色、字体和比例）干扰的情况下做出结构决策（什么放在哪里、以什么顺序、以什么相对尺寸）。将两者分开意味着每个决策都能得到充分关注。
已经知道结构的用户完全可以跳过此阶段，直接走 briefings → design。
产出的工件
文件 | 描述
stardust/wireframes/{page}.html | 灰色结构线框图——自包含 HTML