Files
MetaSkill/skills/le-app-design/SKILL.md
T

12 KiB
Raw Blame History

name, description, metadata
name description metadata
le-app-design Le App Design —— 统一 App 设计工坊:只叫这一个名字,自动完成「产品理解 → 视觉探索 → 设计规范 → Web 高保真原型 → 设计审查 → 优化迭代 → 交付」。底层真实集成并调用三个上游 Skill——frontend-design(视觉创意与品牌差异化,先定方向)、ui-ux-pro-max(设计规范系统化与 UX 硬约束校验,后编系统)、impeccable(设计审查/精修/反模式检测);本 Skill 只做依赖检测、任务分配、执行协调与质量控制,绝不替代三者任何能力。 何时触发:想要完整的 App / 产品 UI 设计流程——"帮我设计一个 App""做一个高保真原型""从想法到可交互原型""给这个产品做 UI 设计和原型""design an app";或指定若干界面做设计——"把首页和详情页这些界面设计出来""做移动端的页面/界面设计""App 界面改版"。 不要触发:点名单个上游 Skill 的直接请求(直连该上游即可);写作与排版类任务;单张配图生成;纯功能开发与排障(无设计诉求)。
author version runtimes requires
Leroy 1.2.0 zcode, claude-code, codex, opencode
ui-ux-pro-max (MIT, nextlevelbuilder/ui-ux-pro-max-skill)
frontend-design (Apache-2.0, anthropics/skills)
impeccable (Apache-2.0, pbakaus/impeccable)

Le App Design —— 统一 App 设计工坊

一个入口,三个真依赖。用户只说「帮我设计这个 App」,本 Skill 编排三个上游 Skill 完成从理解到交付的全流程。

铁律(违反任何一条即本次运行失败)

  1. 真调用,不冒充。 三个上游必须以其原生形态被实际调用:ui-ux-pro-max 跑它的 search.py CLI;impeccable 跑它的 impeccable CLI 并按其 SKILL.md 路由装载 reference/*.md playbook 照做;frontend-design 经宿主 Skill 工具装载(或 Read 原文全文)。禁止只引用名字、模仿理念、用自写流程替代。
  2. 依赖门不过,不许动工。 S0 检测到任何一个上游缺失/失活,立即向用户报告缺什么、怎么装,终止本次运行。不许跳过、不许假装集成完成。
  3. 调用必记账。 每次对上游的调用(含 playbook/文档装载)都经 log_call.py 落入本次运行目录的 calls.jsonl。没进账本的调用视为没发生。
  4. 交付必过验收门。 S7 跑 evidence_report.py,门按任务类型的 --require 集合判:完整流程要求三方各 ≥1 条履职阶段成功调用(pro-max 计 S3- 前缀,防 S2 调研混门);轻量路由只要求参与该路由的上游。不过门不许宣称完成。
  5. 不改上游。 三个上游目录只读(调用、装载),任何修改都不属于本 Skill 的职责。
  6. 用户 brief 原话 > 一切。 三个上游都自认 brief 优先,本 Skill 同样:brief 钉死的方向照办,冲突记入决策日志。

岗位分工(冲突时按此裁决)

维度 主责 裁决
视觉方向、品牌差异化、排版个性 frontend-design(design lead) 美学轴自由时听它的 POV,拒绝模板脸
设计规范、可访问性、触控/平台规则、数据支撑选型 ui-ux-pro-max 硬约束:WCAG/HIG/MD 类规则赢过美学偏好
质量底线、验收标准、反模式 impeccable craft-floor 的 ban 是红线(如 eyebrow 禁令、嵌套卡片必错)
产品事实、范围、语气 用户 brief 最高优先级

工作流 S0–S7

细则(每阶段的动作、命令、产物、验收)见 pipeline.md;跨 runtime 适配见 runtimes.md。设 <SKILL> = 本 Skill 目录,<RUN> = 运行目录(默认 <项目根>/le-app-design-runs/<时间戳>-<slug>/,下同)。

S0 依赖门(每次触发必跑,轻量任务也不例外)

python3 <SKILL>/scripts/check_deps.py --out <RUN>/deps.json

三方解析 + 活性检查(pro-max 真跑一次检索、impeccable 跑 --version、frontend-design 校验原文完整可读)。非零退出 → 停止并报告缺失项与安装指引,本次运行终止。

S1 产品理解

产出 <RUN>/BRIEF.md:项目代号(供 S3 的 -p 与目录命名)、产品是什么、给谁、核心任务、平台与形态、impeccable 四模式归属(Persuade / Operate / Read / Experience)。brief 信息不足且影响方向 → 问用户;足够 → 写明假设直接做。

S2 视觉探索 — frontend-design(方向先行)

  1. 宿主有 Skill 工具(ZCode / Claude Code)→ 用它装载 frontend-design;没有 → Read <DEP_FD>/SKILL.md 全文进上下文(一等路径,不是降级)。
  2. 装载后立即记账:python3 <SKILL>/scripts/log_call.py frontend-design --run-dir <RUN> --load <DEP_FD>/SKILL.md
  3. 按其「两遍法」产出 <RUN>/design-plan.md:从题材世界出发定艺术方向——色板(4–6 个具名 hex)、字体与角色、布局概念(一句话 + ASCII)、设计原则;对照它的 AI 味特征清单逐条自检,修订写明改了什么、为什么。此时不看任何品类匹配结果——方向由题材与 POV 决定,不由目录里有什么决定。
  4. (可选调研模式)方向成形前可用 pro-max 的 --domain style|color|typography 检索选项当情绪板(经 log_call 记账、note 标 S2-research)——只供参考,不做决定,不生成 MASTER。

S3 设计规范 — ui-ux-pro-max(系统后行)

方向已定,本阶段把它编撰成可执行的规范并对硬约束校验:

# 用已定方向的关键词驱动系统生成(不是品类词),dials 按方向调
python3 <SKILL>/scripts/log_call.py ui-ux-pro-max --run-dir <RUN> --note S3-design-system -- \
  python3 <DEP_UIUX>/scripts/search.py "<方向关键词,如 exercise-book hand-drawn sticker>" \
  --design-system --persist -p "<项目名>" --output-dir <项目根>

两条规则:

  • 硬约束否决权:frontend-design 定的 hex/字号若对比度、触控、平台规范不达标,以 pro-max 数据(WCAG/HIG/MD)为准改值不改方向;逐项校验(--domain ux、--domain typography 等)全部经 log_call。
  • 目录回弹降级:若 pro-max 风格目录(51 个活跃风格)对已定方向匹配失败——生成结果明显回弹到品类默认——则不采用该 MASTER,降级为「design-plan 的 token 表即规范 + pro-max 逐项校验补硬约束」,在 design-plan 决策记录里写明降级与理由。方向的独特性优先于系统的便利性。

停点 1(回合终止点)

向用户展示 BRIEF + design-plan(设计方向)+ MASTER 要点或降级说明,等确认或调整后再进构建。用户已明确说「一口气跑完」→ 豁免本停点,继续。本停点必须终止回合等待用户,不得自答自继续。

S4 高保真构建(a 首屏 → 停点 1.5 → b 全量)

  1. Read <DEP_IMPECCABLE>/reference/craft-floor.md(装载即调用)并记账。
  2. S4a 首屏:先只构建主界面一屏(真实内容 + 规范 token + design-plan 个性),390×844 截图。
  3. 停点 1.5(首屏确认,回合终止点):把首屏截图发到对话,请用户确认「方向落地长这样」再继续——这一站消除盲盒:成品第一次见面不再是 S5 之后。豁免时跳过停顿,但截图仍必须发出。
  4. S4b 全量:其余屏 + 完整交互(390 主档 + 375 兼容档截图;移动 Web 任务免桌面档)。显隐/布局断言用渲染事实(computed display / boundingRect),不信 hidden 属性。

S5 设计审查 — impeccable

  1. log_call.py impeccable -- sh <DEP_IMPECCABLE>/scripts/impeccable context --target <主文件>,按其指令行事。
  2. 按其 SKILL.md 路由装载 reference/critique.md(+ 需要的 audit/craft-floor 等)并照做——critique 要求双独立 sub-agent(Assessment A 设计评审 / Assessment B detect+浏览器证据):ZCode/Claude Code 用 Agent 工具并行派两个;Codex 按 critique.md 的 Codex 门问询;无 sub-agent 的 runtime 按其降级规则出横幅。playbook 装载逐一记账。
  3. Assessment B 真跑:log_call.py impeccable -- sh <DEP_IMPECCABLE>/scripts/impeccable detect --json <文件>;可浏览器时按 playbook 走 overlay/截图证据。
  4. 按 critique.md 完整出报告(启发式评分表、persona 红旗、P0–P3、快照持久化 + trend)。

停点 2(回合终止点)

展示审查报告并附修复前后关键截图(不是纯文字报告——用户确认修复范围时应已见过成品),四选一:全部 / Top 3 / 仅 P0-P1 / 保持现状(现状=跳过 S6 直接 S7,报告照出)。「一口气跑完」豁免同上;豁免时默认修 P0+P1,且审查报告末尾必须补字面行 Questions skipped: 停点2经用户豁免(默认修复 P0+P1)——这是 impeccable critique 契约的收尾要求,漏了即该次 critique 不完整。

S6 优化迭代

按确认的范围修复:P0/P1 必修;修完复跑 detect --json 至 0 findings(或记明剩余项与理由);复截图核对视觉。涉及大改方向的回到 S3 重走(罕见)。

S7 交付 + 验收门

# 完整流程(默认三方门,pro-max 计履职前缀)
python3 <SKILL>/scripts/evidence_report.py --run-dir <RUN> --out <RUN>/INTEGRATION-REPORT.md \
  --require "ui-ux-pro-max:S3-,frontend-design:S2-,impeccable" \
  --artifact <原型主文件> --artifact <RUN>/shot-*.png --artifact <RUN>/design-plan.md
# 系统路径(非降级)另加 --artifact design-system/<slug>/MASTER.md(slug 跑完 S3 后 ls design-system/ 确认)

交付物 = 原型(可打开可交互)+ BRIEF/design-plan/MASTER(或降级说明)+ 审查报告与快照 + INTEGRATION-REPORT。报告 FAIL(门或产物缺失)→ 不许宣称完成,如实说明缺什么。

轻量任务路由(含各自的验收门口径)

  • 仅审查/体检(「帮我审一下这个原型的设计」):S0 → S5(完整 critique:装载 critique.md + 双 sub-agent + detect + 快照)→ 停点 2 →(S6 按所选范围)→ S7。验收门 --require "impeccable"。
  • 局部修改(「把这个页面间距调好」):S0 → S2 快速版(涉及视觉决策时:装载 frontend-design + 记账,方向口头确认即可,无 design-plan 全文档)→ S4′(craft-floor 装载 + 就地修改 + 渲染事实断言 + 复截图)→ S5′(detect --json + 复截对比,不走完整 critique)→ S7。验收门 --require "impeccable"(走了 S2 快速版则加 ,frontend-design)。
  • 三上游经 check_deps 解析后始终可调用;轻量路由是省阶段,不是换实现——省掉的阶段不要求调用,但不许伪造调用记录凑门。

失败模式与停手点

  • 依赖缺失/失活:S0 即停,报缺失项与安装指引(见 README「依赖安装」)。
  • 上游 CLI 中途失败:重试一次;仍失败 → 记账(账本保留失败记录)、报告用户、终止或按用户指示降级到其余上游可覆盖的范围,并在交付物中明确标注缺口。
  • Chrome/浏览器不可用:截图核对改为声明 fallback(craft-floor 逐条人工核对),在报告中注明。
  • 用户点名单一上游:不触发本 Skill(负触发已在 description 声明)。

反例黑名单

  • 不要在账本外「顺手」直接调上游——没记账的调用等于没发生。
  • 不要把三个上游的文档内容抄进本 Skill 或其 references 来「省一次装载」。
  • 不要因为某上游慢/临时失败就用自己的设计判断顶替其岗位并照常宣称完成。
  • 不要在停点自问自答继续跑;豁免只能来自用户明确授权。
  • 不要检测到依赖缺失还继续产出「设计」——那是没有集成的假成功。

Reference Map