设计简报

设计简报

Design Brief Skill — 在设计启动前，用一页可导出的 HTML 文档完成目标、用户、策略、标准、约束的一次性对齐。

能力矩阵

本 Skill 的三种运行模式，可单独运行也可叠加。最常见路径：链式模式（从 Frame / Scope / Audit 来）。

Brief 的产出形态在三种模式下完全一致（双通道：spark-output/context/brief.json + 完整 HTML），区别只在"提问多少 / 字段从哪里来"。

输入要求

信息完整度判断：必填项任一缺失 → 进入 Phase 3 引导追问；仅可选项缺失 → 直接生成 HTML 并在卡片内标注"待补充"。

Chain Context

上游读取（Phase 0.5 执行）

Step 1 · 扫描上下文来源（按顺序，找到任一即读取）：

• 会话内 marker：<!-- spark-context:frame --> / scope / audit / journey / hmw
• 项目文件：spark-output/context/frame.json / scope.json / audit.json / journey.json / hmw.json
• 都没有 → 跳过 Phase 0.5，按无上下文流程执行

Step 2 · 字段映射 checklist（找到上下文时，按下表逐项映射并预填 Brief 字段）：

来自 frame（最常见，无 PRD 场景）

来自 scope（有 PRD 场景）

来自 audit（改版场景）

来自 journey / hmw（增量来源）

• journey.stages[*].opportunities → 补充 strategy_dimensions 候选
• journey.key_moments[type=dropout-risk] → 加入 business_goal 强化（"降低 X stage 流失"）
• hmw.cards → 作为 strategy_dimensions[].tactics 的灵感源（不直接转，作为讨论起点）

Step 3 · 告知用户沿用情况（必做）：

读到上下文后必须明确告诉用户：

"已读到 [N 个] 上游 Skill 上下文：[列出 frame/scope/audit/...]。已自动预填以下字段，跳过对应提问：

• project_name = [...]
• business_context = [...]
• user = [...] ... 接下来从 [第一个未自动预填的字段，按 Phase 3 依赖顺序] 开始问你。"

Phase 3 提问顺序原则：跳过已被上游字段预填的字段，从下一个未填字段按 Phase 3 定义的依赖顺序开始问（完整依赖顺序 + 字数约束见下方 Phase 3 章节，不在此重复以避免漂移）。

下游输出（Phase 7 执行）

完成 Brief 内容后，同时做两件事：

1. 会话内输出：

   <!-- spark-context:brief -->
   { ...JSON（schema 见 frontmatter）... }
   <!-- /spark-context:brief -->
   

2. 写入项目文件：spark-output/context/brief.json（目录不存在时先创建）

下游可消费 Skill：Stories / Sitemap / Journey / Flow Web / Flow Mobile / Landing / Campaign / Chart / Edge / Motion / Check / Access / Metric / QA / PRD / Pitch / Retro。

字段流向下游

Brief 是链路锚点，下游消费量最大（13 个 Skill）。字段映射：

• brief.project_name → 全部 13 下游 Skill 的项目识别字段
• brief.user → Stories / Journey 的 persona 输入；PRD 的 Personas 段
• brief.business_goal → Pitch 的 The Bet / Why Now；PRD 的 Goals & Success Metrics；Metric 的 NSM 推导锚点
• brief.strategy_dimensions[] → Stories 的 acceptance_criteria 候选；Flow Web/Mobile 的 IA 决策依据；Check 的"策略一致性"走查项；PRD 的 Solution & Feature Scope 输入
• brief.design_criteria.quantitative → Metric 的 Driver / Counter Metrics 候选；QA 的还原度容差基线
• brief.design_criteria.qualitative → Check 的走查标准；Access 的合规目标基线
• brief.constraints → Sitemap / Flow Web/Mobile / Edge 的设计边界；PRD 的 Constraints & Risks
• brief.project_type / brief.project_subtype → Flow Web/Mobile 的 scenario 选型路由

⛔ 核心原则（全局硬约束，违反即判定任务失败）

1. 本 Skill 的视觉产物唯一来源是 prototype/brief.html。 它不是"参考"，而是必须被完整克隆并在其上做字段替换的源文件。
2. 禁止自写 HTML 结构、CSS 样式、JS 逻辑。 包括但不限于：自定义配色 / 字体 / 圆角 / 阴影 / 间距、引入 Tailwind / Bootstrap / 任何 UI 框架、"简化版"或"更干净的版本"。
3. 禁止凭记忆重建模板。 每次执行 Phase 6 都必须实际读取本 Skill 目录下的 prototype/brief.html（结构）+ prototype/brief-themes.css（样式），以这两个文件的当前实际内容为唯一基线。
4. 路径解析优先级（依次尝试，找到即用，不要凭印象编造路径）：
   1. 相对本 SKILL.md 的相对路径 prototype/brief.html
   2. 用文件搜索工具（glob / find / grep_search / list_dir 等任一可用工具）按文件名 brief.html 在 skill 安装目录下定位——常见位置含 ~/.qoderwork/skills/brief/prototype/brief.html、.claude/skills/brief/prototype/brief.html、<repo>/2-Define/Brief/prototype/brief.html、<plugin-pack>/skills/brief/prototype/brief.html 等，但不要硬编码——按文件名搜索更可靠
   3. 让用户提供绝对路径
5. 三次定位都失败才停止。 单次 read_file 失败不算"无法读取"——必须先尝试搜索；连续三次定位失败才告知用户"模板缺失"，不得降级、不得即兴生成替代 HTML。

触发条件

以下任意一种情况触发本 Skill：

• 用户说"帮我写设计简报 / Design Brief / 项目对齐文档"
• 用户说"启动一个设计项目"、"开始设计前先对齐方向"
• 用户使用 /设计简报 指令
• 前序 Skill（Scope、Journey、HMW）完成后，用户希望沉淀为一页文档

独立能力（无需连接器）

本 Skill 在完全离线、无任何连接器的场景下即可完整交付，所有方法论与输出形态不依赖外部系统：

• 一页纸 HTML 完整生成：目标 / 用户 / 策略 / 标准 / 约束七字段引导式追问 → Phase 4/4.5/4.6 策略维度勾选与 AI 草拟 → 完整 HTML 输出
• 链式上下文双通道：写入 spark-output/context/brief.json + 会话内 marker block，下游 14 个 Skill 可直接读取（无需连接器）
• HTML 一键导出 PNG：本地浏览器即可完成，无需云服务
• 三种运行模式自适应：独立模式（无前序）/ 链式模式（读本地 spark-output）/ 增强模式（识别 SparkDesign 组件标识）全部本地化运行
• 六大项目类型差异化模板：B2C / B2B / Tool / Content / 营销活动 / 平台型差异化策略库内置在 Skill 内

红线：缺连接器时 绝不 abort，所有引导式追问与 HTML 生成路径必须照常完成。

增强能力（连接器加持）

接入以下连接器后，可减少手动粘贴、提高对齐效率。所有连接器均为可选，未装时按"降级路径"列的方式回落。

接入触发：用户首次调用 /设计简报 时，Skill 主动检测已认证的连接器并显示「已检测到：Figma / Notion，将自动启用增强模式」提示，用户可在该次会话中选择关闭。

字段流向变化：

• 启用 Figma → chain.schema 新增可选字段 reference_visuals: array<{frame_url, thumbnail, description}>，下游 Flow Web/Mobile / Pitch 可直接复用
• 启用 Notion / 飞书 → chain.schema 新增可选字段 wiki_page_url: string，下游 Skill 在生成自己的文档时可在底部引用 Brief wiki 链接
• 启用 Linear / Jira → chain.schema 新增可选字段 source_epic: {id, url, title}，PRD / Stories 下游读取后可自动关联同一 Epic

所有新增字段都是 可选，未启用连接器时字段缺省，下游 Skill 必须能容忍缺省。

执行流程（Route B）

按以下 8 个阶段顺序执行。每个阶段完成后再进入下一阶段，不得跳跃。

Phase 0 — 触发识别

确认触发来源（自然语言 / 指令）。无需向用户确认，直接进入 Phase 0.5。

Phase 0.5 — 上下文检查

检查当前会话是否已有前序 Skill 输出的项目上下文（Scope 输出、PRD 摘要、Journey 结论等）。

• 有上下文：提取可复用字段（项目名称、项目类型、业务目标、用户），预填入对应模块，告知用户："我从上下文中提取了以下信息，可以直接沿用或修改。" 然后进入 Phase 1。
• 无上下文：直接进入 Phase 1。

Phase 1 — 项目类型选择

向用户提问，确认项目所属大类与子类型。若用户描述已足够清晰，可直接判断，无需再问。

六大类及子类型：

用户不确定时，AI 根据描述直接判断并告知选择理由，用户确认后继续。

Phase 2 — 文档判断

询问用户是否有已有文档（PRD、需求文档、Research 报告等）：

• 路径 A（有文档）：读取文档，提炼关键信息填入各模块，告知"以下字段信息不足，需要补充：[缺失列表]"，逐一追问缺失项。
• 路径 B（无文档）：展示空白模板结构，进入逐字段追问模式。

Phase 3 — 内容填写

按依赖优先顺序逐字段追问，不得按字段编号顺序（背景决定目标，目标决定用户，用户决定策略）：

业务背景 → 业务目标 → 用户 → 设计策略 → 设计标准 → 边界约束 → 不做什么

追问规则：

• 每次只问一个字段。
• 每个问题附带 AI 推荐答案，格式：> 推荐：[AI 建议内容]，用户可直接采纳、修改或否定。
• 若用户已在上文提及相关信息，不重复追问，直接沿用并告知。

各字段字数上限（HTML 卡片容量约束，生成时严格遵守）：

超出上限时，AI 应主动精简，优先删去冗余修饰词，保留关键数字与动词。

专属字段追问（Phase 1 确定类型后激活，在标准字段完成后追问）：

见下方「字段结构」章节中各类型的专属必填字段。

Phase 4 — 设计策略维度选择

根据项目类型，展示过滤后的设计策略维度供用户勾选。

管理类例外：不展示策略维度，改为填写"执行路径"（本周期的核心行动路线）。

过滤规则：

用户勾选维度后，进入 Phase 4.5（AI 先写策略草稿），而非立即走追问。

Phase 4.5 — 设计策略草稿（AI 先行）

在走结构化追问前，AI 先基于 业务背景 / 业务目标 / 用户 三项输入，为每个勾选的维度自动生成一份 三段式草稿，交给设计师批改而非从零写起。

草稿结构（每个维度一份）：

[维度名]
  主张  ·  [一句判断，≤ 22 字]
  手法  ·  [动作 1，≤ 16 字]
         ·  [动作 2，≤ 16 字]
         ·  [动作 3，≤ 16 字]（可缺省）
  依据  ·  [对应业务目标 / 用户痛点，≤ 25 字]

输出样例（以"交互设计"为例，假设业务目标含"跳出率↓20%"）：

交互设计
  主张  ·  结算压缩到 3 步，错误校验前置
  手法  ·  地址 / 支付合并一屏
         ·  字段实时校验
         ·  进度条常驻顶部
  依据  ·  对应 B2（跳出率↓20%）；用户低容忍繁琐

处理规则：

• 每个维度以卡片形式并排展示，设计师逐条处理。
• 每份草稿提供三种操作：✓ 采纳 / ✎ 改写 / ✗ 否决后进入手写追问。
• 全部确认后，进入 Phase 5；仅被 ✗ 否决 的维度才走 Phase 4.6 的追问式填写。

Phase 4.6 — 三段式结构化追问（仅处理 Phase 4.5 被否决的维度）

对被否决的维度，改问结构化三连问（不再使用开放式的"你打算从哪个角度切入"）：

Q1 · 主张｜[维度名] 上你打算用什么方式推动目标？（≤ 22 字）
    > 推荐：[AI 建议]
    > 可选角度（选 1–2 或自提）：[子问题池抽取 2–3 条]

Q2 · 手法｜具体落到 2–3 个可执行动作是什么？（每条 ≤ 16 字）
    > 推荐：① [建议 1]  ② [建议 2]  ③ [建议 3]

Q3 · 依据｜这条策略对应哪个业务目标或用户痛点？（≤ 25 字，可跳过）
    > 推荐：对应 [业务目标编号]；源自用户 [痛点关键词]

子问题池（AI 追问时从对应维度抽取 2–3 条作为启发，按"切面"分组）：

Phase 5 — 完整性校验 + 草图预览

所有字段填写完成后：

1. 检查 7 个通用模块是否均有实质内容（非空、非"待定"）。
2. 以提示卡片列出缺陷：⚠ [字段名]：内容过于模糊，建议补充 [具体建议]
3. 输出带视觉结构的文字草图预览（用 Markdown 表格或代码块模拟 Bento 布局），让用户确认信息密度与结构。
4. 用户可对话修改任意字段后再生成 HTML。

草图预览示例（横版默认布局，用代码块 ASCII 模拟 Bento 网格）：

┌──────────────────────────────────┬────────────────┬────────────────┐
│ 业务背景  Business Context        │ 业务目标 Goal  │ 用户 User      │
│ 平台成熟期，GMV 增速趋缓，购物车  │ · 购物车转化   │ · 25–40 女性   │
│ 放弃率高于行业 12pp，Q2 增长专项  │   45%→58%      │ · 移动端为主   │
│ 聚焦购物车到支付转化路径。        │ · 跳出率↓20%  │ · 月购 3 次+   │
│                                  │ · 支付率↑8%   │ · 低容忍繁琐   │
├──────────────────────────────────┴────────────────┼────────────────┤
│ 设计策略  Design Strategy                          │ 设计标准       │
│ ┌─ IA ─────────┬─ 交互 ─────────┬─ 情感化 ────────┐│ Design Criteria│
│ │ 主张：核心操 │ 主张：结算压  │ 主张：支付动效 ││ · 步骤≤3 [定量]│
│ │ 作提至首屏   │ 缩到 3 步     │ + 加购确认     ││ · 完成率>88%   │
│ │ 手法：       │ 手法：        │ 手法：         ││ · 感知清晰[定性]│
│ │ · 精简层级   │ · 合并结算屏  │ · 支付成功动效 ││                │
│ │ · 去冗余跳转 │ · 实时校验    │ · 加购即时反馈 ││                │
│ │ 依据：B2     │ · 进度常驻    │ 依据：B4 客诉↓ ││                │
│ └──────────────┴───────────────┴────────────────┘│                │
├──────────────────────────────────┬────────────────┴────────────────┤
│ 边界约束  Constraints             │ 不做什么  Out of Scope           │
│ · 8 周内上线                      │ · 商品详情页不改                │
│ · 支付模块不可改动                │ · 会员积分不重设                │
│ · 遵守 DS v2.3                    │ · PC 端不覆盖                   │
│ · 2 名设计师                      │ · 推荐算法不调                  │
└──────────────────────────────────┴────────────────────────────────┘

或 Markdown 表格版（信息密度更高、便于对话中快速修订）：

两种格式任选其一输出，推荐 ASCII 版（更接近最终视觉）。

Phase 6 — 视觉输出

生成完整 HTML 文件（基于 prototype/brief.html 模板）。

6.0 ⛔ 绝对禁止（任一违反即视为生成失败，必须重做）

• ❌ 从零编写任何 <style> 内容或新增内联 style="..."
• ❌ 引入 Tailwind、Bootstrap、DaisyUI、shadcn、任何 CDN 样式表或 UI 框架
• ❌ 自行定义颜色、字体、圆角、阴影、间距、栅格等视觉 token
• ❌ 删除、替换、"简化"工具栏、主题切换器、字号控件、导出按钮
• ❌ 修改 <style> 内任何 CSS 变量、data-theme 规则、.brief-canvas grid 布局
• ❌ 修改 <script> 内任何 JS（主题切换 / 布局切换 / 字号缩放 / fitCards / topbar 可编辑 bindEditable / modern-screenshot 导出）
• ❌ 以"更现代"、"更简洁"、"移动端优化"为由重写模板
• ❌ 生成一个只有 100–300 行的"轻量版" HTML（合并后的完整文件约 1500 行——结构 ~500 行 + 样式 ~1040 行，成品行数不得低于原型 95%）
• ❌ 删除或改写 .topbar-title-wrap / .topbar-meta-wrap 容器、.topbar-title-edit / .topbar-meta-edit 铅笔按钮、body.is-exporting 相关规则（这是 topbar 文案可编辑功能的必需 DOM / CSS）
• ❌ 删除或修改 modern-screenshot 脚本引用（当前用 jsDelivr CDN，保证导出 PNG 可用；不得改成不可达的本地路径、不得删除此行）

6.1 ✅ 生成步骤（必须严格按序执行）

Step 1 · 读取模板结构（强制）

读取本 Skill 目录下的 prototype/brief.html（结构文件，约 500 行），以其实际内容作为唯一基线。禁止凭记忆或凭 SKILL.md 里的片段推断模板结构。

v0.5.9 变更：模板已拆分为结构（brief.html ~500 行）+ 样式（brief-themes.css ~1040 行，含 9 套主题 CSS 变量）。Step 1 只读结构文件，大幅降低 context 占用。

路径解析协议（依次尝试，禁止凭印象编造路径——尤其禁止编造仓库结构路径如 3-Ideate/Brief/...、SparkSkillHub/2-Define/... 等，AI 既不知道用户从哪安装、也不知道平台的实际安装目录）：

1. 首选：用相对本 SKILL.md 的相对路径 prototype/brief.html 直接 read_file（多数 IDE / Agent 平台支持以 SKILL.md 同目录为基准）
2. 失败则搜索：调用文件搜索工具按文件名 brief.html 定位，候选位置含但不限于：
   • ~/.qoderwork/skills/brief/prototype/brief.html（QoderWork 安装目录）
   • .claude/skills/brief/prototype/brief.html（Claude Code 安装目录）
   • <product-design-pack>/skills/brief/prototype/brief.html（解压套件）
   • <repo>/2-Define/Brief/prototype/brief.html（开发仓库源码）
3. 再失败则问用户："请告诉我你电脑上 brief.html 的绝对路径，或确认 Brief Skill 是否完整安装"
4. 三轮全失败才停止——单轮失败不要立即停止，更不要"降级输出 markdown 版本"——只有定位真的不可能时才告知模板缺失

若读取失败 → 立即停止 → 告知用户"无法访问原型模板，本次不生成 HTML" → 不得即兴兜底。

Step 1.5 · 读取样式文件（强制）

读取与 brief.html 同目录下的 prototype/brief-themes.css（~1040 行，含 9 套主题的 CSS 变量 + 布局样式 + 打印媒体查询）。路径定位策略与 Step 1 一致（同目录下的 brief-themes.css）。

为什么单独读取：CSS 文件内容是静态的，不需要做字段替换，在 context 窗口紧张时可以推迟到 Step 2 之前再读取，减少中间步骤的 context 占用。

Step 2 · 全文克隆（合并结构 + 样式）

将 prototype/brief.html 的结构 + prototype/brief-themes.css 的样式合并为一个自包含的单 HTML 文件，写入目标文件（默认路径 spark-output/brief/[项目名].html，目录不存在时先创建，由用户确认）。

合并方法：在输出 HTML 中，将 <style></style> 替换为 <style>\n{brief-themes.css 全部内容}\n</style>，并删除 <link rel="stylesheet" href="brief-themes.css"> 行（输出文件必须自包含，不依赖外部 CSS 文件）。

合并后的新文件应与原型的视觉效果完全等价。

⛔ 克隆后编辑约束：Write 工具写出的新文件，必须先 Read 再 Edit。不能直接对刚 Write / Bash cp 生成的文件执行 Edit——Edit 工具要求该文件在当前会话内曾被 Read 过。推荐流程：① 用 Write 一次性写出完整替换后的 HTML（最可靠）；② 或 Write 克隆 → Read 目标文件 → 逐字段 Edit 替换。禁止跳过 Read 直接 Edit，否则会触发 "File has not been read yet" 错误。

Step 2.1 · 依赖说明（无需额外拷贝）

HTML 里 modern-screenshot 通过 jsDelivr CDN 引用（https://cdn.jsdelivr.net/npm/modern-screenshot@4/dist/index.js），生成目标文件时不需要再同步拷贝任何 js 文件。只要用户打开 HTML 时能联网，"导出 PNG"即可工作。若用户需要离线使用，再另行下载 UMD 文件并将 src 改回相对路径。

Step 3 · 仅替换以下字段（表格列出的是唯一允许修改的位置，其余一行都不得改动）：

.hint 副标题不替换：每张卡片第二行 <p class="hint">...</p> 是字段含义的固定释义（如「当前业务处于什么阶段，触发本次设计的原因」），必须保持与模板逐字一致。只替换 .hint 之后的正文 <p> / <ul class="list"> / .s-grid 内容。 设计标准 list 结构强约束：每条必须是 <li><span class="tag" data-kind="quant|qual">定量|定性</span><span class="text">...</span></li>，tag 放行首（pill 胶囊形态），不是行尾纯文字。

Step 4 · 严格保留清单（一行都不能改）

• <head> 内全部 <link>（字体 preconnect + Google Fonts url）
• <style> 标签内全部 CSS（9 套主题变量 + 布局 + 字号体系 + 卡片样式 + topbar 可编辑态样式 + body.is-exporting 规则）
• .toolbar-left / .toolbar-right 的 HTML 结构与控件 id（#themeSelect / #accentPicker / 布局按钮组 / 字号按钮组 / 打印按钮 / #exportBtn）
• .topbar-title-wrap / .topbar-meta-wrap 容器 + 两个 .topbar-*-edit 铅笔按钮（含 SVG）
• <script> 标签内全部 JS（主题切换、data-ratio 切换、data-scale 切换、fitCards、bindEditable topbar 可编辑 IIFE、modern-screenshot 导出——必须使用 domToBlob + URL.createObjectURL + isInIframe() 环境检测分流（独立浏览器走 directDownload，iframe 预览态走 showExportModal 浮层，浮层内必须用 FileReader.readAsDataURL(blob) 把预览图 src 切换成 base64 data URL，并用 <a class="export-preview-link" href="${dataUrl}" download> 包裹 <img>——这是 sandbox iframe 下 Mac Option + 点击 / Windows 右键「图片另存为」能工作的唯一条件），不得回退到 domToPng + data URL 的一次性下载，不得在浮层内添加下载按钮 / 复制到剪贴板 / 新窗口打开 等动作按钮（sandbox 已实测全部拦截，是无效噪音））
• <script src="https://cdn.jsdelivr.net/npm/modern-screenshot@4/dist/index.js"></script> 引用一行（jsDelivr CDN，不得改成不可达的本地路径，不得删除此行）
• .brief-canvas 内 7 张卡片的 DOM 顺序、class 名、每张卡片的 SVG line icon（stroke-width="1.5" / stroke-linecap="round" / stroke-linejoin="round" 全部保留）

Step 5 · 交付前自检（每项必须勾上，未全部通过则回到 Step 1 重做）

• 文件行数 ≥ 原型行数的 95%（原型约 1555 行，成品 ≥ 1475 行）
• <style> 块完整保留，未被精简
• #themeSelect、#accentPicker、#exportBtn 三个核心控件 id 均存在
• .topbar-title-edit、.topbar-meta-edit 两个铅笔按钮存在且可聚焦
• 文件含 <script src="https://cdn.jsdelivr.net/npm/modern-screenshot@4/dist/index.js"></script> 的 jsDelivr CDN 引用
• 导出逻辑包含 isInIframe() / directDownload() / showExportModal() 三个函数，及 .export-modal-* / .export-preview-link 相关 CSS
• showExportModal 内使用 FileReader.readAsDataURL(blob) 把预览图 src 切换成 base64 data URL，并用 <a class="export-preview-link" download> 包裹 <img>（sandbox iframe 下 Mac Option + 点击 / Windows 右键另存的唯一条件）
• 浮层内未出现「下载到本地 / 复制到剪贴板 / 新窗口打开」等动作按钮（sandbox 已实测全拦，是无效噪音）；浮层文案含「强烈推荐系统浏览器打开」+ Mac / Windows 分平台操作说明
• <body> 属性齐备：data-theme / data-ratio="16-9"（横版默认）/ data-scale="md"（中号默认）三者均存在
• <body data-theme="..."> 已按 6.3 规则设置为匹配项目类型的风格
• 7 张卡片的顺序、class、SVG icon 与原型一致
• 设计标准每个 <li> 均以 <span class="tag" data-kind="quant|qual"> 开头（行首 pill）
• 未引入任何 Tailwind / Bootstrap / 外部 CSS 框架
• 未出现任何"自定义"颜色/字号/阴影/圆角（所有视觉 token 均来自原型 CSS 变量）
• 视觉验证：如平台支持 present_files 或浏览器预览，展示 HTML 给用户确认（重点检查：策略维度卡片数量与网格匹配、文字未溢出）。不支持预览时提示用户手动在浏览器打开检查。

6.2 生成时必须同步替换的字段

• HTML <title> 标签 → 替换为项目名称（例："Design Brief — [项目名称]"）
• .topbar-title 文本 → 替换为项目名称
• .topbar-meta 文本 → 替换为"[项目子类型] · [生成日期 YYYY-MM-DD]"（例：产品迭代 · 2026-04-29）
• 7 个 .card 内容 → 按 Phase 3 收集的字段填入
• <body> 的 data-theme → 设为本项目匹配的默认风格（见下方风格规则）

6.3 默认风格规则（根据项目类型自动匹配）

生成后告知用户："已用 [风格名] 风格生成（完全基于 prototype/brief.html 模板克隆，仅替换文字字段），可在底部工具栏切换主题 / 自定义主题色 / 切换布局（横版 / 竖版 / 方版）/ 调整整体字号，满意后打印或导出 PNG。"

Phase 7 — 保存项目上下文（双通道输出）

按 chain-protocol.md 第 2.1 节的双通道规则同时输出：

按 chain-protocol.md §2.1 v1.1 智能适配规则：

Step 1 — 写盘到 spark-output/context/brief.json（必做，主持久化通道；目录不存在先创建）。

⛔ JSON 安全（详见 chain-protocol.md §2.1.2）：写入前必须检查所有字符串值中的引号字符。用户原文中的中文弯引号 ""（U+201C/U+201D）必须替换为 「」，否则会被存储为 ASCII " 破坏 JSON 结构，导致下游全链路（Dashboard 更新 + 下游 Skill 读取）解析失败。写盘后用 python3 -c "import json; json.load(open('spark-output/context/brief.json'))" 自检。

写入以下完整 JSON：

{
  "skill": "brief",
  "generated_at": "<ISO8601 当前时间>",
  "project_name": "",
  "project_type": "",
  "project_subtype": "",
  "business_context": "",
  "business_goal": [],
  "user": [],
  "strategy_dimensions": [
    {
      "dimension": "",
      "thesis": "",
      "tactics": [],
      "rationale": ""
    }
  ],
  "design_criteria": { "quantitative": [], "qualitative": [] },
  "constraints": [],
  "out_of_scope": [],
  "style": "",
  "ratio": "16-9",
  "scale": "md"
}

Step 2 — chat 输出紧凑 marker（必做，⛔ 不要在 chat 内重复输出 Step 1 的完整 JSON）：

<!-- spark-context:brief ref="spark-output/context/brief.json" -->
Brief 已保存：project=[project_name]，project_type=[type/subtype]，persona=[user 第一条简述]，[N] 个 strategy_dimensions
<!-- /spark-context:brief -->

降级 fallback：若 Step 1 写盘失败（chat-only 平台），输出完整 JSON marker（无 ref 属性，marker 之间放裸 JSON）作为唯一持久化通道。

更新链路面板（必做，失败不阻断）

协议依据：chain-protocol.md §九「面板自动生成约定」。本步在 Handoff 之前执行；告知用户的提示必须作为独立段落输出，禁止折叠进 Handoff 末尾、禁止静默跳过。

1. 找模板：定位 _shared/dashboard-template.html（依次：相对套件根 → glob dashboard-template.html 搜套件安装目录 → 三轮都失败时，用独立段落醒目告知用户：⚠️ 链路面板模板未找到（套件安装可能不完整，建议重装）。本 Skill 已正常完成，下游链路不受影响。 然后跳过本步、继续 Handoff，不阻断 Skill 完成）。
2. 聚合 STATE：扫 spark-output/context/*.json，聚合为 {"project":"<brief.project_name 或 frame.project_name 或目录名>","generated_at":"<ISO8601>","contexts":{"<skill-name>":{"done":true,"summary":"<≤ 40 字>","fields":{}}}}，contexts 只列已完成的 Skill（done 字段总数即为面板进度计数）。
3. 克隆模板到 spark-output/dashboard.html（覆盖），用正则 /\/\*__SPARK_STATE_INJECT__\*\/null/ 替换为 /*__SPARK_STATE_INJECT__*/<JSON.stringify(STATE)>。
4. 独立段落告知用户（强提示，单独成段，与 Handoff 之间空一行；根据 Object.keys(STATE.contexts).length（记作 done）选模板）：
   • done === 1（本项目第一次生成 dashboard）输出长版：

     📊 链路控制台已生成：spark-output/dashboard.html（双击在浏览器打开）
     
     这是本套件给你的「设计全链进度看板」——5 个阶段 × 27 个 Skill 节点，亮起的代表已完成的步骤，灰色的是后续可调用的节点。每跑完一个 Skill 都会自动更新，建议钉在浏览器一个标签页里随时回看，能看清「现在在哪一步、下游还差什么、链路是否健康」。
     

   • done > 1（后续更新）输出短版：

     📊 链路面板已更新 · 进度 [done]/27 · spark-output/dashboard.html
     

5. 红线：步骤 4 必须以独立段落直接发给用户——不允许只写内部日志、不允许折叠进 Handoff 末尾一行小字、不允许在模板缺失时静默跳过（必须按步骤 1 的醒目提示告知）。

Handoff 提示（必输出）

协议：按 _shared/next-skill.md 三层结构模板输出；前 5 候选由 _shared/skill-graph.json 的依赖图算法实时算（done ⊆ ready，按 next_hint.preferred → alternatives → 同阶段 → anchor → fan-out 排序），优先建议从 _shared/skill-graph.json#skills[id="brief"].next_hint 读取。

首行模板：✅ 设计简报 已完成，business_goal + 5 维 strategy_dimensions + 9 项 design_criteria 已沉淀。

本 Skill 的 next_hint（来自 skill-graph.json，不可在此 SKILL.md 内硬编码覆盖）：

• preferred：/journey
• 优先理由：用户视角可视化（含情感曲线 + dropout-risk 标注）通常是 Brief 之后最有价值的一步——把抽象策略变成可视的体验断点。
• alternatives：/stories (想直接做工程拆解走结构化路径) · /pitch (需要先对齐决策者再执行) · /sitemap (已确定走 IA 优先路径)
• emoji：🎨

红线：

• ❌ 禁止在本段硬编码候选清单（如「进入 Stories / Journey / Sitemap」）——所有候选必须由算法实时生成
• ❌ 禁止按「文档类 / 视觉类 / 决策类」再分类候选（v0.5.5 起，分类已折叠进 next_hint.alternatives）
• ❌ 禁止与「更新链路面板」段合并——两段必须各自独立成段，中间空一行
• ❌ 禁止漏第 2 行候选清单——即使候选只有 1 个、或为空（终端节点）也要写出来

字段结构（Route A）

通用模块（7 个，所有类型必填）

字段区分说明：

• 业务目标 = 业务 KPI（转化率、留存率等可量化结果）
• 设计标准 = 体验层面的判断依据（任务完成率、SUS 评分等），单列混合列表，每条用行首 pill 标注定量 / 定性

各类型专属字段

产品设计 — 全新产品

产品设计 — 产品迭代

产品设计 — 产品改版

营销与传播 — 营销设计

营销与传播 — 会议与活动

营销与传播 — 线下物料

营销与传播 — 视频设计

品牌设计 — 全新品牌

品牌设计 — 品牌升级

研究与评估 — 用户研究

研究与评估 — 设计走查

研究与评估 — 设计咨询

系统与资产 — 设计系统与规范

特殊介质 — 硬件设计

特殊介质 — 互动设计

管理类

视觉输出规格（Route C）

Bento 布局

关于"布局"而非"比例"： 工具栏提供"横版 / 竖版 / 方版"三套布局模板（底层 data-ratio 仍为 16-9 / 4-3 / 1-1，仅切换 grid 排版）。画布宽度固定 1280px、高度完全跟内容，不再强制锁定画幅比例 —— 所见即所导。

横版（默认，data-ratio="16-9"） — 4 列 × 3 行，适合 Keynote / 幻灯片：

[业务背景 ×2列] [业务目标 ×1列] [用户 ×1列]
[设计策略 ×3列]               [设计标准 ×1列]
[边界约束 ×2列] [不做什么 ×2列]

方版（data-ratio="1-1"） — 3 列 × 4 行，顶部通栏 + 底部对半，适合社媒分享：

[业务背景 ×3列 顶部通栏]
[业务目标 ×1] [用户 ×1]       [设计标准 ×1]
[设计策略 ×3列]
[边界约束 ×1.5列] [不做什么 ×1.5列]

实现用 6 列子网格：业务背景 / 设计策略各 span 6，业务目标 / 用户 / 设计标准各 span 2，边界约束 / 不做什么各 span 3。

竖版（data-ratio="4-3"） — 3 列 × 4 行，底部对半，适合 A4 / 文档：

[业务背景 ×1.5列]              [业务目标 ×1.5列]
[用户 ×1]        [设计策略 ×2列 × 跨2行]
[设计标准 ×1]
[不做什么 ×1.5列]              [边界约束 ×1.5列]

实现用 6 列子网格：业务背景 / 业务目标 / 不做什么 / 边界约束各 span 3，用户 / 设计标准各 span 2，设计策略 span 4 列 × 2 行。

风格体系

HTML 内嵌所有风格的 CSS 变量，通过 data-theme 属性切换，无需重新加载。

已实现的 9 个风格（工具栏下拉完整可用）：

原规划中的 Paper（mintlify）、Pulse（verge）、Blueprint / Signal / Canvas / Void / Ink 均已从工具栏移除，不再作为默认或扩展风格。Paper / Pulse 待 CSS 补齐后再考虑加回。

HTML 工具栏规格

工具栏位于 Brief Canvas 下方，左右两组：

[主题 ▾] [🎨 accent]  |  [布局 横版 | 竖版 | 方版]  |  [字号 小 | 中 | 大]    [打印 / PDF] [导出 PNG]

左侧控件（.toolbar-left）：

• 主题下拉：<select id="themeSelect">，选中即时切换 data-theme，无动画延迟。
• 主题色自定义：<input type="color" id="accentPicker"> 圆形色板，实时覆盖 --accent；切换主题时自动回填该主题的默认 accent。
• 布局按钮组：横版 / 竖版 / 方版 三按钮（底层仍切换 data-ratio），默认激活 横版。激活态反色（background: var(--text); color: var(--brief-bg)）。画布高度完全跟内容走，不再强制锁定比例 —— 所见即所导。
• 字号按钮组：小 / 中 / 大 三按钮，切换 data-scale（对应 --size-mult = 1 / 1.2 / 1.45），所有字号 token 等比缩放，默认激活 中。

每次任一切换后都会调用 fitCards() 重新检测卡片内容是否溢出。

右侧控件（.toolbar-right）：

• 打印 / PDF：调用 window.print()，@media print 隐藏工具栏。

• 导出 PNG：调用 modern-screenshot（jsDelivr CDN 加载）的 domToBlob(#brief-canvas, { scale: 2, backgroundColor: 页面背景色, type: 'image/png' }) 生成 Blob。根据运行环境自动分流：

  • 独立浏览器（window.top === window）：用 URL.createObjectURL + 临时挂 DOM 的 <a> 一键下载，按钮显示"已保存 ✓"。

  • iframe 预览态（qoderwork 对话卡片、Notion embed 等，sandbox 同时拦截了 <a>.click() / clipboard.write / window.open，实测三条路径全无效）：弹出 .export-modal 浮层，浮层内仅保留 <a class="export-preview-link" href="<data-url>" download> 包裹的预览图，不得添加任何动作按钮（都是无效噪音）。文案给用户两条路径：

    1. 强烈推荐：在系统浏览器（Chrome / Safari / Edge）中打开此 HTML ——一键下载，无需额外操作，是最可靠路径；
    2. 若必须在预览态导出，在预览图上：Mac 用 Option + 点击触发下载弹窗；Windows 用右键 → 图片另存为…。

    实现要点：先用 URL.createObjectURL(blob) 兜底 previewImg.src 和 .export-preview-link[href]，再异步 new FileReader().readAsDataURL(blob)，onload 里把两者切换成 data:image/png;base64,...（blob URL 会被 sandbox 判为跨源导致右键菜单置灰 / Option 点击失效）。

  按钮保留 loading 态（"生成中…"）+ 成功反馈（"已保存 ✓" / "请在浮层点图保存 →"）+ 防抖。导出开始会给 <body> 加 is-exporting 类名，临时隐藏 topbar 铅笔按钮，避免 wrap 压缩导致文字折行。浮层关闭或 8 秒后 revokeObjectURL 释放。

字体加载

<!-- Google Fonts 优先，系统字体回退；仅加载 9 套主题实际使用的字族 -->
<link href="https://fonts.googleapis.com/css2?family=Cormorant+Garamond:wght@400;500;600
  &family=DM+Mono:wght@300;400;500
  &family=DM+Sans:wght@300;400;500
  &family=EB+Garamond:wght@400;500
  &family=Inter:wght@300;400;500;600;700
  &family=JetBrains+Mono:wght@400;500
  &family=Noto+Sans+SC:wght@400;500;600
  &display=swap" rel="stylesheet">

离线时回退：-apple-system, 'PingFang SC', sans-serif（无衬线）/ Georgia, serif（衬线）。

输出物

本 Skill 产出一个完整可运行的 HTML 文件（prototype/brief.html），包含：

1. 顶部项目信息栏（项目名称、类型、日期 + 右侧 "DESIGN BRIEF" brand 标识），标题与元信息支持 hover 铅笔按钮 → 点击即编辑（刷新恢复 AI 默认值；导出 PNG 时自动隐藏铅笔防折行）
2. Bento 布局的 7 模块 Brief Canvas（每模块配 SVG line icon）
3. 底部工具栏（主题下拉 + 主题色自定义 + 布局切换 + 字号缩放 + 打印 / 导出）
4. 所有已实现风格的 CSS 变量（9 套，通过 data-theme 切换）
5. modern-screenshot 导出逻辑：domToBlob + URL.createObjectURL + iframe 检测分流（独立浏览器一键下载；iframe 预览态弹浮层提供「下载 / 剪贴板 / 新窗口 / 图片右键另存」四条兜底路径），含 loading 态 + 防抖 + 成功反馈 + is-exporting 防折行
6. 卡片内容自适应缩放（fitCards：溢出时逐级降低字号至 9px 下限）

HTML 中不依赖外部框架，仅依赖：

• Google Fonts（远程 CSS，需联网加载字体，不联网则自动回退到系统字体）
• modern-screenshot UMD（通过 jsDelivr CDN 加载，用于"导出 PNG"）

原方案曾用同目录 ./modern-screenshot.umd.js 本地引用，但在 qoderwork 等工作流中生成 HTML 时不会自动同步拷贝二进制文件，导致"导出 PNG"报 modernScreenshot is not defined。现统一改为 CDN，生成后无需任何附加文件即可使用。

质量规范

本章节是 Skill 完成度的高层判定标准，与 Phase 6 内部的执行级约束互补。Phase 6 是"该怎么做"，本章节是"做对了没有"。

🚫 红线规则（违反即任务失败，无降级空间）

• 视觉产物必须基于 prototype/brief.html 克隆——不得自写 HTML / CSS / JS，不得引入任何 UI 框架（详见 Phase 6.0）
• 必须输出双通道：spark-output/context/brief.json 写盘 + chat 内紧凑 marker（含 ref= 属性）
• 必须按 chain-protocol §2.1 v1.1.1 执行顺序：先写盘 → 自检行 → 渲染报告 → marker → handoff，不得颠倒
• 7 张卡片的 DOM 顺序、class 名、SVG line icon 必须与原型逐字一致
• 设计标准每条必须以 <span class="tag" data-kind="quant|qual"> 行首 pill 开头，不得放行尾纯文字
• 三轮路径定位都失败才停止——单次 read_file 失败必须先用文件搜索工具定位（详见 Phase 6 路径解析协议），不得凭印象编造仓库结构路径，也不得直接降级输出 markdown 版本

⚠️ 反模式（常见错误，需主动规避）

• ❌ 把"业务目标"和"设计标准"混为一谈——前者是业务 KPI（如"转化率提升 8%"），后者是体验判断依据（如"任务完成率 > 88%"）
• ❌ 按字段编号顺序追问（1→2→3...）——必须按依赖顺序：业务背景 → 业务目标 → 用户 → 设计策略 → 设计标准 → 边界约束 → 不做什么
• ❌ 在 Phase 4 跳过 Phase 4.5 直接走 4.6 追问——草稿在前（AI 先写），追问只处理被否决的维度
• ❌ 在 chat 内重复输出完整 JSON——应只输出紧凑 marker（≤ 80 字摘要），完整 JSON 写盘到文件
• ❌ 凭记忆重建 HTML 模板——必须每次 read_file 实际读取 prototype/brief.html
• ❌ 删除或"简化"工具栏控件、topbar 铅笔按钮、modern-screenshot 导出逻辑——它们是产物功能完整性的必需 D

…(truncated)