From harness-flow
Transforms approved specs into reviewable UI design documents for pages, components, interactions, and frontend surfaces. Applies atomic design, design tokens, WCAG AA, Nielsen heuristics, and information architecture. For unapproved designs or hf-ui-review revisions.
npx claudepluginhub hujianbest/harness-flow --plugin harness-flowThis skill uses the workspace's default tool permissions.
当任务含 UI surface 时,把已批准规格转化为可评审的 **UI 设计文档**,说明"界面如何承载需求、用户如何完成任务、视觉如何成为产品的一部分",让后续任务规划与前端实现不再靠猜测推进。
Reviews completed UI design drafts for usability (Nielsen heuristics), accessibility (WCAG AA), spec traceability, design tokens, and peer alignment with hf-design-review. For formal verdict before joint approval or task planning.
Generates UI specifications for screens, component trees, props/state flows, interaction paths, responsive behavior, design tokens, and accessibility requirements. For frontend design phase before coding.
Enforces UI design contracts from DESIGN.md/plan.md and supplements baseline for explicit UI workflows, activated project visual changes, design system refactoring, and visual verification with code mapping and acceptance checks.
Share bugs, ideas, or general feedback.
当任务含 UI surface 时,把已批准规格转化为可评审的 UI 设计文档,说明"界面如何承载需求、用户如何完成任务、视觉如何成为产品的一部分",让后续任务规划与前端实现不再靠猜测推进。
本 skill 是 design stage 的 conditional peer:与 hf-design(技术/架构设计)同层并行,不 bypass 主链。两者都通过各自 review 才能进入 hf-tasks(联合 design approval)。
本 skill 融合以下已验证方法。每个方法在 Workflow 中有对应的落地步骤。
| 方法 | 核心原则 | 来源 | 落地步骤 |
|---|---|---|---|
| Information Architecture | 在 wireframe 之前先锁定站点地图、导航结构与内容分组,不让交互设计跑在 IA 之前 | Rosenfeld & Morville,《Information Architecture》 | 步骤 3 — 锁 IA 与用户流 |
| Atomic Design | 组件按 Atoms / Molecules / Organisms / Templates / Pages 分层,与 Design System 映射 | Brad Frost,《Atomic Design》 | 步骤 5 — 组件映射;步骤 6 — 编写文档 |
| Design System / Design Tokens | 所有颜色/字号/间距/圆角/阴影/动效走 token,不硬编码,视觉一致性优先于单页美化 | W3C Design Tokens CG;Material / HIG / Ant Design 等共同基础 | 步骤 4 — 视觉与 token 策略 |
| Nielsen 十大可用性启发式 | 可用性冷读 rubric;每个关键页面可在评审阶段按十条反查 | Nielsen Norman Group | 步骤 7 — 自检 |
| WCAG 2.2 AA | 可访问性硬门槛:色彩对比、键盘可达、语义/ARIA、焦点管理、reduced motion | W3C | 步骤 4 — 视觉策略;步骤 7 — 自检 |
| Interaction State Inventory | 每个关键交互必须至少覆盖 idle / hover / focus / active / disabled / loading / empty / error / success,防止只设计 happy path | Smashing Magazine、Adam Silver 等通用实践 | 步骤 3 — 用户流;步骤 5 — 组件映射 |
| ADR(继承自 hf-design) | UI 层关键决策(导航范式、组件库选型、布局模式、视觉方向)用同一 ADR 模板记录,含可逆性评估 | Nygard | 步骤 4 — 选定方案;步骤 6 — 编写文档 |
| Design Context First | 不在缺失既有 Design System / 品牌 / 既有产品上下文时从零起手;优先复用,必要时显式偏离 | Anthropic Claude Claude-Design 系统提示词 | 步骤 0 — 设计上下文获取 |
| Anti-Slop Discipline | 对抗 AI 默认审美:拒绝渐变滥用、紫色默认、Inter/Roboto 默认、左竖线圆角容器、装饰 SVG、emoji 当图标、通用 dashboard 模板等惯性 | Anthropic Claude Claude-Design 系统提示词;行业反 slop 经验 | 步骤 4 — 视觉方向;步骤 7 — 自检 |
| Earn-Its-Place Content | 每个 section / 文案 / 图标 / 数字必须能回指真实需求;缺资源时占位优于劣质仿制;规格之外不擅自加 section | Anthropic Claude Claude-Design 系统提示词;编辑规约 | 步骤 5 — wireframe;步骤 6 — 编写文档 |
| Vocalize the System Up Front | 进入 wireframe 之前,显式说出"将采用什么系统"(layout grid / 节奏 / 背景色用法 / 标题与图像分工等),让后续页面级决策对齐 | Anthropic Claude Claude-Design 系统提示词 | 步骤 4 — 视觉与 token 策略 |
补充借用(按需,不作为硬门):Risk-Driven Architecture (Fairbanks) 用于对高频/高业务风险页面投入更多打磨;YAGNI + Complexity Matching 防止规格未要求的动效或多主题过度设计。
使用:
hf-ui-review 返回 需修改 或 阻塞,需要按 findings 修订hf-design 已进入起草、需要并行起 UI 设计(parallel 默认模式)不使用:
hf-designhf-specify / hf-spec-reviewhf-designhf-taskshf-ui-reviewhf-workflow-router直接调用信号:"开始做 UI 设计"、"把页面和交互先定下来"、"UI 设计被打回了"、"先别拆任务,把界面想清楚"。
读取:
hf-design 当前最新稿(读 API 契约、错误模型、鉴权模型、状态形状;parallel 模式下可读草稿,标记"待 peer 锁定"条目)progress.md(默认 features/<active>/progress.md)产出:可评审 UI 设计草稿 + UI 决策 ADR + peer 交接说明。
Handoff:hf-ui-review(独立 reviewer subagent,不在父会话内联)。
联合 approval 规则:hf-design-review 与 hf-ui-review 同时通过后才能进入 设计真人确认;任一未过,另一方可继续稳定部分,但 approval step 不解锁。
hf-ui-review 通过前,不得拆解任务或编写前端实现代码hf-design-review 与 hf-ui-review 双通过前,不发起 设计真人确认using-hf-workflow 或 hf-workflow-router 入口判断(含 UI surface 激活条件判定),不直接开始 UI 设计hf-specify 显式补齐 UI surface 声明references/design-context-acquisition.md,写出"视觉语汇摘要"(缺资源时显式标注与用户确认){{ image:hero-product, 16:9 }}、{{ icon:warning }}、{{ copy:hero-headline-pending }}),不要让 LLM 自画 SVG 或自编正文hf-tasks)references/anti-slop-checklist.md):紫色 / 紫蓝渐变默认主色、Inter / Roboto / 系统栈无理由套用、所有 callout 都是"左 4px 彩条 + 圆角卡片"、emoji 当图标、自画"科技感" SVG 插画、千篇一律的 dashboard 模板、glassmorphism 滥用、5+ 不同阴影同页混用hf-design 的职责);需要时在文档标注"依赖 hf-design 锁定 "按 references/design-context-acquisition.md 完成:
ui-design.md 顶部未取到 P0 + P1 + 用户确认 → 不进入步骤 3(候选方向比较)。这是反 AI 默认审美的硬门,不可跳过。
读取 项目级路径约定(若项目已声明)、feature progress.md(默认 features/<active>/progress.md)、已批准规格(默认 features/<active>/spec.md)相关部分、hf-design 当前最新稿(若已有,默认 features/<active>/design.md)。
提取:
规格若缺以下信息,不假设默认:
hf-workflow-router读取:
不提前进入前端编码规划。若用户输入仍是 brainstorming(组件库名、页面截图灵感、零散视觉偏好混写):
候选方向 / 决策驱动因素 / 硬性约束 / 假设 / 明显越界的实现细节3.1 Information Architecture
产出至少一份站点地图或导航结构图(Mermaid / 文本树均可),含:
3.2 User Flow
对每条关键用户任务画出端到端路径。最少覆盖:
3.3 Interaction State Inventory
对每个关键交互(表单提交、数据加载、列表筛选、权限受限操作等)列状态矩阵:
| 交互 | idle | hover | focus | active | disabled | loading | empty | error | success | offline/partial |
|---|---|---|---|---|---|---|---|---|---|---|
| 示例 | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
高风险交互至少全列;一般交互至少覆盖 loading / empty / error 三态。状态矩阵是后续组件映射和任务拆解的必要输入。
对每个候选方向至少说明:
frontend-design skill 关于 "commit to a BOLD aesthetic direction" 的提法,本 skill 采纳"明确的视觉主张优于折衷的安全选择"这一原则,但在企业/工程化语境下默认倾向"intentional restraint(有意识的克制)"而非"maximalist chaos",除非规格显式要求。prefers-reduced-motion形成紧凑 compare view(表格或矩阵)——至少能冷读出:
复用既有 Design System 时,也要把"沿用现状"写入 compare view,而不是跳过比较。
选定后用 ADR 模板(见 references/adr-template.md,与 hf-design 共用)记录关键决策:视觉方向、组件库选型、导航范式、布局范式、主题策略、动效策略等。
Vocalize the System(进入 wireframe 之前必做):在选定方向 ADR 之后、wireframe 之前,显式写出本设计的"系统宣言"。最少包含:
系统宣言写完后立刻冷读:能否只看宣言就预测出所有关键页面的视觉骨架?不能 → 宣言不够;继续补。
若是因 hf-ui-review 打回而重入:先读 findings → 修复阻塞问题 → 不重做未受影响的部分。
5.1 Wireframe
对关键页面(规格中声明或 User Flow 中覆盖的核心页面)给出:
不要求像素级视觉稿;要求能冷读出"这个页面承担了哪条用户任务、主要操作在哪里、关键状态如何呈现"。
5.2 Atomic Design 组件映射
对关键组件按 Atomic 分层列出:
| 层级 | 组件 | 来源(复用 DS / 扩展 DS / 新增) | 依赖 token | 对应任务(待 hf-tasks 细化) |
|---|---|---|---|---|
| Atom | Button | 复用 shadcn/ui | color.primary, radius.md | ... |
| Molecule | SearchInput | 扩展(加 loading 图标) | ... | ... |
| Organism | DataTableWithFilters | 新增 | ... | ... |
新增组件需给出:职责、props 边界、关键状态、a11y 语义(role、aria-*)、键盘交互。
按 references/ui-design-doc-template.md 的默认结构(或 项目级覆盖的模板)。
明确区分规格层(做什么)、UI 设计层(界面如何承载)、任务层(分步实施,属 hf-tasks)。
默认要显式落下以下文档级语义:
{{ image:... }} / {{ icon:... }} / {{ copy:... }} 占位)hf-design 的 peer 依赖交接块:本 UI 设计依赖对方锁定的 X/Y/Z;本 UI 设计已锁定并可供对方依赖的 A/B/Chf-tasksreferences/anti-slop-checklist.md 第 5 节冷读 5 项)交 hf-ui-review 前确认:
references/anti-slop-checklist.md 第 5 节冷读 5 项已过;任何被标记为可疑 slop 的元素已修正或显式辩护hf-design 的 peer 依赖交接块已写明(依赖的、已锁的、冲突的)hf-tasksfeatures/<active>/ui-design.md)progress.md 已按 canonical schema 更新 Current Stage 和 Next Action准备好后,启动独立 reviewer subagent 执行 hf-ui-review,不在父会话内联评审。
按需加载详细参考内容:
| 主题 | Reference | 加载时机 |
|---|---|---|
| 项目级设计原则锚点 | 项目级约定(查找 design principles / design system / frontend principles / brand / a11y / i18n 的声明路径) | 项目存在此类锚点时,先按声明路径加载并用于筛选候选方向 |
| ADR 模板 | ../hf-design/references/adr-template.md | 记录 UI 关键决策时(与 hf-design 共用) |
| UI 设计文档模板 | references/ui-design-doc-template.md | 编写 UI 设计文档时 |
| 交互状态清单 | references/interaction-state-inventory.md | 列状态矩阵时 |
| a11y 检查清单(含最小尺寸表) | references/a11y-checklist.md | 做可访问性声明与自检时;定移动端 / 演示稿 / 印刷物最小尺寸时 |
| UI 决策矩阵模板(含多样性策略) | references/ui-decision-matrix.md | 写候选方向 compare view 时 |
| 设计上下文获取 | references/design-context-acquisition.md | 步骤 0;任何含 UI surface 的 feature 启动时必读 |
| 反 AI slop 设计清单 | references/anti-slop-checklist.md | 步骤 4 视觉方向决策 + 步骤 7 自检;评审时也用于 anti-pattern 检测 |
{{ image:... }} / {{ copy:... }} 占位hf-design 的 API 契约/数据模型决策写进 UI 文档| 易混淆 skill | 区别 |
|---|---|
hf-design | 本 skill 与 hf-design 是同层 peer:hf-design 管架构/模块/API 契约/数据模型/后端 NFR;本 skill 管 IA/wireframe/交互/视觉/组件/前端 a11y/i18n/响应式。两者共同进入联合 design approval。 |
hf-ui-review | 本 skill 负责起草 UI 设计;hf-ui-review 负责独立评审。不能自审自交。 |
hf-specify | specify 回答"做什么";本 skill 回答"界面如何承载"。规格未声明 UI surface 时本节点不激活。 |
hf-tasks | 本 skill 回答"UI 长什么样、交互怎么流、组件怎么组";tasks 回答"分几步实现"。UI 设计未双通过前不拆任务。 |
hf-workflow-router | router 负责阶段判断、激活判定和路由;本 skill 假设阶段已确定为"设计(含 UI surface)"。 |
完成时产出:
progress.md 更新:Current Stage → hf-ui-design;Next Action Or Recommended Skill → hf-ui-review若 hf-design 也在并行,feature progress.md 以最新进入的 skill 为 Current Stage,两条 skill 的 Next Action 分别登记在各自设计文档的状态字段中,由父会话/router 在联合 approval 时汇总。
推荐输出:
UI 设计文档草稿已起草完成,下一步应派发独立 reviewer subagent 执行 `hf-ui-review`。
推荐下一步 skill: `hf-ui-review`
若 UI 设计稿仍未达评审门槛,不伪造 handoff;明确还缺什么,继续修订。
hf-design 文件、非任务文件)references/anti-slop-checklist.md 第 5 节);缺资源处用带语义的 placeholderhf-design 的 peer 依赖交接块已写明hf-tasksprogress.md 已按 canonical schema 更新 Current Stage 和 Next Actionhf-ui-review