141 lines
12 KiB
Markdown
141 lines
12 KiB
Markdown
---
|
||
name: le-app-design
|
||
description: |
|
||
Le App Design —— 统一 App 设计工坊：只叫这一个名字，自动完成「产品理解 → 视觉探索 → 设计规范 → Web 高保真原型 → 设计审查 → 优化迭代 → 交付」。底层真实集成并调用三个上游 Skill——frontend-design（视觉创意与品牌差异化，先定方向）、ui-ux-pro-max（设计规范系统化与 UX 硬约束校验，后编系统）、impeccable（设计审查/精修/反模式检测）；本 Skill 只做依赖检测、任务分配、执行协调与质量控制，绝不替代三者任何能力。
|
||
何时触发：想要完整的 App / 产品 UI 设计流程——"帮我设计一个 App""做一个高保真原型""从想法到可交互原型""给这个产品做 UI 设计和原型""design an app"；或指定若干界面做设计——"把首页和详情页这些界面设计出来""做移动端的页面/界面设计""App 界面改版"。
|
||
不要触发：点名单个上游 Skill 的直接请求（直连该上游即可）；写作与排版类任务；单张配图生成；纯功能开发与排障（无设计诉求）。
|
||
metadata:
|
||
author: Leroy
|
||
version: 1.2.0
|
||
runtimes: zcode, claude-code, codex, opencode
|
||
requires:
|
||
- "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](references/pipeline.md)；跨 runtime 适配见 [runtimes.md](references/runtimes.md)。设 `<SKILL>` = 本 Skill 目录，`<RUN>` = 运行目录（默认 `<项目根>/le-app-design-runs/<时间戳>-<slug>/`，下同）。
|
||
|
||
### S0 依赖门（每次触发必跑，轻量任务也不例外）
|
||
|
||
```bash
|
||
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（系统后行）
|
||
|
||
方向已定，本阶段把它**编撰**成可执行的规范并对硬约束校验：
|
||
|
||
```bash
|
||
# 用已定方向的关键词驱动系统生成（不是品类词），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 交付 + 验收门
|
||
|
||
```bash
|
||
# 完整流程（默认三方门，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
|
||
|
||
- 七阶段细则与验收：[pipeline.md](references/pipeline.md)
|
||
- 跨 runtime 适配与已知限制：[runtimes.md](references/runtimes.md)
|
||
- 依赖安装与许可证：[README.md](README.md)、[NOTICE](NOTICE)
|