specs-ui

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Specs UI maquettées en Tailwind

Tailwind UI 规格原型

Ce skill produit un petit site de specs (une page par écran, publié comme un seul artifact multi-pages) qui sert de référence entre le métier et les développeurs : chaque écran y est maquetté en Tailwind (desktop et mobile), situé dans son parcours et annoté avec ses règles. On itère jusqu'à valider le fonctionnement et le rendu, puis les développements reprennent les mêmes tokens et les mêmes classes.

Documents, libellés, annotations et échanges sont en français. Le code (scripts, attributs, variables, identifiants techniques) est en anglais ; ses commentaires peuvent être en français.

Les specs sont fonctionnelles et UI : aucun nom de bibliothèque, de fonction, de champ d'API ni de notation technique dans les écrans, les annotations ou les règles (

redaction-specs.md

, « Specs fonctionnelles, sans code »).

<skill>

désigne le dossier de ce skill : les scripts se lancent avec

node <skill>/scripts/…

depuis le projet de la personne.

该 skill 会生成一个小型规格站点（每个屏幕一页，并以单个多页 artifact 发布），用于在业务方与开发人员之间充当参考：每个屏幕均以 Tailwind 制作原型（desktop 和 mobile），放入对应的用户流程中，并针对相关规则添加注释。持续迭代，直至功能和视觉呈现均通过确认；随后，开发工作会沿用相同的 tokens 和 classes。

文档、标签文案、注释和交流均使用法语。代码（scripts、attributes、variables、technical identifiers）使用英语；代码注释可以使用法语。

这些规格同时涵盖功能与 UI：屏幕、注释或规则中均不得出现任何 library、function、API field 或 technical notation 名称（

redaction-specs.md

，“不含代码的功能规格”）。

<skill>

指该 skill 所在的文件夹：scripts 从用户项目中通过

node <skill>/scripts/…

运行。

Économiser le contexte (à lire en premier)

节省上下文（首先阅读）

Un projet de specs grossit vite : un lot d'une dizaine d'écrans en une seule page dépasse 300 Ko. C'est pourquoi les specs sont découpées en pages par écran, et pourquoi il ne faut jamais relire ce qui n'est pas utile. Règles :

specs/ui/CONTEXTE.md
est la mémoire du projet. En reprise, le lire en premier et s'en contenter tant que possible. Il contient les décisions, l'identité, la disposition, les personas, les faits du fil rouge en chaînes exactes (identifiants, libellés, heures : à y ajouter dès qu'un écran en crée), l'inventaire avec les ancres, l'état des lots et leurs URL, les conventions propres au projet, les points ouverts et la prochaine étape. Le créer depuis
```
templates/contexte.md
```
dès l'étape 1, et le mettre à jour à la fin de chaque étape. Il doit rester sous 200 lignes.
Ne jamais lire les pages construites (
specs/ui/site/
). Les specs vivent dans
```
specs/ui/sources/
```
: un fichier par état d'écran. On lit et modifie seulement les fichiers utiles (
```
sources/<lot>/070-e15d.html
```
,
```
sources/shared/shells.html
```
), puis on reconstruit (étape 3).
Relire ses captures en commençant par le moins cher. Lire d'abord les alertes de
```
capture.mjs
```
, puis la planche réduite (
```
--sheet
```
, environ 1 000 tokens pour plusieurs écrans), et ouvrir un cadre seul seulement en cas de doute. Les captures de section (
```
--sections
```
) coûtent cher : à réserver aux mises en page de document.
Limiter au travail en cours :
```
--ids
```
pour ne capturer que les écrans modifiés, références du skill lues selon la table ci-dessous.
Déléguer sobrement, au bon modèle (voir « Répartir le travail entre modèles »). Un sous-agent reçoit le chemin de
```
CONTEXTE.md
```
et sa tâche, pas un résumé de tout le projet. Deux sous-agents en parallèle ne travaillent jamais sur les mêmes fichiers, et l'inventaire révisé (ID, titres, ancres) est écrit dans
```
CONTEXTE.md
```
avant de les lancer.
Publier seulement ce qui a changé. Tout le projet est un seul artifact multi-pages :
```
prepare-publish.mjs
```
liste les pages modifiées depuis la dernière publication, et seules celles-là sont envoyées. Regrouper les retouches avant de publier.

规格项目很快就会膨胀：一批约十个屏幕放在同一页面中就会超过 300 KB。因此，规格按每个屏幕一页拆分，并且绝不应重读无关内容。规则：

specs/ui/CONTEXTE.md
是项目记忆。续作时先读取它，并尽可能只依赖该文件。它包含决策、视觉身份、布局、personas、以精确字符串记录的贯穿性事实（标识符、标签、时间：屏幕产生这些信息时应立即添加）、带锚点的清单、批次状态及其 URL、项目专属约定、待确认事项和下一步操作。从
```
templates/contexte.md
```
创建它，并在每个步骤结束时更新。必须保持在 200 行以内。
绝不读取已构建的页面（
specs/ui/site/
）。规格实际保存在
```
specs/ui/sources/
```
中：每个屏幕状态对应一个文件。只读取和修改有用的文件（
```
sources/<lot>/070-e15d.html
```
、
```
sources/shared/shells.html
```
），然后重新构建（步骤 3）。
重看自己的截图时，从成本最低的方式开始。 先读取
```
capture.mjs
```
的 alerts，再查看缩略拼版（
```
--sheet
```
，多个屏幕约需 1 000 tokens），仅在有疑问时打开单个 frame。分区截图（
```
--sections
```
）成本较高，仅应用于文档布局。
将工作限定在当前范围： 使用
```
--ids
```
仅捕获已修改的屏幕，并按照下表读取 skill references。
适度委派给合适的模型（参见“如何在模型之间分配工作”）。Sub-agent 只接收
```
CONTEXTE.md
```
的路径及其任务，而不是整个项目的摘要。两个并行 sub-agent 绝不能处理相同文件；启动前，必须先将修订后的清单（ID、标题、锚点）写入
```
CONTEXTE.md
```
。
只发布发生变化的内容。 整个项目是一个多页 artifact：
```
prepare-publish.mjs
```
会列出自上次发布以来修改过的页面，并且只发送这些页面。发布前应集中整理所有调整。

Répartir le travail entre modèles

如何在模型之间分配工作

Écrire ou modifier du HTML d'écran, appliquer une décision, extraire du texte : c'est de l'exécution, qui ne demande pas le modèle le plus capable. Quand l'environnement permet de choisir le modèle d'un sous-agent (paramètre

model

de l'outil Agent dans Claude Code), répartir ainsi :

Rôle	Modèle	Tâches
Conception et décision	modèle principal de la session	Cadrage, propositions (disposition + thème), inventaire, fiches d'écran, relecture des planches avec la grille de `qualite-ui.md` , dialogue et questions, `CONTEXTE.md` , publication
Rédaction	`sonnet`	Écrire les fichiers d'écran d'un lot à partir des fiches ; appliquer des retours ou des décisions dans les sources ; mutualiser un composant ; migrer un projet
Exécution mécanique	`haiku`	Lancer `build.mjs` et `capture.mjs` et rapporter les alertes ; corriger une pastille ou un lien signalé ; extraire en texte brut les points ouverts, journaux ou inventaires ; renommer en série

Pourquoi Sonnet pour rédiger : écrire un écran demande de composer une mise en page soignée et de rester fidèle à la fiche, au fil rouge et à la grille de qualité. Haiku y perd en finition et oblige à des allers-retours qui coûtent plus que l'écart de prix. Haiku reste le bon choix pour ce qui ne demande aucun jugement de mise en page : lancer les scripts, extraire, renommer, corriger une pastille ou un lien signalé.

Fiche d'écran : ce que le modèle principal transmet au rédacteur, en 10 à 20 lignes par écran. Elle contient l'ID et les ancres de chaque état, l'objectif et l'usage dominant, le point focal, le contenu exact (faits du fil rouge), les composants et l'écran modèle à reprendre, les annotations à écrire (règle, condition, renvoi), les liens Depuis / Ensuite, et la portée mobile. Plus la fiche est précise, moins le rédacteur a besoin de contexte, et plus il peut être léger.

Le rédacteur ne décide pas : une ambiguïté ou un manque dans la fiche lui fait poser la question dans son compte rendu, pas improviser. Le modèle principal relit toujours les planches avant de publier ; un défaut de conception revient au rédacteur avec une consigne précise.

Tâche	À lire
Reprise, itération, retouche	`CONTEXTE.md` , puis les fichiers sources concernés ; `redaction-specs.md` §6 si besoin
Nouveau lot de specs	`CONTEXTE.md` , `tailwind.md` §2 à §6, `qualite-ui.md` §9, un écran existant comme modèle, `shells.html`
Propositions d'interface	`propositions.md` , `qualite-ui.md`
Site existant	`site-existant.md`
Inventaire, évolution transverse	`redaction-specs.md` §1 à §4

编写或修改屏幕 HTML、应用决策、提取文本属于执行工作，不需要使用能力最强的模型。当环境允许为 sub-agent 选择模型时（Claude Code 中 Agent 工具的

model

参数），应按以下方式分配：

角色	模型	任务
构思与决策	当前会话的主模型	范围界定、方案（布局 + 主题）、清单、屏幕卡片、使用 `qualite-ui.md` 检查表复核拼版、对话与问题、 `CONTEXTE.md` 、发布
编写	`sonnet`	根据卡片编写一个批次的屏幕文件；在 sources 中应用反馈或决策；抽取共用组件；迁移项目
机械执行	`haiku`	运行 `build.mjs` 和 `capture.mjs` 并报告 alerts；修复被指出的标记或链接；以纯文本提取待确认事项、日志或清单；批量重命名

为什么使用 Sonnet 编写： 编写一个屏幕需要构思精致的布局，并忠实遵循卡片、贯穿性事实和质量检查表。Haiku 在精细度上有所损失，还会引发成本高于价格差异的往返沟通。对于不需要判断布局的任务，Haiku 仍是正确选择：运行 scripts、提取内容、重命名，以及修复被指出的标记或链接。

屏幕卡片： 主模型传递给编写者的信息，每个屏幕 10 至 20 行。它包含每个状态的 ID 和锚点、目标与主要用途、视觉焦点、确切内容（贯穿性事实）、组件及要沿用的参考屏幕、要编写的注释（规则、条件、引用）、“Depuis / Ensuite”链接以及 mobile 范围。卡片越精确，编写者需要的上下文越少，工作也就能越轻量。

编写者不负责决策：如果卡片中存在歧义或缺失内容，编写者应在报告中提出问题，而不是即兴发挥。主模型在发布前始终会重新查看拼版；设计缺陷会以明确指令退回给编写者修正。

任务	需要读取的内容
续作、迭代、调整	`CONTEXTE.md` ，然后是相关的 source files；如需要，再读取 `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

Fichiers produits

产出文件

Les trois skills de la chaîne rangent leurs livrables dans un seul dossier

specs/

à la racine du projet. C'est aussi le dossier qui vit dans le dépôt de code de l'application pendant les développements :

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)

Images du produit. Un logo, une mascotte, une illustration ou un insigne que l'interface affiche se montre dans la maquette, pas une forme de couleur qui le remplace : sans lui, l'écran ne se reconnaît pas. Les sources citent l'image par

assets/<chemin>

; dans un projet qui a déjà ses images (application existante),

sources/site.json

→

"assets"

désigne leur dossier (chemin relatif à

specs/ui/

, par exemple

"../../apps/web/public/assets"

) plutôt que de les copier.

build.mjs

copie dans

site/assets/

les seules images citées, et

prepare-publish.mjs

les publie avec les pages (

tailwind.md

§7).

Les captures de vérification vont dans un dossier temporaire (le scratchpad de la session s'il existe), jamais dans le projet.

Dans un dépôt git, on commite les sources et

site/.published.json

, qui dit ce qui est publié, mais pas le site construit : le build est déterministe et prend quelques secondes, et l'équipe lit les specs dans l'artifact publié. Dans le

.gitignore

du projet :

specs/ui/site/*

, puis

!specs/ui/site/.published.json

. Sur un clone neuf, lancer

build.mjs

avant

prepare-publish.mjs

. Ne versionner le site que si l'équipe doit lire le HTML sans rien construire ni ouvrir l'artifact. Les captures et les dossiers de publication restent hors du dépôt.

工作流中的三个 skills 会将各自的交付物放在项目根目录的同一个

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)

产品图片。 界面中展示的 logo、mascot、illustration 或 badge 应在原型中显示真实图片，而不是用色块替代：否则用户无法认出该屏幕。Sources 通过

assets/<chemin>

引用图片；对于已有图片的现有应用项目，

sources/site.json

→

"assets"

指定其文件夹（相对于

specs/ui/

的路径，例如

"../../apps/web/public/assets"

），无需复制这些图片。

build.mjs

仅将页面引用的图片复制到

site/assets/

，

prepare-publish.mjs

则在发布页面时一并发布这些图片（

tailwind.md

§7）。

验证截图应放在临时文件夹中（如果会话存在 scratchpad，就使用它），绝不能放入项目。

在 git 仓库中，应提交 sources 和

site/.published.json

；后者记录已发布的内容，但不要提交构建后的站点。构建过程是确定性的，只需数秒，团队会通过已发布的 artifact 阅读规格。在项目的

.gitignore

中加入

specs/ui/site/*

，然后加入

!specs/ui/site/.published.json

。在全新 clone 上，应先运行

build.mjs

，再运行

prepare-publish.mjs

。只有在团队必须直接阅读 HTML、既不构建也不打开 artifact 时，才应将站点纳入版本管理。截图和发布目录应保留在仓库之外。

Ressources du skill

Skill 资源

Fichier	Rôle
`references/tailwind.md`	Tokens, cadres, blocs réutilisables, annotations, catalogue de composants
`references/qualite-ui.md`	Principes de qualité UI et grille de revue avant publication
`references/propositions.md`	Construire trois propositions (disposition + thème)
`references/site-existant.md`	Fonctionnalité ajoutée à un site ou une application existante
`references/redaction-specs.md`	Inventaire, anatomie d'un écran, états, itérations, évolutions transverses
`templates/specs.html`	Squelette d'un document de specs : habillage, script, deux écrans d'exemple
`templates/propositions.html`	Page de comparaison : trois dispositions, trois thèmes, combinables en direct
`templates/tokens.css` , `templates/contexte.md`	Fichier d'identité, mémoire du projet
`scripts/build.mjs`	Construit le site depuis les sources : pages, liens entre pages, tokens, coquilles, habillage, typographie ; liste les pages modifiées
`scripts/split.mjs`	Crée un lot ( `--new <lot> --root specs/ui` ) ou découpe un document existant en sources
`scripts/capture.mjs`	Contrôles d'un fichier ou de tout le site ; images : `--sheet` , `--frames` , `--thumbnails` , `--sections` , `--themes` , `--ids`
`scripts/check-contrast.mjs`	Contrôle WCAG AA des tokens
`scripts/prepare-publish.mjs`	Prépare la publication du site (page principale + pages modifiées) ou d'un document isolé ; `--check` dit si l'artifact est en retard sur le site local
`scripts/migrate-layout.mjs`	Range un projet à l'ancienne disposition ( `specs-ui/` , `prototype-ui/` , `cdc/` côte à côte) dans `specs/`
`scripts/extract-identity.mjs`	Identité d'un site (URL) ou d'un code (dossier), captures
`scripts/upgrade.mjs`	Met un document ancien (sans sources) au niveau des templates, sans toucher aux maquettes
`scripts/typography.mjs`	Typographie française (appliquée automatiquement par `build.mjs` )
`scripts/export-design-system.mjs`	(Facultatif) Prépare un dossier Design System Claude Design : tokens, fondations, composants, README
`scripts/design-sync-package.mjs`	(Facultatif) Crée le paquet « tokens seuls » envoyé à Claude Design par `/design-sync`
`templates/design-system.html`	Catalogue de composants exporté vers le Design System
`templates/design-sync/`	Modèles du paquet : `build.mjs` , brouillon de conventions, notes de synchronisation

Les templates contiennent un produit fictif (« Orbe », demandes clients) qui ne sert qu'à montrer le format : en remplacer tout le contenu.

Où poser les questions. Une question ne doit jamais exister seulement dans la conversation. Les choix fermés passent par l'outil de questions interactives s'il existe (AskUserQuestion), avec une option recommandée. Tout ce qui attend une réponse est aussi reporté dans le document publié (« À valider » des propositions, « Points ouverts » des specs) et dans

CONTEXTE.md

. Le message annonce ce qui est attendu.

文件	作用
`references/tailwind.md`	Tokens、frames、可复用 blocks、annotations、组件目录
`references/qualite-ui.md`	UI 质量原则及发布前的检查表
`references/propositions.md`	构建三个方案（布局 + 主题）
`references/site-existant.md`	为现有网站或应用添加功能
`references/redaction-specs.md`	清单、屏幕结构、状态、迭代、横向演进
`templates/specs.html`	规格文档骨架：页面样式、script、两个示例屏幕
`templates/propositions.html`	对比页面：三种布局、三种主题，可实时组合
`templates/tokens.css` 、 `templates/contexte.md`	视觉身份文件、项目记忆
`scripts/build.mjs`	从 sources 构建站点：页面、页面间链接、tokens、shells、页面样式、排版；列出已修改的页面
`scripts/split.mjs`	创建批次（ `--new <lot> --root specs/ui` ），或将现有文档拆分为 sources
`scripts/capture.mjs`	检查单个文件或整个站点；图片： `--sheet` 、 `--frames` 、 `--thumbnails` 、 `--sections` 、 `--themes` 、 `--ids`
`scripts/check-contrast.mjs`	检查 tokens 的 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`	将旧文档（没有 sources）升级到当前 templates 级别，不修改原型
`scripts/typography.mjs`	法语排版（由 `build.mjs` 自动应用）
`scripts/export-design-system.mjs`	（可选）准备 Claude Design System 文件夹：tokens、foundations、components、README
`scripts/design-sync-package.mjs`	（可选）创建仅含 tokens 的包，通过 `/design-sync` 发送给 Claude Design
`templates/design-system.html`	导出到 Design System 的组件目录
`templates/design-sync/`	Design Sync 包的 templates：build.mjs、draft conventions、sync notes

Templates 中包含一个虚构产品（“Orbe”、客户请求），仅用于展示格式：必须替换其中的全部内容。

问题应放在哪里。 问题绝不能只存在于对话中。对于封闭式选择，应优先使用交互式问题工具（如果存在则使用 AskUserQuestion），并提供一个推荐选项。所有需要答复的内容，也必须记录在已发布文档中（方案中的“À valider”、规格中的“Points ouverts”）以及

CONTEXTE.md

中。消息应说明当前等待用户提供的内容。

Étape 0 · Cadrer

步骤 0 · 确定范围

Reprise ? Si
```
specs/ui/
```
existe, lire
```
CONTEXTE.md
```
et reprendre à l'étape utile. Un projet à l'ancienne disposition (
```
specs-ui/
```
à la racine, versions 2.x) se range d'abord avec
```
node <skill>/scripts/migrate-layout.mjs <projet>
```
(
```
--dry-run
```
pour voir), puis se reconstruit ; les artifacts gardent leur URL. Un projet sans
```
CONTEXTE.md
```
ni
```
sources/
```
(créé par une version 1.x, un document par lot) se migre d'abord :
- ```
split.mjs
```
  sur chaque document de specs, dans l'ordre des lots ;
- ranger les anciens documents dans
```
specs/ui/archives/
```
  ;
- ```
build.mjs specs/ui
```
  , puis contrôle avec
```
capture.mjs specs/ui/site <tmp>
```
  ;
- rédiger
```
CONTEXTE.md
```
  en extrayant le texte des points ouverts et des journaux, plutôt qu'en lisant les pages ;
- publier le site comme un nouvel artifact, et noter les anciens artifacts comme remplacés.
Origine de l'identité, déduite de la conversation : à définir → étape 1A ; site ou code existant → étape 1B ; fournie (charte, design system, tokens) →
```
tokens.css
```
directement, puis étape 2. Si la personne dispose d'un Design System Claude Design et souhaite partir de celui-ci (c'est facultatif, le proposer seulement s'il existe), le lire (outil Artifact :
```
list
```
avec le type « Design System », puis
```
read
```
du README et des tokens) et le traduire en
```
tokens.css
```
et en coquilles : l'étape 1A devient inutile.
Besoin fonctionnel : objectif, utilisateurs, règles, documents fournis. Un brief qui s'appuie sur une bibliothèque ou une documentation se lit avant de concevoir, puis se traduit en vocabulaire fonctionnel (
```
redaction-specs.md
```
§1). La bibliothèque n'apparaît jamais dans les specs.

S'il manque des informations, les demander toutes dans un seul message. Si le brief suffit, ne rien demander : écrire les hypothèses et produire. Sans nom de produit, en choisir un provisoire et le signaler.

续作？ 如果存在
```
specs/ui/
```
，先读取
```
CONTEXTE.md
```
，然后从合适的步骤继续。位于项目根目录、采用旧目录结构（2.x 版本的
```
specs-ui/
```
）的项目，应先通过
```
node <skill>/scripts/migrate-layout.mjs <projet>
```
重新整理（使用
```
--dry-run
```
可先预览），然后重新构建；artifacts 会保留原有 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 已被替代。
视觉身份来源，根据对话推断：待定义 → 步骤 1A；现有网站或代码 → 步骤 1B；已提供（charte、design system、tokens）→ 直接使用
```
tokens.css
```
，然后进入步骤 2。如果用户拥有 Claude Design System 并希望以此为基础（这是可选项，仅在确实存在时提出），则读取它（Artifact 工具：使用类型“Design System”调用
```
list
```
，再读取 README 和 tokens），并将其转换为
```
tokens.css
```
和 shells；此时无需执行步骤 1A。
功能需求： 目标、用户、规则、已提供的文档。如果 brief 依赖某个 library 或 documentation，应先阅读，再将其转化为功能词汇（
```
redaction-specs.md
```
§1）。Library 的名称绝不能出现在规格中。

如果缺少信息，应在同一条消息中一次性询问全部问题。如果 brief 已足够，不要提问：写明假设并开始产出。如果没有产品名称，则选择一个临时名称并明确说明。

Étape 1A · Trois propositions : disposition + thème

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

Suivre

references/propositions.md

. Une proposition associe une disposition (navigation, organisation, manière de travailler) et un thème (palette, typographie, formes, densité). Les trois propositions diffèrent sur les deux plans, sur le même écran représentatif, avec le même contenu réel, desktop et mobile. Partir de

templates/propositions.html

: chaque disposition a son balisage, et des boutons appliquent n'importe quel thème à n'importe quelle disposition.

Vérifier :

check-contrast.mjs

, puis

capture.mjs --thumbnails

(test de la vignette : les trois dispositions se distinguent au premier coup d'œil),

--themes

sur deux ou trois combinaisons, et la grille de

qualite-ui.md

. Publier, puis demander un choix : une lettre, une combinaison ou des retouches. Présenter au même point d'arrêt l'inventaire de l'étape 2 dans la section « À valider ».

Après un retour (« A et C se ressemblent »), refaire l'étape dans le même fichier et le même artifact, avec un encadré « Depuis la version précédente ». Une fois le choix fait :

figer le thème dans
```
tokens.css
```
(source, date, contrastes revérifiés) et la disposition dans
```
sources/shared/shells.html
```
;
ajouter à
```
propositions.html
```
un encadré « Décision » et marquer « À valider » comme tranché. Ne jamais supprimer
propositions.html
.

Un choix composite se reformule précisément avant d'être appliqué. S'il reste ambigu sans moyen de demander, retenir l'interprétation la plus plausible, l'écrire comme hypothèse et la poser en première question.

遵循

references/propositions.md

。每个方案都结合一种布局（导航、组织方式、工作方式）和一种主题（palette、typography、shapes、density）。三个方案应在这两个维度上均有差异，并基于同一个代表性屏幕、相同的真实内容以及 desktop 和 mobile 形式进行设计。以

templates/propositions.html

为起点：每种布局都有自己的 markup，按钮可以将任意主题应用到任意布局。

验证方式：先运行

check-contrast.mjs

，再运行

capture.mjs --thumbnails

（缩略图测试：三种布局应能让人第一眼区分），对两到三种组合运行

--themes

，并使用

qualite-ui.md

的检查表。发布后，询问用户选择：一个字母、一种组合或需要调整的内容。在同一个确认节点，还应在“À valider”部分展示步骤 2 的清单。

收到反馈（例如“A 和 C 看起来相似”）后，在同一个文件和同一个 artifact 中重新制作该步骤，并加入“自从上一版本以来”的说明框。完成选择后：

在
```
tokens.css
```
中固定主题（来源、日期、重新检查过的对比度），并在
```
sources/shared/shells.html
```
中固定布局；
在
```
propositions.html
```
中添加“Décision”说明框，并将“À valider”标记为已决定。绝不删除
propositions.html
。

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

Étape 1B · Reprendre un site existant

步骤 1B · 沿用现有网站

Suivre

references/site-existant.md

extract-identity.mjs <url> --screenshots specs/ui/captures

(ou un dossier de code), croiser le rapport avec les captures, écrire

tokens.css

avec les valeurs exactes et leur origine, puis reproduire une page en E0 · Existant à côté de sa capture et faire valider la fidélité. Si l'emplacement de la fonctionnalité est incertain, proposer deux ou trois dispositions d'intégration.

遵循

references/site-existant.md

：运行

extract-identity.mjs <url> --screenshots specs/ui/captures

（或传入代码文件夹），将报告与截图交叉核对，使用精确值及其来源编写

tokens.css

，然后在截图旁复现一个 E0 · Existant 页面，并确认还原度。如果功能应放置的位置尚不明确，则提出两到三种集成布局。

Étape 2 · Inventaire des écrans

步骤 2 · 屏幕清单

Suivre

references/redaction-specs.md

§1. Avant toute maquette, présenter le tableau des écrans (ID, objectif, états), les parcours, les règles comprises, les hypothèses et deux ou trois questions au plus. L'écrire aussi dans le document publié et dans

CONTEXTE.md

, avec l'ancre de chaque écran. Attendre la validation. Un brief large se découpe en lots (un document par lot, numérotation globale) ; commencer par celui qui fixe la coquille. Le mobile est maquetté pour chaque écran, sauf portée réduite acceptée par la personne.

遵循

redaction-specs.md

§1。在制作任何原型之前，展示屏幕表格（ID、目标、状态）、用户流程、已理解的规则、假设，以及最多两到三个问题。还应将这些内容连同每个屏幕的锚点写入已发布文档和

CONTEXTE.md

。然后等待确认。如果 brief 范围较大，应拆分为多个批次（每批一个文档，使用全局编号）；先从确定 shell 的批次开始。除非用户接受缩小范围，否则每个屏幕都要制作 mobile 版本。

Étape 3 · Écrire les specs (sources par écran)

步骤 3 · 编写规格（按屏幕拆分 sources）

Créer un lot :

bash

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

Dans un projet qui a déjà ses coquilles, le lot démarre d'un squelette vide (en-tête, règles, points ouverts, journal à remplir, annexe d'identité reprise d'un lot existant) : partir des écrans modèles cités dans

CONTEXTE.md

. Puis, dans

sources/<lot>/

renseigner
```
lot.json
```
:
```
label
```
(« Lot 2 · Projets et dépôts »),
```
title
```
,
```
fonts
```
,
```
screens
```
(titre court de chaque écran :
```
{ "e4": "Assistant de création" }
```
) ;
renseigner l'en-tête (
```
000-header.html
```
) : contexte, règles, parcours ;
écrire un fichier par état d'écran (
```
020-e4a.html
```
,
```
030-e4b.html
```
…) en remplaçant les écrans d'exemple. Les sections
```
eN…
```
d'un même écran forment une page ; les autres sections (règles, points ouverts, journal, annexe) vont sur l'index du lot.

Un lot peut n'avoir aucun écran : une revue des points ouverts ou une liste de décisions à prendre, faite seulement de sections (tableaux à annoter avec « Retours »), avec

"summary"

dans

lot.json

pour sa carte sur l'accueil.

Les coquilles se modifient une seule fois dans

shells.html

, pour tous les lots ; les composants communs à plusieurs lots (en-tête de projet…) vont dans

sources/shared/components.html

. Les fonds de calque et contenus réutilisés vont dans

templates.html

. Les liens s'écrivent simplement (

#e13b

sessions.html#e13b

propositions.html#retenu

) : le build les réécrit vers la bonne page.

Construire après chaque série de modifications :

bash

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

build.mjs

produit

specs/ui/site/

: il injecte

tokens.css

, les coquilles utiles à chaque page, l'habillage et le script du template à jour, ajoute la navigation entre écrans, réécrit les liens et applique la typographie française. Les pages construites n'ont jamais besoin de mise à niveau. Il signale les liens non résolus et liste les pages modifiées.

Contenu : suivre

tailwind.md

(tokens uniquement, catalogue de composants, annotations) et

qualite-ui.md

(usage dominant, point focal, hiérarchie). Chaque écran comporte un ID, un titre, un badge, une note, « Depuis / Ensuite », une maquette desktop, une maquette mobile repensée et 3 à 6 annotations. Écrire l'en-tête et le premier écran, construire, vérifier, puis la suite.

创建批次：

bash

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

在已经有 shells 的项目中，新批次从一个空骨架开始（待填写 header、rules、open points、journal，以及从现有批次复用的 identity appendix）：从

CONTEXTE.md

中列出的参考屏幕开始。

然后在

sources/<lot>/

中：

填写
```
lot.json
```
：
```
label
```
（“Lot 2 · Projets et dépôts”）、
```
title
```
、
```
fonts
```
、
```
screens
```
（每个屏幕的简短标题：
```
{ "e4": "Assistant de création" }
```
）；
填写 header（
```
000-header.html
```
）：context、rules、paths；
编写每个屏幕状态一个文件（
```
020-e4a.html
```
、
```
030-e4b.html
```
……），替换示例屏幕。同一屏幕的
```
eN…
```
sections 组成一个页面；其他 sections（rules、open points、journal、appendix）放在批次索引页上。

某个批次可以完全没有屏幕：例如，只包含 sections（带有“Retours”列、供批注的表格）的待确认事项或待决定事项评审，并在

lot.json

中填写

"summary"

，用于首页中的批次卡片。

Shells 只在

shells.html

中修改一次，并应用于所有批次；多个批次共用的组件（例如项目 header）放入

sources/shared/components.html

。可复用的 overlay 背景和内容放入

templates.html

。链接只需简单编写（

#e13b

、

sessions.html#e13b

、

propositions.html#retenu

）：build 会将它们重写到正确页面。

每完成一系列修改后进行构建：

bash

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

build.mjs

会生成

specs/ui/site/

：注入

tokens.css

、各页面适用的 shells、最新 template 的页面样式和 script、添加屏幕间导航、重写链接并应用法语排版。构建后的页面永远不需要升级。它会报告未解析的链接，并列出已修改的页面。

内容：遵循

tailwind.md

（仅使用 tokens、组件目录、annotations）和

qualite-ui.md

（主要用途、视觉焦点、层级）。每个屏幕包含 ID、标题、badge、note、“Depuis / Ensuite”、desktop 原型、重新设计的 mobile 原型以及 3 到 6 条 annotations。先编写 header 和第一个屏幕，然后构建、检查，再继续其余部分。

Étape 4 · Vérifier, puis publier

步骤 4 · 检查，然后发布

bash

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

Le script signale la version du template, les icônes inconnues, les blocs non assemblés, le contenu coupé et les pastilles posées sur du texte ou coupées par un bord (avec le cadre, le numéro et le texte recouvert). Corriger ces alertes, relire les planches avec la grille de

qualite-ui.md

§9, ouvrir un cadre seul (

--frames --ids …

) seulement en cas de doute, puis corriger les trois défauts les plus visibles et recapturer les écrans touchés. Cette boucle prime sur toute consigne générale de vérification unique. Sans navigateur, le dire.

Publier (outil Artifact s'il existe ; les fichiers locaux font foi). Tout le projet est un seul artifact multi-pages :

bash

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

Passer à l'outil Artifact la page principale préparée (
```
file_path
```
) et la table
```
files
```
affichée par le script : chemin publié → fichier de
```
specs/ui/site/
```
. Les pages secondaires sont des documents complets ; les liens relatifs entre pages fonctionnent tels quels.
Première publication : toutes les pages (
```
--all
```
). Ensuite, seules les pages modifiées depuis la dernière publication ; les autres restent en ligne. Un artifact introuvable (supprimé, ou publié depuis un autre compte claude.ai) se remplace par un nouveau : publier avec
```
--all
```
, puis remplacer l'URL partout (
```
site.json
```
,
```
CONTEXTE.md
```
, configurations du prototype et du cahier des charges, README du projet) en notant l'ancienne comme remplacée. Avec
```
url
```
, l'outil peut exiger d'avoir vu la liste des fichiers : demander la liste (
```
scope: "files"
```
) plutôt que de relire les pages.

Après une publication réussie :

prepare-publish.mjs specs/ui/site --confirm

. Noter l'URL dans

sources/site.json

(

artifact

) et dans

CONTEXTE.md

Respecter les règles de l'outil Artifact pour la publication ; titre de deux à quatre mots.

Terminer par le chemin, le lien, un résumé court et les décisions attendues, et rappeler comment faire des retours : bouton « Retours » sur chaque page, puis coller l'export (voir « Retours de relecture » à l'étape 5). Mettre

CONTEXTE.md

à jour.

bash

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

Script 会报告 template 版本、未知 icons、未组装的 blocks、被截断的内容，以及落在文本上或被边缘裁切的标记（包括 frame、编号和被遮挡的文本）。修正这些 alerts，使用

qualite-ui.md

§9 的检查表重新查看拼版，仅在有疑问时打开单个 frame（

--frames --ids …

），然后修复最明显的三个缺陷，并重新捕获已修改的屏幕。这个循环的优先级高于任何通用的单次验证要求。如果没有浏览器，应明确说明。

发布（如果存在则使用 Artifact 工具；本地文件是事实依据）。整个项目是一个多页 artifact：

bash

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

向 Artifact 工具传入已准备好的主页（
```
file_path
```
），以及 script 显示的
```
files
```
表：published path →
```
specs/ui/site/
```
中的 file。Secondary pages 是完整文档；页面之间的相对链接可正常工作。
首次发布：使用
```
--all
```
发布所有页面。此后，只发布自上次发布以来修改过的页面；其他页面保持在线。如果找不到某个 artifact（已删除，或从另一个 claude.ai 账户发布），则创建新的 artifact：使用
```
--all
```
发布，然后替换所有位置中的 URL（
```
site.json
```
、
```
CONTEXTE.md
```
、prototype 和 cahier des charges 的配置、项目 README），并注明旧 artifact 已被替代。使用
```
url
```
时，工具可能要求先查看文件列表：应请求列表（
```
scope: "files"
```
），而不是重新读取页面。

发布成功后：运行

prepare-publish.mjs specs/ui/site --confirm

。在

sources/site.json

（

artifact

）和

CONTEXTE.md

中记录 URL。

遵循 Artifact 工具的发布规则；标题为两到四个词。

最后提供路径、链接、简短摘要和待决定事项，并说明如何提供反馈：点击每个页面上的“Retours”按钮，然后粘贴导出内容（参见步骤 5 的“评审反馈”）。更新

CONTEXTE.md

。

Étape 5 · Itérer

步骤 5 · 迭代

Suivre

redaction-specs.md

§6. Pour chaque retour :

modifier seulement les sources concernées (et celles qu'elles impactent) en gardant les identifiants stables, puis reconstruire ;
incrémenter l'itération, ajouter une entrée au journal, mettre à jour les points ouverts ;
vérifier, republier, mettre à jour
```
CONTEXTE.md
```
.

Selon le type de changement :

identité : passe par
```
tokens.css
```
, puis reconstruire ;
coquille : se fait dans
```
shells.html
```
, puis reconstruire (c'est une maintenance, pas une itération) ;
disposition d'un écran qui fait débat : maquetter des variantes
```
E5-A
```
/
```
E5-B
```
côte à côte ;
évolution transverse : analyse d'impact, décisions, inventaire révisé dans
```
CONTEXTE.md
```
et les propositions, puis production en commençant par le lot qui la porte.

遵循

redaction-specs.md

§6。对于每条反馈：

只修改相关 sources（以及受其影响的 sources），并保持 identifiers 稳定，然后重新构建；
增加迭代次数，添加一条 journal entry，并更新 open points；
检查、重新发布，并更新
```
CONTEXTE.md
```
。

根据变更类型：

视觉身份： 通过
```
tokens.css
```
修改，然后重新构建；
shell： 在
```
shells.html
```
中修改，然后重新构建；这属于维护，不算一次迭代；
某个屏幕的布局存在争议： 并排制作
```
E5-A
```
/
```
E5-B
```
变体；
横向演进： 进行 impact analysis、作出决策、修订
```
CONTEXTE.md
```
和 propositions 中的清单，然后从承载该变更的批次开始产出。

Retours de relecture

评审反馈

Chaque page du site porte un bouton « Retours » (habillage du document, absent des captures et de l'impression). La personne qui relit passe en mode « Annoter », clique sur l'endroit d'une maquette ou d'un texte (règle, annotation, point ouvert) et écrit une correction à faire ou une question. Chaque retour est repéré à l'endroit cliqué (R1, R2…), gardé dans son navigateur seulement, puis exporté en Markdown et collé dans la conversation : « Copier l'export », « Afficher l'export » (grande fenêtre de lecture, avec copie et sélection du texte quand le presse-papiers est refusé) et, hors artifact, « Télécharger » (une page publiée dans un artifact ne peut pas déclencher de téléchargement). L'export regroupe les retours par état d'écran et cite pour chacun le fichier source (

sources/<lot>/NNN-<id>.html

, inscrit par

build.mjs

dans chaque section), le cadre (

e4c-desktop

), la position dans le cadre et le texte visé.

Pour traiter un export :

Ne lire que l'export, puis les seuls fichiers sources qu'il cite. Repérer l'élément par le texte cité, le cadre et la position (en % de la largeur et de la hauteur du cadre) ; jamais de relecture des pages construites.
Correction claire et compatible avec les règles et décisions : l'appliquer dans la source. Correction ambiguë, qui contredit une règle, une décision de
```
CONTEXTE.md
```
ou un autre écran : la poser à la personne (outil de questions, choix fermés) plutôt que d'improviser.
Question : y répondre dans la conversation ; si elle appelle une décision, l'ajouter aux points ouverts du lot (et à
```
CONTEXTE.md
```
) avec une recommandation.
Une itération par série de retours : journal du lot qui cite les retours traités (« R1, R3 : … »), reconstruire, capturer les écrans touchés (
```
--ids
```
), republier les pages modifiées.
Répondre par un tableau
```
Retour | Suite donnée | Écran
```
(corrigé, question posée, point ouvert, non retenu et pourquoi). La personne marque ensuite les retours « traités » dans le panneau, ou les efface.

Les retours restent dans le navigateur de chaque personne : plusieurs relecteurs exportent chacun les leurs (le nom saisi les signe). Un retour sur un écran déjà livré (statut d'implémentation) suit la boucle de l'étape 7 : il change aussi le code, ou devient un écart.

站点中的每个页面都有一个 “Retours” 按钮（属于 document 样式，不会出现在截图和打印中）。评审者进入“Annoter”模式，点击原型或文本（rule、annotation、open point）上的具体位置，并填写一项待执行修正或一个问题。每条反馈都会在点击位置进行标记（R1、R2……），仅保存在其浏览器中，然后导出为 Markdown 并粘贴到对话中：“Copier l'export”、“Afficher l'export”（大尺寸阅读窗口，支持复制；如果浏览器拒绝剪贴板访问，则可选择文本），以及在 artifact 之外使用“Télécharger”（已发布到 artifact 的页面无法触发下载）。导出内容按屏幕状态分组，并为每条反馈注明 source file（

sources/<lot>/NNN-<id>.html

，由

build.mjs

写入每个 section）、frame（如

e4c-desktop

）、frame 内的位置和目标文本。

处理导出内容时：

只读取导出内容，然后只读取其中引用的 source files。根据引用的文本、frame 和位置（占 frame 宽度和高度的百分比）定位元素；绝不重新读取构建后的页面。
修正明确且符合规则和决策的反馈：直接在 source 中应用。如果修正存在歧义，或与
```
CONTEXTE.md
```
中的规则、决策或其他屏幕相冲突，则通过问题工具向用户提出封闭式选择，而不是即兴发挥。
问题： 在对话中回答；如果需要作出决策，则将其添加到批次的 open points 和
```
CONTEXTE.md
```
中，并附上建议。
每系列反馈对应一次迭代：在批次 journal 中记录已处理的反馈（如“R1、R3：……”），重新构建，捕获已修改的屏幕（
```
--ids
```
），并重新发布已修改的页面。
使用
```
反馈 | 处理结果 | 屏幕
```
格式的表格作答。随后，用户可以在面板中将反馈标记为“已处理”，或者将其删除。

反馈保存在每个人的浏览器中：多位评审者会分别导出各自的反馈（输入的姓名会作为签名）。针对已交付屏幕的反馈（implementation status）遵循步骤 7 的流程：它还应改变代码，或者成为一项差异。

Option · Design System Claude Design

选项 · Claude Design System

Fonctionnalité facultative : chaque personne décide de l'utiliser ou non. La proposer une fois, par une question fermée (« Exporter l'identité vers un Design System Claude Design ? » Oui / Non / Plus tard), juste après la décision de l'étape 1A ou à l'étape 6, et noter la réponse dans

CONTEXTE.md

(section « Préférences ») pour ne pas la reposer. Ne jamais l'exporter sans accord.

Si la réponse est oui, deux temps.

1. Le catalogue (

specs/ui/design-system/

) :

bash

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

Il contient le README (thème, vocabulaire des tokens, règles d'usage),

tokens.css

, les fondations (couleurs, typographie, formes), les composants du catalogue et ceux du projet (

sources/shared/

). Chaque fiche porte le marqueur de carte de Claude Design.

2. Le paquet « tokens seuls » (

specs/design-system-package/

, à côté de

specs/ui/

). Claude Design construit en React à partir d'un paquet : comme les specs n'ont pas de composants React, on lui envoie l'identité sous forme de tokens et de classes utilitaires. Les fiches du catalogue deviennent les cartes visibles du projet.

bash

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

Compléter
```
.design-sync/conventions.md
```
à partir de
```
CONTEXTE.md
```
, en anglais, entre 2 000 et 4 000 caractères. C'est l'en-tête que lit le design agent : il doit nommer chaque token et dire quand l'employer, décrire les motifs récurrents (badges, coquille, en-têtes) et donner un exemple réaliste.
La personne lance ensuite
```
/design-sync
```
depuis ce dossier, et accorde l'accès avec
```
/design-login
```
si on le lui demande. Ce skill n'envoie rien lui-même.
Les étapes de reconstruction et les pièges connus sont dans
```
.design-sync/NOTES.md
```
.

Après une évolution de l'identité ou des composants partagés : relancer l'export, puis

npm run build

dans le paquet, puis

/design-sync

这是一项可选功能：由每个人自行决定是否使用。在步骤 1A 的决策之后或步骤 6 之后，通过一个封闭式问题提出一次（“将视觉身份导出到 Claude Design System？”是／否／稍后），并将回答记录在

CONTEXTE.md

的“Preferences”部分，避免重复询问。未经同意，绝不能导出。

如果回答为是，则分为两个阶段。

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

bash

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

其中包含 README（主题、token 词汇、使用规则）、

tokens.css

、foundations（颜色、排版、形状）、目录组件和项目组件（

sources/shared/

）。每张卡片都带有 Claude Design 的卡片标记。

2. 仅含 tokens 的包（
specs/design-system-package/
，与
specs/ui/
并列）。 Claude Design 会用 React 构建它。由于规格中没有 React components，因此需要将视觉身份以 tokens 和 utility classes 的形式发送。目录卡片会成为产品中可见的卡片。

bash

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 个字符。它是 design agent 读取的 header：必须命名每个 token 并说明何时使用，描述 recurring patterns（badges、shell、headers），并给出一个真实示例。
随后，用户在该目录中运行
```
/design-sync
```
，并在工具要求时通过
```
/design-login
```
授予访问权限。该 skill 本身不会发送任何内容。
重新构建步骤和已知陷阱记录在
```
.design-sync/NOTES.md
```
中。

视觉身份或共享组件发生变化后：重新导出，运行包中的

npm run build

，然后执行

/design-sync

。

Étape 6 · Passer aux développements

步骤 6 · 转入开发

Vérifier qu'aucun point ouvert ne bloque, activer le statut d'implémentation (étape 7), proposer l'export Design System si la personne ne s'est pas encore prononcée (voir l'option ci-dessus), proposer l'inventaire des composants récurrents, et rappeler que

tokens.css

se colle tel quel après

@import "tailwindcss";

. Sur demande, découper en stories avec les annotations comme critères d'acceptation.

Pour faire tester les parcours ou les montrer avant de développer, le skill

prototype-ui

transforme ces specs en prototype cliquable (mêmes écrans, données simulées, scénarios de test). Pour lancer les développements, le skill

requirements-doc

en tire le cahier des charges de l'équipe (specs par lot avec critères d'acceptation, architecture, stack, infrastructure, lots et estimations).

检查是否还有会阻塞工作的 open point，启用 implementation status（步骤 7）；如果用户尚未就此作出选择，则提出导出 Design System 的选项（参见上文），并提出 recurring components 清单。提醒用户在

@import "tailwindcss";

之后原样粘贴

tokens.css

。如有要求，可将屏幕拆分为 stories，并将 annotations 作为 acceptance criteria。

为了测试用户流程，或在开发前进行演示，

prototype-ui

skill 会将这些规格转换为可点击的 prototype（相同的屏幕、模拟数据、测试场景）。在启动开发时，

requirements-doc

skill 会从中生成团队的 cahier des charges（按批次划分的 specs、acceptance criteria、architecture、stack、infrastructure、batches 和 estimations）。

Étape 7 · Maintenir pendant les développements

步骤 7 · 在开发期间持续维护

Une fois les développements lancés, les specs restent la référence : elles décrivent ce que l'application fait, écran par écran, et suivent l'implémentation. Le dossier

specs/

vit dans le dépôt de l'application.

Statut d'implémentation. L'activer dans

sources/site.json

(

"implementation": true

), puis le tenir à jour dans le

lot.json

de chaque lot :

json

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

Valeurs :
```
todo
```
(À développer, par défaut),
```
doing
```
(En cours),
```
done
```
(Livré),
```
gap
```
(Écart : l'application diffère des specs ; la note dit en quoi).
Le build remplace le badge « Nouveau » de chaque état par le statut, met une pastille dans la navigation et affiche l'avancement sur l'index des lots et l'accueil. Le cahier des charges reprend les statuts à l'extraction.

Un écart constaté pendant le développement se tranche, puis se reporte dans le même changement que le code (même branche, même PR) :

Le code a raison (contrainte technique, meilleure idée validée) : modifier les sources de l'écran, incrémenter l'itération et noter au journal du lot « aligné sur l'implémentation », avec la raison. Garder les identifiants (écrans, états, numéros de règles) : le code et les tests les citent.
Les specs ont raison : le code se corrige ; en attendant, statut
```
gap
```
avec une note.
Question ouverte : point ouvert du lot et de
```
CONTEXTE.md
```
, statut
```
gap
```
.

Puis, dans l'ordre :

reconstruire les specs ;
reporter l'écart dans le prototype s'il câble l'écran (skill
```
prototype-ui
```
, « Suivre les specs ») ;
réextraire le cahier des charges et ajuster les critères touchés (skill
```
requirements-doc
```
, « Maintenir ») ;
publier les artifacts concernés (
```
prepare-publish.mjs … --check
```
dit lesquels sont en retard) ;
commiter les sources et les
```
.published.json
```
ensemble (et les sites construits, s'ils sont versionnés).

Numérotation stable. Une règle fonctionnelle garde son numéro : une nouvelle règle va à la fin de la liste, une règle abandonnée reste avec la mention « Retirée ». Un écran ou un état retiré garde son identifiant réservé. Les identifiants RF du cahier des charges viennent de ces numéros.

开发启动后，规格仍然是事实依据：它们逐屏描述应用的行为，并跟随实现同步更新。

specs/

文件夹保留在应用代码仓库中。

Implementation status。 在

sources/site.json

中启用（

"implementation": true

），然后在每个批次的

lot.json

中持续更新：

json

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

取值：
```
todo
```
（待开发，默认）、
```
doing
```
（进行中）、
```
done
```
（已交付）、
```
gap
```
（差异：应用与 specs 不一致；note 说明具体差异）。
Build 会将每个状态的“Nouveau” badge 替换为对应状态，在导航中添加一个标记，并在批次索引和首页显示进度。提取 cahier des charges 时，也会带上这些状态。

开发期间发现差异时，应先作出决定，然后在与代码相同的变更中报告（同一 branch、同一 PR）：

代码正确（存在技术限制，或采用了更好的方案并已确认）：修改屏幕 sources，增加迭代次数，并在批次 journal 中注明“已与实现对齐”及其原因。保留 identifiers（屏幕、状态、规则编号）：代码和测试会引用它们。
规格正确： 修正代码；在修正之前，将状态设为
```
gap
```
并添加 note。
开放问题： 添加到批次的 open points 和
```
CONTEXTE.md
```
中，并将状态设为
```
gap
```
。

然后按以下顺序执行：

重新构建 specs；
如果 prototype 接入该屏幕，则将差异同步到 prototype（
```
prototype-ui
```
skill，“Suivre les specs”）；
重新提取 cahier des charges，并调整受影响的 acceptance criteria（
```
requirements-doc
```
skill，“Maintenir”）；
发布相关 artifacts（
```
prepare-publish.mjs … --check
```
会指出哪些内容已落后）；
将 sources 和
```
.published.json
```
一起提交（如果构建后的站点也纳入版本管理，则一并提交）。

稳定编号。 一条功能规则始终保留其编号：新规则添加到列表末尾；废弃的规则保留并标注“Retirée”。被删除的屏幕或状态保留其 reserved identifier。Cahier des charges 中的 RF identifiers 来自这些编号。

Ce que ce skill ne fait pas

该 skill 不做什么

Il ne code pas l'application : les maquettes sont statiques, et les specs restent la référence.
Il ne copie pas l'identité d'un produit tiers : un site extérieur sert d'inspiration de structure, jamais de modèle visuel.

它不负责编写应用代码：原型是静态的，而 specs 始终是事实依据。
它不复制第三方产品的视觉身份：外部网站只能作为结构灵感，绝不能作为视觉样式范例。