wireframes

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Wireframes

线框图

Turn approved briefings into grey, structural wireframes — boxes, bars, shapes — so the user can validate page structure (section order, hierarchy, density, spatial relationships) before committing to visual design.

This stage is optional. A user who already has a clear structural vision can skip straight to

/stardust:prototype

将已获批的简报转化为灰色结构型线框图——仅包含方框、条块、图形——以便用户在确定视觉设计前验证页面结构（章节顺序、层级、密度、空间关系）。

此阶段为可选步骤。对结构已有清晰规划的用户可直接跳转到

/stardust:prototype

。

When to use this skill

何时使用此技能

The user wants to validate page structure before visual design — section order, hierarchy, density, spatial relationships.
The user asks to annotate a wireframe or mark reusable fragments across pages.
The user asks to change, refine, review, critique, or iterate on any file under
```
stardust/wireframes/**/*.html
```
.
The user types
```
/stardust:wireframes
```
.

用户希望在视觉设计前验证页面结构——包括章节顺序、层级、密度、空间关系。
用户要求注释线框图或标记跨页面可复用片段。
用户要求更改、优化、评审、修改或迭代
```
stardust/wireframes/**/*.html
```
下的任意文件。
用户输入
```
/stardust:wireframes
```
。

Do NOT use this skill

请勿使用此技能

For branded visual design, colors, typography, or final proportions. Hand off to
```
prototype
```
.
For page copy or intent. Hand off to
```
briefings
```
.
When the user explicitly wants to skip straight to branded design — suggest
```
/stardust:prototype
```
instead.

用于品牌视觉设计、配色、排版或最终比例设计。此类需求请转交
```
prototype
```
处理。
用于页面文案或意图设计。此类需求请转交
```
briefings
```
处理。
用户明确希望直接跳过此阶段进行品牌化设计时——建议使用
```
/stardust:prototype
```
替代。

Pre-flight

前置检查

Run the procedure in

../_shared/preflight.md

first.

请先执行

../_shared/preflight.md

中的流程。

Contract

规则约定

Needs (reads if present):

```
stardust/briefings/{page}.md
```
(one or more)
```
.impeccable.md
```
(tone for annotations)

Produces:

```
stardust/wireframes/{page}.html
```
(grey, annotated)

If missing:

No briefings → prompt the user for a one-line page intent, synthesize a minimal briefing, stamp provenance on both the briefing and the wireframe, and proceed.
No
```
.impeccable.md
```
→ annotations use neutral-technical tone.
Brand is intentionally not read at this stage.

所需资源（若存在则读取）：

```
stardust/briefings/{page}.md
```
（一个或多个）
```
.impeccable.md
```
（注释语气规范）

产出内容：

```
stardust/wireframes/{page}.html
```
（带注释的灰色线框图）

资源缺失时的处理：

无简报→提示用户提供一行页面意图说明，生成最简简报，在简报和线框图上标注来源信息，然后继续流程。
无
```
.impeccable.md
```
→注释采用中立技术语气。
本阶段刻意不读取品牌相关信息。

Phase 1: Plan

第一阶段：规划

For each page with an approved briefing:

Read the page briefing from
```
stardust/briefings/{page}.md
```
.
Read the site briefing from
```
stardust/briefings/_site.md
```
if it exists (including the Content Reuse Map).
Plan the page's sections — UX discovery:
- If the
```
impeccable
```
  plugin is installed (
```
/impeccable shape
```
  is registered), delegate section planning to
```
/impeccable shape
```
  .
- Otherwise, use the "For wireframe section planning" pattern in
```
../_shared/fallback-brainstorm.md
```
  . Per
```
../_shared/soft-deps.md
```
  , impeccable fallback runs silently. Either path answers: what sections does this page need, what's the visual hierarchy, and how does the user flow through the content.
- ```
/shape
```
  produces a design brief — use this as the structural plan.
For multi-page sites, plan the information architecture across all pages before wireframing individual ones:
- If
  /write-plan
  is registered in this session (detect per
```
../_shared/soft-deps.md
```
  ): delegate IA planning to
```
/write-plan
```
  , seeded with the site briefing and the list of pages. Use its output as the multi-page structural plan.
- Otherwise (superpowers not installed): announce the fallback exactly once per session using the verbatim text from
```
../_shared/soft-deps.md
```
  ("superpowers announcement") — unless it was already announced earlier in this session. Then sketch the IA inline: list pages, their primary content type, and the shared sections between them, and confirm with the user before moving on.

针对每个带有已获批简报的页面：

读取
```
stardust/briefings/{page}.md
```
中的页面简报。
若存在
```
stardust/briefings/_site.md
```
，读取其中的站点简报（包括内容复用映射）。
规划页面章节——用户体验探索：
- 若已安装
```
impeccable
```
  插件（已注册
```
/impeccable shape
```
  ），将章节规划任务委托给
```
/impeccable shape
```
  。
- 否则，使用
```
../_shared/fallback-brainstorm.md
```
  中的「线框图章节规划」模式。根据
```
../_shared/soft-deps.md
```
  ，impeccable备用方案将静默运行。无论采用哪种方式，都需明确：页面需要哪些章节、视觉层级如何、用户如何浏览内容。
- ```
/shape
```
  会生成设计简报——以此作为结构规划依据。
对于多页面站点，在绘制单个页面线框图前先规划跨页面信息架构：
- 若本次会话已注册
  /write-plan
  （根据
```
../_shared/soft-deps.md
```
  检测）：将信息架构规划任务委托给
```
/write-plan
```
  ，以站点简报和页面列表为基础。将其输出作为多页面结构规划依据。
- 否则（未安装增强功能）：按照
```
../_shared/soft-deps.md
```
  中的原文，在本次会话中仅发布一次备用方案通知（「增强功能通知」）——除非此前已发布过。然后在线规划信息架构：列出页面、各页面的主要内容类型以及页面间的共享章节，确认后再继续。

Phase 2: Render (Grey Mode)

第二阶段：渲染（灰色模式）

Render each wireframe as visual HTML in grey mode:

Pure grey layout: boxes, bars, shapes. No brand colors, no real fonts (system-ui is fine).
Background: light grey (#f5f5f5); elements in shades of grey.
Placeholder text as grey bars; images as grey rectangles with labels.
Annotations are required — every block gets a short italic
```
.note
```
or
```
.caption
```
describing what it represents, so the reviewer can evaluate the flow without guessing. Repeated items (pipeline nodes, host tiles, card grids) carry identifying labels ("01 · brand", "Claude Code"), not generic numbers. See wireframe-guide.md Annotations section.
Shows: section order, relative sizing, content density, spatial relationships.
Each section gets
```
data-section
```
,
```
data-intent
```
,
```
data-layout
```
attributes so the design stage can pick up the structure.
For multi-page sites: add
```
data-fragment
```
,
```
data-fragment-role
```
, and
```
data-fragment-source
```
attributes to reusable content sections — see wireframe-guide.md Content Reuse & Fragments section.
Include the JSON metadata block linking to the briefing (with
```
fragments
```
map for multi-page sites).
Write to
```
stardust/wireframes/{page}.html
```
.

If the upstream briefing was synthesized (provenance comment present, or generated during this pre-flight), carry forward a provenance block on the wireframe per

../_shared/skill-contract.md

Follow the full rendering rules in wireframe-guide.md.

以可视化HTML形式渲染每个线框图，采用灰色模式：

纯灰色布局：仅包含方框、条块、图形。无品牌色彩，无真实字体（可使用system-ui）。
背景：浅灰色（#f5f5f5）；元素采用不同灰度色调。
占位文本为灰色条块；图片为带标签的灰色矩形。
必须添加注释——每个模块需添加简短的斜体
```
.note
```
或
```
.caption
```
说明其用途，以便评审人员无需猜测即可评估流程。重复项（流水线节点、主机卡片、卡片网格）需添加识别标签（如"01 · brand"、"Claude Code"），而非通用编号。详见wireframe-guide.md的注释章节。
需展示：章节顺序、相对尺寸、内容密度、空间关系。
每个章节需添加
```
data-section
```
、
```
data-intent
```
、
```
data-layout
```
属性，以便设计阶段沿用该结构。
对于多页面站点：为可复用内容章节添加
```
data-fragment
```
、
```
data-fragment-role
```
和
```
data-fragment-source
```
属性——详见wireframe-guide.md的内容复用与片段章节。
包含链接至简报的JSON元数据块（多页面站点需包含
```
fragments
```
映射）。
写入
```
stardust/wireframes/{page}.html
```
。

若上游简报为生成内容（包含来源注释，或在前置检查阶段生成），需根据

../_shared/skill-contract.md

在线框图上添加来源信息块。

请遵循wireframe-guide.md中的完整渲染规则。

Phase 3: Serve

第三阶段：交付

Wireframes are self-contained HTML files. Open each file in the designer's default browser immediately after writing per

../_shared/skill-contract.md

Opening HTML artifacts. On macOS:

open stardust/wireframes/{page}.html

. Do not rely on the designer to open it manually.

If multiple wireframes were rendered in this phase (multi-page run), open each one so the designer can review in tabs.

In pipeline-automation mode (no designer present), skip the open.

线框图为独立HTML文件。写入完成后立即在设计师的默认浏览器中打开每个文件，遵循

../_shared/skill-contract.md

中的「打开HTML产物」规则。在macOS系统中执行：

open stardust/wireframes/{page}.html

。请勿依赖设计师手动打开。

若本阶段渲染了多个线框图（多页面运行），需打开每个文件以便设计师在标签页中评审。

在流水线自动化模式下（无设计师参与），跳过打开步骤。

Phase 4: Approval Gate

第四阶段：审批环节

Soft gate — the user approves structure, not visuals.

Present the wireframe and ask: "Does this structure match what you had in mind? What should change?"

Common feedback:

"Swap these sections" → Reorder, re-render.
"Add a section for [X]" → Add new section with data attributes, re-render.
"This section is too big/small relative to the rest" → Adjust proportions, re-render.
"I want something interactive here" → Add
```
data-interactive
```
attribute.

Iterate until the user approves. Then:

If
```
stardust/brand-profile.json
```
exists: "Wireframes approved. Run
```
/stardust:prototype
```
to upgrade them to branded prototypes."
If not: "Wireframes approved. Run
```
/stardust:brand
```
to capture your brand, then
```
/stardust:prototype
```
to layer it onto these wireframes."

Pipeline automation: When invoked as part of a full pipeline run, auto-approve and continue.

软审批环节——用户仅需审批结构，无需审批视觉效果。

展示线框图并询问："此结构是否符合你的预期？需要做哪些调整？"

常见反馈及处理：

"交换这些章节的位置"→重新排序并重新渲染。
"添加[X]章节"→添加带数据属性的新章节并重新渲染。
"此章节相对于其他章节过大/过小"→调整比例并重新渲染。
"我希望此处具备交互性"→添加
```
data-interactive
```
属性。

迭代至用户审批通过。然后：

若存在
```
stardust/brand-profile.json
```
："线框图已审批通过。运行
```
/stardust:prototype
```
将其升级为品牌化原型。"
若不存在："线框图已审批通过。运行
```
/stardust:brand
```
设置你的品牌信息，然后运行
```
/stardust:prototype
```
将品牌元素应用到这些线框图上。"

流水线自动化： 若作为完整流水线运行的一部分被调用，自动审批并继续流程。

Why Wireframes Before Design

为何先做线框图再做设计

Wireframes let you make structural decisions (what goes where, in what order, at what relative size) without being distracted by visual ones (what colors, fonts, and proportions). Separating the two means each decision gets full attention.

Users who already know the structure can skip this stage entirely and go briefings → design.

线框图让你专注于结构决策（内容放置位置、顺序、相对尺寸），而不会被视觉决策（配色、字体、比例）干扰。将两者分离意味着每个决策都能得到充分关注。

对结构已有清晰规划的用户可完全跳过此阶段，直接从简报进入设计环节。

Artifacts Written

产出文件

File	Description
`stardust/wireframes/{page}.html`	Grey structural wireframes — self-contained HTML

文件	描述
`stardust/wireframes/{page}.html`	灰色结构型线框图——独立HTML文件