le-app-design v1.1.0：阶段顺序修正——frontend-design 先定方向，ui-ux-pro-max 后编系统（方向由题材与 POV 决定，不由品类目录决定）。依据四条：①pro-max 自身 Step 1 契约即期望风格关键词作为输入；②impeccable craft-floor 原文 direction settled 后才施工；③两次实跑实证系统先行产出品类默认脸（cream 命中 detect tell / Tailwind 默认靛蓝被评审点名），frontend-design 两遍法被迫做防守性裁决；④专业流程方向先于系统。新增两补丁：硬约束否决权（改值不改方向）与目录回弹降级（51 风格目录匹配失败时用 design-plan token 表 + pro-max 逐项校验）；S2 可选调研模式（--domain 检索当情绪板，不做决定）；停点2 补 impeccable critique 的 Questions skipped 字面行硬规则（上次审计发现的契约遗漏）
This commit is contained in:
leroy
@@ -1,12 +1,12 @@
|
||||
---
|
||||
name: le-app-design
|
||||
description: |
|
||||
Le App Design —— 统一 App 设计工坊：只叫这一个名字，自动完成「产品理解 → 设计规范 → 视觉探索 → Web 高保真原型 → 设计审查 → 优化迭代 → 交付」。底层真实集成并调用三个上游 Skill——ui-ux-pro-max（设计规范/UX 数据检索引擎）、frontend-design（视觉创意与品牌差异化）、impeccable（设计审查/精修/反模式检测）；本 Skill 只做依赖检测、任务分配、执行协调与质量控制，绝不替代三者任何能力。
|
||||
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.0.0
|
||||
version: 1.1.0
|
||||
runtimes: zcode, claude-code, codex, opencode
|
||||
requires:
|
||||
- "ui-ux-pro-max (MIT, nextlevelbuilder/ui-ux-pro-max-skill)"
|
||||
@@ -52,30 +52,36 @@ python3 <SKILL>/scripts/check_deps.py --out <RUN>/deps.json
|
||||
|
||||
产出 `<RUN>/BRIEF.md`：产品是什么、给谁、核心任务、平台与形态（移动 Web / 桌面 / 响应式）、impeccable 四模式归属（Persuade / Operate / Read / Experience）。brief 信息不足且影响方向 → 问用户；足够 → 写明假设直接做。
|
||||
|
||||
### S2 设计规范 — ui-ux-pro-max
|
||||
|
||||
```bash
|
||||
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
|
||||
### 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 味特征清单逐条自检，修订要写明改了什么、为什么。
|
||||
4. 与 S2 的 MASTER.md 冲突时按上方裁决表处理，冲突与裁决记入 design-plan.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 + MASTER 要点 + design-plan，等确认或调整后再进构建。用户已明确说「一口气跑完」→ 豁免本停点，继续。**本停点必须终止回合等待用户，不得自答自继续。**
|
||||
向用户展示 BRIEF + design-plan（设计方向）+ MASTER 要点或降级说明，等确认或调整后再进构建。用户已明确说「一口气跑完」→ 豁免本停点，继续。**本停点必须终止回合等待用户，不得自答自继续。**
|
||||
|
||||
### S4 高保真构建
|
||||
|
||||
1. Read `<DEP_IMPECCABLE>/reference/craft-floor.md`（impeccable 施工底线，装载即调用）并记账 `log_call.py impeccable --load <该文件>`。
|
||||
2. 照 MASTER.md tokens + design-plan 写可运行、可交互的 Web 原型（默认单文件或多文件 HTML/CSS/JS，无构建链）。
|
||||
2. 照规范 tokens（MASTER.md，或 S3 降级时的 design-plan token 表）+ design-plan 写可运行、可交互的 Web 原型（默认单文件或多文件 HTML/CSS/JS，无构建链）。
|
||||
3. headless Chrome 截图核对（375/390 移动档 + 桌面档），按 craft-floor「一次看一批」原则修完再截。
|
||||
|
||||
### S5 设计审查 — impeccable
|
||||
@@ -87,7 +93,7 @@ python3 <SKILL>/scripts/log_call.py ui-ux-pro-max --run-dir <RUN> -- \
|
||||
|
||||
### 停点 2（回合终止点）
|
||||
|
||||
展示审查报告，与用户确认修复范围（全部 / Top 3 / 仅 P0-P1）再进 S6。「一口气跑完」豁免同上。
|
||||
展示审查报告，与用户确认修复范围（全部 / Top 3 / 仅 P0-P1）再进 S6。「一口气跑完」豁免同上；**豁免时默认修复范围为 P0+P1，且审查报告末尾必须补字面行 `Questions skipped: 停点2经用户豁免（默认修复 P0+P1）`——这是 impeccable critique 契约的收尾要求，漏了即该次 critique 不完整。**
|
||||
|
||||
### S6 优化迭代
|
||||
|
||||
@@ -105,7 +111,7 @@ python3 <SKILL>/scripts/evidence_report.py --run-dir <RUN> --out <RUN>/INTEGRATI
|
||||
## 轻量任务路由
|
||||
|
||||
- **仅审查/体检**（「帮我审一下这个原型的设计」）：S0 → S5（→停点2）→ S6 → S7。
|
||||
- **局部修改**（「把这个页面间距调好」）：S0 → 若涉及视觉决策走 S3 快速版 → S4′（craft-floor 装载后施工）→ S5′（detect+复截）→ S7。
|
||||
- **局部修改**（「把这个页面间距调好」）：S0 → 若涉及视觉决策走 S2 快速版 → S4′（craft-floor 装载后施工）→ S5′（detect+复截）→ S7。
|
||||
- 三上游经 check_deps 解析后始终可调用；轻量路由是省阶段，不是换实现。
|
||||
|
||||
## 失败模式与停手点
|
||||
|
||||
Reference in New Issue
Block a user