要从零建立整套视觉识别（配色/字体/间距/组件/动效…

当需要为一个项目从零建立完整视觉宇宙（而非美化单个组件）时，按「头脑风暴→视觉/交互 thesis→设计系统 MASTER.md→逐页实现→审计」五阶段执行，并在轻量场景下自动缩短流程。

适用场景

解决思路

1. 执行前先做技术栈扫描：跑技能里给出的 bash 检测命令，检查 package.json（gsap / motion / framer-motion / three / react / vue / svelte / next / tailwind 等）、gradle 与 settings.gradle（androidx.compose、kotlin multiplatform、jetbrains.compose）、xcodeproj / Package.swift 与 Swift 文件（并区分 iOS/macOS）、viewport/manifest/sw.js 移动端指标，以及 .xib/.storyboard/res/layout XML/setContentView(R.layout.*) 等遗留混合指标；把结果映射为动画库、框架、CSS 方案、原生平台、移动/桌面上下文。
2. 若扫描到遗留混合（XIB / storyboard / layout XML / setContentView(R.layout.*)），头脑风暴阶段只额外问一个问题：本次是纯 Compose/SwiftUI，还是要集成进遗留页面；若选集成，只写桥接（Compose 用 AndroidView，SwiftUI 用 UIViewControllerRepresentable），绝不生成新的遗留代码（不写 XML、XIB、setContentView）。
3. 强制跑头脑风暴，永不跳过：覆盖五个域——产品（app/落地页/作品集/SaaS/电商/博客/仪表盘）、受众、氛围（3–5 个形容词）、参考（站点/截图/情绪板）、技术栈；一次只问一个问题，从最不明显的域开始；若已从 package.json 得知技术栈就不要问它，改从氛围或受众起问。
4. 处理模糊回答：先肯定（「这是个起点，我们把它变精确」），再给具体选项（如「像 Stripe 的编辑式留白 / 像 Linear 的密集但有序 / 像 Apple 的戏剧性极简」），再换角度问「什么会让你觉得不对？哪些站点让你反感？」，再点明后果（「这个选择决定整个配色和字体，值得花一分钟」）；绝不把模糊回答当确认，「嗯差不多」意味着继续追问是哪一部分打动了用户。
5. 用户催着跳过或加速时不要妥协：指出已覆盖的域与仍缺失的域，并说明缺失会造成的具体后果，给出二选一——「再问一个问题」还是「我做假设、你事后纠正」；若选假设，必须在 thesis 中逐条显式列出每个假设。不要谈判剩余问题数量（不说「再问两个就好」）。
6. 停止提问的时机：当你能写出视觉与交互两个 thesis，且有把握用户会说「oui parfait」；只要还有一个方面靠猜，就继续问。
7. 写视觉 thesis：一句话覆盖四个维度——色彩方向（明/暗、色系、强调色）、字体气质（衬线/无衬线/等宽、字重用法、字号对比）、间距哲学（密集/通透、基础单位感觉）、组件风格（圆角/锐利、描边/填充、浮起/扁平）；回读自查，四项缺一或含糊（如「好看的字体」）就重写后再展示。
8. 写交互 thesis：一句话覆盖四个维度——时间范围（快 100–200ms / 中 200–400ms / 慢 400ms+）、hover 行为、滚动行为（揭示/视差/无）、禁止模式（本项目不做什么）；自查标准是能否立刻从中推导出 CSS/JS 属性，否则重写。
9. 在第一个视觉 gate 前只问一次用户想怎么看预览：给出菜单 A. Artifact（实时页面，真实缓动曲线与时长）、B. Live preview（项目内一次性路由/原生 @Preview 草稿文件）、C. Inline（对话中写出），并标出推荐默认——轻量范围选 C；中/全量 Web 选 A；Compose/SwiftUI 选 B、次要 A；涉及完整视觉识别或设计系统选 A；无 dev server 或不能写仓库选 A；Cowork 无项目 checkout 选 A（B 不可用）。
10. 预览模式选定后整个会话固定：之后每个 gate 只用一行宣告模式（如「Variants in artifact.」）然后直接给，不再重开菜单；用户说「用文字给我」「放进 artifact」时立即遵从，且新模式从此成为会话默认。
11. 按手册生成有信息量的预览（不能只是换个字体的句子）：交互 thesis 展示用 SVG 画出的缓动曲线并打印精确值、真实执行交互且带重播按钮的元素、裸数值（时长/延迟/stagger/弹簧参数）、以及 reduced-motion 降级开关；变体展示同一张卡片并排、一个全局触发器同时触发以便对比，外加逐变体重播；视觉识别展示带 hex 与对比度的色板、真实字号阶梯的字体样本、间距条、圆角与阴影样本、一个真实按钮和一个真实卡片；设计系统渲染每个 token 类别、每个基础组件的五种状态（default/hover/focus/active/disabled）、明暗并排。
12. 预览必须遵守的规则：它是一次性的、绝不成为实现（实现要从已验证的 thesis 与载入的子技能重建，Compose/SwiftUI 上要说明 HTML 只近似时间与曲线、不近似渲染）；验证后删除 live-preview 路由，除非用户要求保留；绝不为预览安装依赖；未经询问不启动 dev server；只展示 thesis 中已有的值。
13. 等待用户对两个 thesis 的明确确认后再继续；用户有异议时不要推倒重来，而是问哪里感觉不对并调整。
14. 进入设计系统阶段：载入 ui-ux-pro-max 子技能并实际运行，用已确认的视觉 thesis（而非原始用户请求）作为查询词，顺序为「产品类型 行业 氛围形容词」，执行 python3 "$SKILL_BASE/ui-ux-pro-max/scripts/search.py" "<...>" --design-system -f markdown；-f markdown 不可省略（默认 ascii 会输出 ANSI 转义垃圾且 token 约为 3.3 倍）。
15. 把检索结果当提案而非答案（它是对静态数据集的查询，没见过本项目）：保留服务于已确认视觉 thesis 的部分，丢弃与其冲突的部分，并用一行说明取了什么、丢了什么；与 thesis 冲突的配色永远让位于 thesis。
16. 若 python3 不可用或脚本失败，用一行说明后手动从 thesis 推导设计系统，管线不因此停止。
17. 按检测到的技术栈生成对应的 token 代码文件：Web 生成 Tailwind config / CSS 变量（hex、cubic-bezier、rem）；Android Compose 生成 Theme.kt、Color.kt、Type.kt、Shapes.kt、Motion.kt（Color(0xFF...)、TextStyle、RoundedCornerShape、MotionScheme，间距用 dp）；SwiftUI 生成 Color+App.swift、Font+App.swift、Animation+App.swift、Shape+App.swift（Color("AssetName") 或 Color(red:green:blue:)、Font.system/.custom、.spring/.snappy/.bouncy，间距用 CGFloat）；Compose Multiplatform 在 commonMain 生成并用 expect/actual 处理字体与平台色；多栈项目在 MASTER.md 中分节并为每栈各出代码文件。
18. 生成完整设计系统内容：色板（primary/secondary/accent/neutrals/semantic，必要时含明暗两套）、字体（字体栈、字号阶梯、字重用法、行高规则）、间距（基础单位与阶梯 4/8/12/16/24/32/48/64…）、圆角阶梯（none/sm/md/lg/full）、阴影层级（0–4）、基础组件（按钮、输入、卡片、徽标、链接）、motion tokens（时长阶梯 fast/normal/slow、缓动名、stagger 延迟）。
19. 在项目根目录创建 MASTER.md 作为唯一真源，所有实现决策引用它；生成的语言文件是 MASTER.md 的子文件并引用它（多栈项目在 MASTER.md 内按栈分节）。
20. 如可用则使用 MCP 工具：Stitch（生成线框/稿）、Nano Banana（生成插画、图标、背景等视觉资产）、21st.dev Magic（按描述生成 UI 组件）；不可用则优雅跳过，设计系统 + 代码实现仍是核心路径。
21. 进入实现前在会话既定预览模式中展示设计系统并取得确认（一行宣告模式，不重开菜单）——所有 token 即将全局应用，这里是发现错误最便宜的地方。
22. 实现阶段按需载入子技能：永远载入 motion-principles；有移动上下文载 mobile-principles，有桌面上下文载 desktop-principles；明确要求审计或 scope=full 载 design-audit；高级 UI/UX 问题载 ui-ux-pro-max；再按检测到的栈载 gsap / framer-motion（motion 与 framer-motion 是同一库的两个包名，两个都存在时说明项目处于迁移中并跟随所编辑文件已 import 的那个）/ css-native / threejs-r3f / canvas-generative / compose-motion / compose-multiplatform / swiftui-motion，以及当 thesis 命中 shader、Metal、AGSL、RuntimeShader、MSL、liquid-glass、glassEffect、morphing transition、M3 Expressive、MotionScheme、colorEffect、distortionEffect、layerEffect、生成式 Canvas、holographic、CRT、displacement、ripple 等关键词时，额外载 compose-graphics 或 swiftui-graphics。
23. 实现时逐页或逐组件推进，绝不一次做完；每个颜色/字体/间距/阴影/圆角都必须取自 MASTER.md 的 token，不出现魔法数字和随意 hex；每个动画都遵守交互 thesis（时长、缓动、禁止模式）；交互元素应用五状态规则（default、hover、focus、active、disabled）；每个主要页面/区块完成后先求用户确认再进入下一个。
24. 审计阶段永不跳过：载入 design-audit 子技能，运行与检测栈匹配的完整检查清单。
25. 对「可在此检查」的一项一项带证据汇报（格式：检查项 - 结论 - 证据，证据是跑过的 grep、算出的值或 file:line；无证据的结论不算发现，没查成的报「未检查」而非通过）：reduced-motion 是否真正降级（Web 的 prefers-reduced-motion、SwiftUI 的 accessibilityReduceMotion、Compose 基于 ValueAnimator.areAnimatorsEnabled()/ANIMATOR_DURATION_SCALE 的 helper）；卸载处是否有退出动画；是否没有动画化 width/height/top/left/margin/padding 等布局属性（改用 transform、opacity、graphicsLayer）；每个交互元素是否 focus 可见且没有无替代的 outline: none；交互元素是否具备五状态；是否用 token 而非魔法数字（列出违规的 file:line）；对比度是否达标（正文 ≥4.5:1、大字号与 UI 边界 ≥3:1，要从 token 值实际计算，不靠肉眼，例如 #831843 on #FDF2F8 = 9.4:1）；语义是否到位（Web 无裸可点 div、装饰性动效加 aria-hidden；Compose 用 Modifier.semantics；SwiftUI 对无文字控件加 .accessibilityLabel）；Web 的条件渲染是否包在 AnimatePresence 或框架等价物中、will-change 是否克制使用并在动画后移除。
26. 对无法在会话内验证的项（Profiler、真机、指针）绝不勾选、绝不弱化、绝不因其余项干净而省略本段：以交接块给出精确执行方式并标 UNVERIFIED，包括 Web 用 Chrome DevTools Performance 录制交互（无帧超过 16.7ms）、375/768/1024/1440 视口下检查（无横向滚动、无裁切）、开启系统「减少动态效果」后跑一遍（降级路径真正生效）；Compose 用 Layout Inspector > Component Tree > View Options > Show Recomposition Counts（滚动时计数稳定）和 androidx.benchmark.macro Macrobenchmark（中端机 60fps 下 <16.67ms、120fps 下 <8.33ms）；SwiftUI 用 Instruments > Animation Hitches（过渡无 hitch）以及开启 Reduce Motion、Dynamic Type 200% 检查（无裁切、无只靠位移的表达）；macOS 用指针遍历每个交互元素并用键盘走完整视图（hover 生效、焦点环可见、快捷键已绑定）。
27. 两组分开汇报并给出计数（例如「9 checked, 2 problems found, 8 handed over」）；已检查组内按 Critical > Important > Nice-to-have 排序，交接组不排序、不过滤、整体交付。
28. 每个跨用户 gate 之后的 Bash 调用都要在同一个调用内重新输出 skill-base 解析块再用 load_skill（$SKILL_BASE 与 shell 状态不跨调用存活，否则路径会解析成 /<name>/SKILL.md 而静默失败）；load_skill 在子技能缺失时只警告（输出到 stderr）并继续，不失败；不要在未定义 $SKILL_BASE 的调用里 cat 路径。
29. 判断是否属于 light scope：三个条件需全部满足——目标是单个组件/单个效果/孤立元素；不建立视觉识别（项目已有配色字体，或尚无项目只有草图）；下游不依赖结果被系统化。若有两个以上不成立就不是 light scope，跑完整管线并用一行说明理由。
30. light scope 下的具体变更：头脑风暴只问一个最不明显的问题后停下；只做交互 thesis 且仍须明确验证；跳过设计系统（不写 MASTER.md，读取项目已有 token 使用，绝不新造）；只实现那一个组件；审计缩短为快速检查（reduced-motion、退出动画、60fps）。并且只宣告一次（例如「这是单个组件，所以跑 paint light：一个问题、不生成设计系统文件。需要完整管线请说一声」），让用户知道走了哪条管线并可推翻。
31. light scope 下依然不能做的事：完全不问头脑风暴问题、跳过 thesis、跳过验证——每个 gate 都保留，只是数量减少。
32. 在已有设计的项目上被调用时：仍跑完整头脑风暴；承认现有设计但 thesis 优先于它；实现阶段用新设计系统替换现有 design token/样式；保留功能与布局结构，只替换视觉层（这是刻意设计——要增强现有设计应改用 /genjutsu:cast）。
33. 语气分两档：执行过程中可用简短、沉浸、带忍术味的短句（如「Brushing the color palette...」）；在报告、最终总结、审计结果中彻底去掉修辞，只讲事实——改了什么、动了哪些文件、下一步。
34. 时刻自查红旗思维并纠正：两个字不构成五个域；一次只问一个问题；用户不耐烦时用压力协议而非跳步；token 一律来自 MASTER.md；逐页做逐页验；thesis 是法律（要加 bounce 必须重新验证）；审计永不跳过；勾选不算发现（给 grep/比值/file:line 或报未检查）；不能 profile 就交交接块；「嗯差不多」不是 yes；hex 列表精确但不可评审，要用预览模式展示；预览模式问一次即固定；预览页面好看也不能拿它当实现蓝本，实现从 MASTER.md 来。

适用边界 · 注意事项

• 目标只是单个组件、单个悬停或单个动效微调（如「让这个词动起来」「打磨这个 hover」）时不要用完整 paint 管线——那属于 /genjutsu:cast，paint 应降级为 light scope（一个问题、只做交互 thesis、不生成 MASTER.md）。
• 只想在保留现有设计的前提下增强、润色已有界面时不要用 paint：paint 会重建视觉宇宙并替换现有 token 与样式，这种情况应改用 /genjutsu:cast。
• 宿主环境没有可写入的项目 checkout（例如 Cowork 无项目检出）时无法提供 B 模式 live preview，此时不要承诺该选项；缺少 genjutsu 子技能或对应运行环境时管线会降级或部分不可执行。