9.5 KiB
9.5 KiB
name, description, metadata
| name | description | metadata | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| le-app-design | Le App Design —— 统一 App 设计工坊：只叫这一个名字，自动完成「产品理解 → 设计规范 → 视觉探索 → Web 高保真原型 → 设计审查 → 优化迭代 → 交付」。底层真实集成并调用三个上游 Skill——ui-ux-pro-max（设计规范/UX 数据检索引擎）、frontend-design（视觉创意与品牌差异化）、impeccable（设计审查/精修/反模式检测）；本 Skill 只做依赖检测、任务分配、执行协调与质量控制，绝不替代三者任何能力。 何时触发：想要完整的 App / 产品 UI 设计流程——"帮我设计一个 App""做一个高保真原型""从想法到可交互原型""给这个产品做 UI 设计和原型""design an app"；或指定若干界面做设计——"把首页和详情页这些界面设计出来""做移动端的页面/界面设计""App 界面改版"。 不要触发：点名单个上游 Skill 的直接请求（直连该上游即可）；写作与排版类任务；单张配图生成；纯功能开发与排障（无设计诉求）。 |
|
Le App Design —— 统一 App 设计工坊
一个入口，三个真依赖。用户只说「帮我设计这个 App」，本 Skill 编排三个上游 Skill 完成从理解到交付的全流程。
铁律（违反任何一条即本次运行失败）
- 真调用，不冒充。 三个上游必须以其原生形态被实际调用：ui-ux-pro-max 跑它的
search.pyCLI；impeccable 跑它的impeccableCLI 并按其 SKILL.md 路由装载 reference/*.md playbook 照做；frontend-design 经宿主 Skill 工具装载（或 Read 原文全文）。禁止只引用名字、模仿理念、用自写流程替代。 - 依赖门不过，不许动工。 S0 检测到任何一个上游缺失/失活，立即向用户报告缺什么、怎么装，终止本次运行。不许跳过、不许假装集成完成。
- 调用必记账。 每次对上游的调用（含 playbook/文档装载）都经
log_call.py落入本次运行目录的calls.jsonl。没进账本的调用视为没发生。 - 交付必过验收门。 S7 跑
evidence_report.py，三方各有 ≥1 条成功调用记录才可宣称完成；否则如实报告 FAIL 与原因。 - 不改上游。 三个上游目录只读（调用、装载），任何修改都不属于本 Skill 的职责。
- 用户 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：产品是什么、给谁、核心任务、平台与形态（移动 Web / 桌面 / 响应式）、impeccable 四模式归属（Persuade / Operate / Read / Experience）。brief 信息不足且影响方向 → 问用户；足够 → 写明假设直接做。
S2 设计规范 — ui-ux-pro-max
python3 <SKILL>/scripts/log_call.py ui-ux-pro-max --run-dir <RUN> -- \
python3 <DEP_UIUX>/scripts/search.py "<产品类型 关键词>" --design-system --persist -p "<项目名>" --output-dir <项目根>
产出 design-system/<slug>/MASTER.md。按需补 --domain ux|typography|color|landing、--stack <栈> 定向检索（每次都走 log_call）。规范冲突时本阶段数据优先于直觉。
S3 视觉探索 — frontend-design
- 宿主有 Skill 工具（ZCode / Claude Code）→ 用它装载
frontend-design；没有 → Read<DEP_FD>/SKILL.md全文进上下文（一等路径，不是降级）。 - 装载后立即记账：
python3 <SKILL>/scripts/log_call.py frontend-design --run-dir <RUN> --load <DEP_FD>/SKILL.md - 按其「两遍法」产出
<RUN>/design-plan.md：色板（4–6 个具名 hex）、字体与角色、布局概念（一句话 + ASCII）、设计原则；对照它的 AI 味特征清单逐条自检，修订要写明改了什么、为什么。 - 与 S2 的 MASTER.md 冲突时按上方裁决表处理，冲突与裁决记入 design-plan.md 的「决策记录」节。
停点 1（回合终止点）
向用户展示 BRIEF + MASTER 要点 + design-plan，等确认或调整后再进构建。用户已明确说「一口气跑完」→ 豁免本停点，继续。本停点必须终止回合等待用户，不得自答自继续。
S4 高保真构建
- Read
<DEP_IMPECCABLE>/reference/craft-floor.md（impeccable 施工底线，装载即调用）并记账log_call.py impeccable --load <该文件>。 - 照 MASTER.md tokens + design-plan 写可运行、可交互的 Web 原型（默认单文件或多文件 HTML/CSS/JS，无构建链）。
- headless Chrome 截图核对（375/390 移动档 + 桌面档），按 craft-floor「一次看一批」原则修完再截。
S5 设计审查 — impeccable
log_call.py impeccable -- sh <DEP_IMPECCABLE>/scripts/impeccable context --target <主文件>，按其指令行事。- 按其 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 装载逐一记账。 - Assessment B 真跑：
log_call.py impeccable -- sh <DEP_IMPECCABLE>/scripts/impeccable detect --json <文件>；可浏览器时按 playbook 走 overlay/截图证据。 - 按 critique.md 完整出报告（启发式评分表、persona 红旗、P0–P3、快照持久化 + trend）。
停点 2（回合终止点）
展示审查报告，与用户确认修复范围（全部 / Top 3 / 仅 P0-P1）再进 S6。「一口气跑完」豁免同上。
S6 优化迭代
按确认的范围修复：P0/P1 必修；修完复跑 detect --json 至 0 findings（或记明剩余项与理由）；复截图核对视觉。涉及大改方向的回到 S3 重走（罕见）。
S7 交付 + 验收门
python3 <SKILL>/scripts/evidence_report.py --run-dir <RUN> --out <RUN>/INTEGRATION-REPORT.md \
--artifact <原型主文件> --artifact <截图...>
交付物 = 原型（可打开可交互）+ BRIEF/design-plan/MASTER + 审查报告与快照 + INTEGRATION-REPORT（三方调用统计、命令清单、产物存在性核验）。报告 FAIL（任何一方 0 成功调用）→ 不许宣称完成，如实说明缺什么。
轻量任务路由
- 仅审查/体检（「帮我审一下这个原型的设计」）：S0 → S5（→停点2）→ S6 → S7。
- 局部修改（「把这个页面间距调好」）：S0 → 若涉及视觉决策走 S3 快速版 → S4′（craft-floor 装载后施工）→ S5′（detect+复截）→ S7。
- 三上游经 check_deps 解析后始终可调用；轻量路由是省阶段，不是换实现。
失败模式与停手点
- 依赖缺失/失活：S0 即停，报缺失项与安装指引（见 README「依赖安装」）。
- 上游 CLI 中途失败：重试一次；仍失败 → 记账（账本保留失败记录）、报告用户、终止或按用户指示降级到其余上游可覆盖的范围，并在交付物中明确标注缺口。
- Chrome/浏览器不可用：截图核对改为声明 fallback（craft-floor 逐条人工核对），在报告中注明。
- 用户点名单一上游：不触发本 Skill（负触发已在 description 声明）。
反例黑名单
- 不要在账本外「顺手」直接调上游——没记账的调用等于没发生。
- 不要把三个上游的文档内容抄进本 Skill 或其 references 来「省一次装载」。
- 不要因为某上游慢/临时失败就用自己的设计判断顶替其岗位并照常宣称完成。
- 不要在停点自问自答继续跑；豁免只能来自用户明确授权。
- 不要检测到依赖缺失还继续产出「设计」——那是没有集成的假成功。
Reference Map
- 七阶段细则与验收：pipeline.md
- 跨 runtime 适配与已知限制：runtimes.md
- 依赖安装与许可证：README.md、NOTICE