specs-ui

使用 Tailwind 制作的规格页面原型

此技能会生成一个小型规格网站（每个屏幕对应一个页面，以单个多页面 artifact 发布），作为业务人员与开发人员之间的参考：每个屏幕都使用 Tailwind 制作原型（桌面版和移动版），标明其在流程中的位置，并附上相关规则。我们会反复迭代，直到确认功能和呈现效果，然后开发工作沿用相同的 tokens 和 classes。

文档、标签、注释和交流内容使用法语。代码（脚本、属性、变量、技术标识符）使用英语；代码注释可以使用法语。

规格涵盖功能和 UI：屏幕、注释或规则中不得出现任何库名称、函数名称、API 字段名称或技术标记（redaction-specs.md，“功能规格，不含代码”）。

<skill> 表示此技能的目录：从用户的项目中使用 node <skill>/scripts/… 运行脚本。

节省上下文（请先阅读）

规格项目很快就会变大：一批约十个屏幕放在同一页面上会超过 300 Ko。因此，规格会按屏幕拆分为多个页面，而且绝不能重读无关内容。规则如下：

1. specs/ui/CONTEXTE.md 是项目记忆。 继续工作时，先阅读此文件，并尽可能仅依靠它。文件包含决策、视觉标识、布局、用户画像、主线中的确切字符串事实（标识符、标签、时间：每当某个屏幕新增此类内容时，都要添加）、带锚点的清单、各批次的状态及其 URL、项目专属约定、未解决的问题和下一步。从第 1 步开始，根据 templates/contexte.md 创建此文件，并在每个步骤结束时更新。文件应少于 200 行。
2. 绝不读取已构建的页面（specs/ui/site/）。 规格存放在 specs/ui/sources/：每个屏幕状态对应一个文件。只读取和修改相关文件（sources/<lot>/070-e15d.html、sources/shared/shells.html），然后重新构建（第 3 步）。
3. 按成本从低到高查看截图。 先查看 capture.mjs 的警告，再查看缩略图表（--sheet，多个屏幕约 1,000 个 tokens）；只有存在疑问时，才单独打开某个画面。分区截图（--sections）成本较高：仅用于文档版式。
4. 仅处理当前工作：使用 --ids 只截取已修改的屏幕，并根据下表阅读技能参考资料。
5. 合理委派，选择合适的模型（参见“在模型之间分配工作”）。给子 Agent 提供 CONTEXTE.md 的路径和任务，而非整个项目的摘要。两个并行工作的子 Agent 绝不能修改相同文件；启动子 Agent 前，先将修订后的清单（ID、标题、锚点）写入 CONTEXTE.md。
6. 仅发布已更改的内容。 整个项目是一个多页面 artifact：prepare-publish.mjs 会列出上次发布以来已修改的页面，并且只发布这些页面。发布前合并所有修订。

在模型之间分配工作

编写或修改屏幕 HTML、落实决策、提取文本：这些都属于执行工作，不需要使用能力最强的模型。如果环境支持为子 Agent 选择模型（Claude Code 中 Agent 工具的 model 参数），可按以下方式分配：

角色	模型	任务
设计与决策	会话的主模型	确定范围、提出方案（布局 + 主题）、盘点、屏幕规格表、依据 qualite-ui.md 的检查表审阅页面、对话与提问、CONTEXTE.md、发布
编写	sonnet	根据规格表编写一批屏幕文件；在源文件中落实反馈或决策；抽取公用组件；迁移项目
机械执行	haiku	运行 build.mjs 和 capture.mjs 并报告警告；修正被指出的徽标或链接；以纯文本提取待解决事项、日志或清单；批量重命名

为什么编写工作选 Sonnet：编写屏幕需要精心组织布局，并忠实遵循规格表、主线和质量检查表。Haiku 在完成度上较弱，因此需要来回修改，成本超过了价格差异。对于不需要任何布局判断的工作，Haiku 仍是合适的选择：运行脚本、提取内容、重命名，以及修正被指出的徽标或链接。

屏幕规格表：主模型交给编写者的内容，每个屏幕 10 至 20 行。内容包括各状态的 ID 和锚点、目标与主要用途、焦点、确切内容（主线事实）、要复用的组件和示例屏幕、要撰写的注释（规则、条件、引用）、「来源 / 后续」链接，以及移动端适用范围。规格表越精确，编写者所需的上下文就越少，交给它的工作也越轻。

编写者不做决策：如果规格表存在歧义或缺漏，应在工作报告中提问，而不是自行发挥。主模型始终会在发布前审阅页面；如果发现设计缺陷，会附上明确指示退回给编写者修改。

任务	阅读内容
接手、迭代、微调	CONTEXTE.md，然后阅读相关源文件；如有需要，阅读 redaction-specs.md §6
新建一批规格	CONTEXTE.md、tailwind.md §2 至 §6、qualite-ui.md §9、一个现有屏幕作为示例、shells.html
界面方案	propositions.md、qualite-ui.md
现有网站	site-existant.md
盘点、跨项目演进	redaction-specs.md §1 至 §4

生成的文件

这条链路中的三个技能都会将交付物放在项目根目录下同一个 specs/ 文件夹中。应用开发期间，这也是应用代码仓库中的文件夹：

specs/
├── ui/              ce skill : specs maquettées
├── prototype/       skill prototype-ui (facultatif)
└── requirements/    skill requirements-doc : cahier des charges (facultatif)

specs/ui/
├── CONTEXTE.md                 mémoire du projet (à jour à chaque étape)
├── tokens.css                  identité : bloc @theme Tailwind, injecté dans chaque document
├── propositions.html           propositions d'interface et décision (jamais supprimé ; copié dans le site)
├── captures/                   captures du site existant (étape 1B)
├── assets/                     (facultatif) images du produit : logos, illustrations, photos de démonstration
├── sources/
│   ├── site.json               titre, introduction, URL de l'artifact, liste ordonnée des lots, dossier des images
│   ├── shared/shells.html      coquilles <template id="tpl-shell-…"> communes à tous les lots
│   └── <lot>/                  lot.json, 000-header.html, NNN-<id>.html (un état d'écran par fichier), templates.html
└── site/                       construit par build.mjs, ne pas modifier à la main :
                                index.html (accueil), <lot>/index.html (en-tête, règles, écrans, points ouverts,
                                journal), <lot>/eN.html (une page par écran, tous ses états), propositions.html,
                                assets/ (les images citées par les pages)

产品图片。 界面中展示的徽标、吉祥物、插图或徽章，应在原型图中展示，而不是用色块代替：没有这些元素，屏幕就无法辨认。源文件通过 assets/<chemin> 引用图片；对于已有图片的项目（现有应用），sources/site.json → "assets" 指向图片所在文件夹（相对于 specs/ui/ 的路径，例如 "../../apps/web/public/assets"），而不是复制图片。build.mjs 只会将引用到的图片复制到 site/assets/，prepare-publish.mjs 会将它们与页面一起发布（tailwind.md §7）。

验证截图应放在临时文件夹中（如果会话中有 scratchpad，则放在那里），绝不能放在项目中。

在 git 仓库中，提交源文件和说明已发布内容的 site/.published.json，但不要提交构建生成的网站：构建结果是确定性的，只需几秒，团队会在已发布的 artifact 中查看规格。在项目的 .gitignore 中添加：specs/ui/site/*，然后添加 !specs/ui/site/.published.json。在全新克隆的仓库中，先运行 build.mjs，再运行 prepare-publish.mjs。只有当团队需要无需构建或打开 artifact 就能查看 HTML 时，才对网站进行版本控制。截图和发布文件夹应保留在仓库之外。

技能资源

文件	作用
references/tailwind.md	令牌、框架、可复用区块、注释、组件目录
references/qualite-ui.md	UI 质量原则和发布前审核清单
references/propositions.md	构建三个方案（布局 + 主题）
references/site-existant.md	为现有网站或应用添加功能
references/redaction-specs.md	清单、屏幕结构、状态、迭代、跨功能演进
templates/specs.html	规格文档框架：外观、脚本、两个示例屏幕
templates/propositions.html	对比页面：三种布局、三种主题，可实时组合
templates/tokens.css, templates/contexte.md	身份文件、项目记忆
scripts/build.mjs	从源文件构建网站：页面、页面间链接、令牌、拼写错误、外观、排版；列出已修改的页面
scripts/split.mjs	创建一批内容（--new <lot> --root specs/ui），或将现有文档拆分为源文件
scripts/capture.mjs	检查单个文件或整个网站；图像：--sheet、--frames、--thumbnails、--sections、--themes、--ids
scripts/check-contrast.mjs	检查令牌是否符合 WCAG AA
scripts/prepare-publish.mjs	准备发布网站（主页 + 已修改的页面）或单个文档；--check 可检查 artifact 是否落后于本地网站
scripts/migrate-layout.mjs	将采用旧布局（specs-ui/、prototype-ui/、cdc/ 并列）的项目整理到 specs/ 中
scripts/extract-identity.mjs	提取网站（URL）或代码（目录）的身份信息和截图
scripts/upgrade.mjs	将旧文档（无源文件）升级到模板的标准，不改动模型稿
scripts/typography.mjs	法语排版（由 build.mjs 自动应用）
scripts/export-design-system.mjs	（可选）准备 Claude Design Design System 目录：令牌、基础规范、组件、README
scripts/design-sync-package.mjs	（可选）创建通过 /design-sync 发送给 Claude Design 的“仅令牌”软件包
templates/design-system.html	导出到 Design System 的组件目录
templates/design-sync/	软件包模板：build.mjs、约定草稿、同步说明

模板中包含一个虚构产品（“Orbe”，客户请求），仅用于展示格式：请替换其中的所有内容。

在哪里提问。 问题绝不能只存在于对话中。如果有交互式提问工具（AskUserQuestion），封闭式选择应通过该工具提出，并提供推荐选项。所有待答事项也应记录在已发布文档中（方案中的“待确认”、规格中的“未决问题”）和 CONTEXTE.md 中。消息中应说明需要对方提供什么。

步骤 0 · 明确范围

1. 继续已有项目？ 如果存在 specs/ui/，请阅读 CONTEXTE.md，并从适当的步骤继续。采用旧版布局的项目（根目录下有 specs-ui/，版本为 2.x）应先使用 node <skill>/scripts/migrate-layout.mjs <projet> 整理（使用 --dry-run 查看效果），然后重新构建；产物保留原有 URL。没有 CONTEXTE.md 和 sources/ 的项目（由 1.x 版本创建，每批一个文档）应先迁移：
   • 按批次顺序，对每份规格文档运行 split.mjs；
   • 将旧文档移入 specs/ui/archives/；
   • 运行 build.mjs specs/ui，然后使用 capture.mjs specs/ui/site <tmp> 检查；
   • 从未解决事项和日志中提取文字来编写 CONTEXTE.md，而不是阅读页面；
   • 将网站发布为新的 artifact，并注明旧 artifacts 已被替代。
2. 身份信息的来源，根据对话判断：待定义 → 步骤 1A；现有网站或代码 → 步骤 1B；已提供（品牌规范、设计系统、tokens）→ 直接编写 tokens.css，然后进入步骤 2。如果用户有 Design System Claude Design 并希望以此为基础（非必需，只有在确实存在时才提出），请读取它（Artifact 工具：使用类型「Design System」调用 list，然后调用 read 读取 README 和 tokens），并将其转换为 tokens.css 和框架；这样就不需要执行步骤 1A。
3. 功能需求：目标、用户、规则、所提供的文档。如果 brief 依赖某个库或文档，应先阅读，再进行设计，然后转换为功能性术语（redaction-specs.md §1）。规格中绝不出现库的名称。

如果缺少信息，请在同一条消息中一次性询问所有问题。如果 brief 已足够清晰，则不必提问：记录假设并开始产出。若没有产品名称，请先选一个临时名称并注明。

步骤 1A · 三种方案：布局 + 主题

遵循 references/propositions.md。每种方案都由一种布局（导航、组织方式、工作方式）和一种主题（配色、字体、形状、密度）组成。三种方案在这两个方面都要有所不同，并使用同一个代表性页面、相同的真实内容，同时展示桌面端和移动端。从 templates/propositions.html 开始：每种布局都有自己的标记，按钮可以将任意主题应用到任意布局。

检查：运行 check-contrast.mjs，然后运行 capture.mjs --thumbnails（缩略图测试：三种布局必须一眼就能区分），对两到三种组合运行 --themes，并检查 qualite-ui.md 中的评估表。发布后，请用户选择：某个字母、一种组合或提出修改。在同一处等待确认时，展示步骤 2 的清单，并放在「待确认」部分。

收到反馈（例如「A 和 C 很像」）后，在同一个文件和同一个 artifact 中重新完成此步骤，并添加「自上一版本以来」的说明框。用户选定后：

• 在 tokens.css 中固定主题（注明来源和日期，并重新检查对比度），在 sources/shared/shells.html 中固定布局；
• 在 propositions.html 中添加「决策」说明框，并将「待确认」标记为已解决。绝不要删除 propositions.html。

对于组合式选择，在应用前先准确复述。如果仍有歧义且无法询问用户，则采用最合理的解释，将其记录为假设，并将其作为第一个问题提出。

步骤 1B · 沿用现有网站

遵循 references/site-existant.md：运行 extract-identity.mjs <url> --screenshots specs/ui/captures（或指定代码目录），结合截图核对报告，使用准确数值及其来源编写 tokens.css，然后在对应截图旁以 E0 · 现有 状态复现一个页面，并请用户确认还原是否准确。如果功能应放置的位置不确定，则提出两到三种集成布局。

步骤 2 · 屏幕清单

遵循 references/redaction-specs.md §1。在制作任何原型之前，先提交屏幕表格（ID、目标、状态）、用户流程、已理解的规则、假设，以及至多两个或三个问题。也要将其写入已发布的文档和 CONTEXTE.md，并为每个屏幕添加锚点。等待确认。范围较大的需求应拆分为批次（每批一个文档，编号全局递增）；从确定外壳的批次开始。除非对方接受缩小范围，否则每个屏幕都要制作移动端原型。

步骤 3 · 编写规格（按屏幕提供源文件）

创建批次：

node <skill>/scripts/split.mjs --new <lot> --root specs/ui     # → sources/<lot>/, inscrit dans sources/site.json

如果项目已经有外壳，批次应从空白骨架开始（标题、规则、未决事项、待填写的日志，以及沿用现有批次的身份附录）：从 CONTEXTE.md 中引用的示例屏幕开始。 然后，在 sources/<lot>/ 中：

• 填写 lot.json：label（「批次 2 · 项目与代码库」）、title、fonts、screens（每个屏幕的简短标题：{ "e4": "创建助手" }）；
• 填写标题部分（000-header.html）：背景、规则、流程；
• 每种屏幕状态创建一个文件（020-e4a.html、030-e4b.html……），替换示例屏幕。同一屏幕的 eN… 部分共同组成一个页面；其他部分（规则、未决事项、日志、附录）放在批次索引页上。

批次可以不包含任何屏幕：例如，仅由各部分组成的未决事项评审或待处理决策列表（表格中需留出「反馈」栏），并在 lot.json 中添加 "summary"，用于在首页显示该批次的卡片。

所有批次的外壳只在 shells.html 中修改一次；多个批次共用的组件（项目标题栏……）放在 sources/shared/components.html 中。图层背景和重复使用的内容放在 templates.html 中。链接直接书写即可（#e13b、sessions.html#e13b、propositions.html#retenu）：构建时会将它们改写到正确的页面。

每完成一轮修改后都要构建：

node <skill>/scripts/build.mjs specs/ui

build.mjs 会生成 specs/ui/site/：注入 tokens.css、每个页面所需的外壳、最新的模板样式和脚本，添加屏幕间导航，改写链接，并应用法语排版规则。构建后的页面无需再升级。它会报告无法解析的链接，并列出已修改的页面。

内容：遵循 tailwind.md（仅使用 token、组件目录、注释）和 qualite-ui.md（主要用途、焦点、层级）。每个屏幕都包含 ID、标题、徽章、说明、「上一页 / 下一步」、桌面端原型、重新设计的移动端原型，以及 3 至 6 条注释。先编写标题部分和第一个屏幕，构建并检查，然后再继续。

第 4 步 · 检查，然后发布

node <skill>/scripts/capture.mjs specs/ui/site <tmp>/captures                       # contrôles seuls, aucune image
node <skill>/scripts/capture.mjs specs/ui/site <tmp>/captures --sheet --ids e4,e5   # planches des écrans touchés

脚本会提示模板版本、未知图标、未组装的区块、被截断的内容，以及贴在文字上或被边缘裁切的徽章（并标出画板、编号和被遮挡的文字）。修复这些警告，按照 qualite-ui.md §9 中的检查表审阅各画板，仅在有疑问时单独打开一个画板（--frames --ids …），然后修复最明显的三个问题，并重新捕获受影响的屏幕。此循环优先于任何有关仅检查一次的一般指示。如果没有浏览器，请说明。

发布（如果有 Artifact 工具则使用；以本地文件为准）。整个项目是一个多页 artifact：

node <skill>/scripts/prepare-publish.mjs specs/ui/site <tmp>/publish    # page principale + pages à envoyer

• 将准备好的主页面（file_path）和脚本显示的 files 表传给 Artifact 工具：发布路径 → specs/ui/site/ 中的文件。次级页面是完整文档；页面间的相对链接可直接使用。
• 首次发布：发布所有页面（--all）。之后，只发布自上次发布以来修改过的页面；其他页面仍保持在线。找不到 artifact（已删除，或从另一个 claude.ai 账号发布）时，用新的替换：使用 --all 发布，然后在所有地方替换 URL（site.json、CONTEXTE.md、原型和规格说明的配置、项目 README），并注明旧链接已被替换。使用 url 时，工具可能要求先查看文件列表：请求文件列表（scope: "files"），不要重新读取页面。
• 发布成功后：运行 prepare-publish.mjs specs/ui/site --confirm。在 sources/site.json（artifact）和 CONTEXTE.md 中记下 URL。
• 遵守 Artifact 工具的发布规则；标题为两到四个词。

最后提供路径、链接、简短摘要和待定决策，并提醒如何提交反馈：点击每个页面上的“反馈”按钮，然后粘贴导出内容（参见第 5 步的“审阅反馈”）。更新 CONTEXTE.md。

第 5 步 · 迭代

遵循 redaction-specs.md §6。对于每条反馈：

• 仅修改相关源文件（及受其影响的文件），保持标识符稳定，然后重新构建；
• 增加迭代编号，添加一条日志记录，更新未解决事项；
• 检查、重新发布并更新 CONTEXTE.md。

根据变更类型：

• 视觉识别：通过 tokens.css 修改，然后重新构建；
• 错别字：在 shells.html 中修改，然后重新构建（这是维护，不是迭代）；
• 有争议的屏幕布局：并排制作 E5-A / E5-B 变体；
• 跨领域演进：进行影响分析，记录决策，在 CONTEXTE.md 和提案中修订清单，然后从承载该变更的批次开始制作。

审阅反馈

网站的每个页面都有一个**“反馈”按钮（属于文档界面，不会出现在截图和打印内容中）。审阅者进入“批注”模式，点击原型或文本中的某处（规则、注释、待决事项），并填写一条待修改内容或问题**。每条反馈都会标记在点击的位置（R1、R2……），仅保存在审阅者的浏览器中，随后导出为 Markdown 并粘贴到对话中：“复制导出内容”、“显示导出内容”（大型阅读窗口；当剪贴板操作被拒绝时，可复制并选择文本），以及在 artifact 之外提供的“下载”（在 artifact 中发布的页面无法触发下载）。导出内容按屏幕状态分组，并为每条反馈注明源文件（sources/<lot>/NNN-<id>.html，由 build.mjs 写入每个章节）、框架（e4c-desktop）、在框架中的位置以及目标文本。

处理导出内容：

1. 只阅读导出内容，然后只阅读其中引用的源文件。根据引用文本、框架以及位置（相对于框架宽度和高度的百分比）定位元素；绝不重新阅读构建后的页面。
2. 清晰且符合规则和决策的修改：在源文件中应用。若修改含糊不清、与规则、CONTEXTE.md 中的决策或其他屏幕相矛盾，则应使用提问工具和封闭式选项向审阅者确认，而不是自行猜测。
3. 问题：在对话中作答；若问题需要作出决策，则将其连同建议添加到该批次的待决事项中（并添加到 CONTEXTE.md）。
4. 每批反馈进行一次迭代：在该批次的日志中注明已处理的反馈（“R1、R3：……”），重新构建，截取受影响的屏幕（--ids），重新发布修改后的页面。
5. 使用表格回复：反馈 | 后续处理 | 屏幕（已修改、已提问、列为待决事项、未采纳及原因）。之后，审阅者可在面板中将反馈标记为“已处理”，或将其删除。

反馈保留在每位审阅者各自的浏览器中：多位审阅者分别导出自己的反馈（填写的姓名会作为署名）。对于已交付的屏幕（实现状态）的反馈，按照第 7 步的流程处理：同时修改代码，或将其列为差异。

选项 · Design System Claude Design

可选功能：由每个人决定是否使用。只提出一次，用封闭式问题询问（“要将视觉标识导出到 Claude Design 的 Design System 吗？”是 / 否 / 以后再说），在步骤 1A 作出决定后或步骤 6 时提出，并将回答记录在 CONTEXTE.md（“偏好”部分），以免重复询问。未经同意，绝不导出。

如果回答是“是”，分两个阶段。

1. 目录（specs/ui/design-system/）：

node <skill>/scripts/export-design-system.mjs specs/ui

其中包含 README（主题、token 词汇、使用规则）、tokens.css、基础元素（颜色、排版、形状）、目录中的组件以及项目组件（sources/shared/）。每个说明页都带有 Claude Design 卡片标记。

2. “仅 tokens”包（specs/design-system-package/，与 specs/ui/ 同级）。Claude Design 根据一个包构建 React 应用：由于规格中没有 React 组件，因此要以 tokens 和实用类的形式向其提供视觉标识。目录中的说明页会成为项目中可见的卡片。

node <skill>/scripts/design-sync-package.mjs specs/ui
cd design-system-package && npm install && npm run build

• 根据 CONTEXTE.md 补全 .design-sync/conventions.md，使用英文，长度为 2,000 到 4,000 个字符。这是设计 Agent 会读取的前言：必须逐一列出每个 token，并说明何时使用；描述常见模式（徽章、外壳、页眉），并提供一个真实示例。
• 然后，由使用者从此目录运行 /design-sync，如果收到提示，则通过 /design-login 授予访问权限。此技能本身不会发送任何内容。
• 重建步骤和已知陷阱见 .design-sync/NOTES.md。

视觉标识或共享组件更新后：重新导出，然后在包中运行 npm run build，再运行 /design-sync。

步骤 6 · 开始开发

确认没有未解决的问题会造成阻碍，启用实施状态（步骤 7），如果使用者尚未表态，则询问是否导出 Design System（见上方选项），询问是否要整理常用组件清单，并提醒可以将 tokens.css 原样粘贴到 @import "tailwindcss"; 之后。应要求时，将内容拆分为 stories，并将标注作为验收标准。

如果要在开发前测试或展示流程，prototype-ui 技能会将这些规格转化为可点击的原型（相同的屏幕、模拟数据、测试场景）。要启动开发，requirements-doc 技能会据此生成团队的需求文档（按批次划分的规格及验收标准、架构、技术栈、基础设施、批次和估算）。

第 7 步 · 在开发过程中维护

开发开始后，规格说明仍是唯一依据：它们逐屏描述应用的功能，并与实现保持同步。specs/ 目录位于应用仓库中。

实现状态。 在 sources/site.json 中启用（"implementation": true），然后在每个批次的 lot.json 中及时更新：

"status": { "e1": "done", "e2": "doing", "e3": { "status": "gap", "note": "Codex pas encore pris en charge" } }

• 可选值：todo（待开发，默认值）、doing（进行中）、done（已交付）、gap（不一致：应用与规格说明不符；备注说明具体差异）。
• 构建时，每种状态都会替换「新建」徽标，在导航中显示状态圆点，并在批次索引页和首页显示进度。提取时，需求文档会沿用这些状态。

开发过程中发现不一致时，应先作出判断，然后在与代码相同的变更中更新（同一分支、同一 PR）：

1. 代码正确（技术限制、经确认的更佳方案）：修改屏幕源文件，迭代次数加一，并在批次日志中注明「与实现对齐」及原因。保留标识符（屏幕、状态、规则编号）：代码和测试会引用这些标识符。
2. 规格说明正确：修正代码；在此之前，状态设为 gap 并添加备注。
3. 问题尚未确定：将其列为批次和 CONTEXTE.md 中的待解决问题，状态设为 gap。

然后按顺序执行：

• 重新构建规格说明；
• 如果原型连接了该屏幕，则同步更新原型（skill prototype-ui，「遵循规格说明」）；
• 重新提取需求文档，并调整受影响的验收标准（skill requirements-doc，「维护」）；
• 发布相关 artifacts（prepare-publish.mjs … --check 会指出哪些内容尚未更新）；
• 将源文件与 .published.json 一起提交（如果构建后的网站纳入版本控制，也一并提交）。

编号保持稳定。 功能规则沿用原编号：新规则追加到列表末尾，废弃的规则保留并标注「已移除」。已移除的屏幕或状态仍保留其标识符，不再分配给其他内容。需求文档中的 RF 标识符来自这些编号。

此 skill 不会做什么

• 它不会编写应用代码：原型图是静态的，规格说明仍是唯一依据。
• 它不会照搬第三方产品的品牌形象：外部网站仅用于参考结构，绝不作为视觉模板。