ui-design
- Repo stars 141
- Author updated Live
- Author repo CataForge
- Domain
- Design
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @lync-cyber · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: ui-design
description: 基于Step 1确立的设计方向定义Token,每个Token选择须有设计意图: 若 {INSTRUCTION_FILE} 设计工具 为 penpot,调用 penpot-sync 将token…
category: design
runtime: no special runtime
---
# ui-design output preview
## PART A: Task fit
- Use case: 基于Step 1确立的设计方向定义Token,每个Token选择须有设计意图: 若 {INSTRUCTION_FILE} 设计工具 为 penpot,调用 penpot-sync 将token同步到Penpot项目和 tokens.css 从PRD功能需求推导页面和组件需求: runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “能力边界 / 输入规范 / 输出规范” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “基于Step 1确立的设计方向定义Token,每个Token选择须有设计意图: 若 {INSTRUCTION_FILE} 设计工具 为 penpot,调用 penpot-sync 将token同步到Penpot项目和 tokens.css 从PRD功能需求推导页面和组件需求: runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “能力边界 / 输入规范 / 输出规范” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “能力边界 / 输入规范 / 输出规范”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: ui-design
description: 基于Step 1确立的设计方向定义Token,每个Token选择须有设计意图: 若 {INSTRUCTION_FILE} 设计工具 为 penpot,调用 penpot-sync 将token…
category: design
source: lync-cyber/CataForge
---
# ui-design
## When to use
- 基于Step 1确立的设计方向定义Token,每个Token选择须有设计意图: 若 {INSTRUCTION_FILE} 设计工具 为 penpot,调用 penpot-sync 将token同步到Penpot项目和 tokens.cs…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “能力边界 / 输入规范 / 输出规范” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "ui-design" {
input -> user goal + target files + boundaries + acceptance criteria
context -> 能力边界 / 输入规范 / 输出规范
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} UI设计 (ui-design)
能力边界
- 能做: 设计方向决策、设计系统token定义、页面布局决策、组件规范定义、交互流程、响应式策略、组件目录维护(C-NNN注册/去重/合并)、设计token一致性检查
- 不做: 需求分析、架构设计、代码实现、从 Penpot 设计稿生成代码骨架(由 penpot-implement 负责)
输入规范
- prd#§2功能需求(F-{NNN})
- arch#§2模块划分(M-{NNN})
- 用户对产品调性和视觉偏好的输入(Step 1采集)
输出规范
- 设计方向声明(调性/风格参考/视觉策略)
- 设计系统token(色彩/排版/间距),含设计意图说明
- 组件清单(C-{NNN}),含变体、Props和视觉说明
- 页面布局(P-{NNN}),含路由、状态流和空间构成说明
- 导航与路由表
- 响应式断点策略
执行流程
Step 1: 设计方向决策(产出任何Token前必须完成)
理解产品上下文,确立设计方向:
- 用户与场景: 产品服务什么人?在什么环境使用?(办公桌前/通勤中/嘈杂车间)
- 产品调性: 通过user-interview向用户确认调性方向,提供具体选项而非开放提问。示例选项:
- 专业克制(企业工具/数据平台) vs 活泼亲和(消费端/社交)
- 信息密集(仪表盘/管理后台) vs 内容聚焦(阅读/展示)
- 科技感(深色/渐变/动效) vs 朴素实用(浅色/清晰/快速)
- 视觉参考: 询问用户是否有喜欢的产品或网站作为参考。有参考时提取其视觉特征(配色倾向/排版密度/圆角程度/留白比例)作为设计输入
- 产出: 在ui-spec §0写入设计方向声明(2-3句),后续所有Token和组件决策须可追溯到此方向
Step 2: 设计系统Token定义(对应ui-spec §1)
基于Step 1确立的设计方向定义Token,每个Token选择须有设计意图:
色彩体系:
- 确立主色(brand)、语义色(success/warning/error/info)、中性色(背景/文字/边框)
- 主色与辅色之间应有明确的主次关系——主色占视觉主导,辅色用于强调和引导,避免多个颜色平均分配
- 中性色不只是灰色,应从主色中提取色相倾向(暖灰/冷灰/蓝灰)以保持色彩体系的一致感
- 确保对比度满足WCAG AA标准(正文≥4.5:1,大标题≥3:1)
排版体系:
- 选择与产品调性匹配的字体,说明选择理由。西文字体与中文字体需分别指定并确认混排效果
- 定义清晰的字号层级(标题/副标题/正文/辅助文字),层级之间有可感知的视觉差异
- 行高和字重定义完整(非仅指定font-family)
间距与圆角:
- 使用一致的间距基数(如4px/8px倍数)
- 圆角程度与产品调性一致(企业工具偏小圆角2-4px,消费产品可用较大圆角8-16px)
Step 3: [Penpot可选] Token同步
若 {INSTRUCTION_FILE} 设计工具 为 penpot,调用 penpot-sync 将token同步到Penpot项目和 tokens.css
Step 4: 页面与组件规划
从PRD功能需求推导页面和组件需求:
- 先规划页面(P-NNN):按用户任务流组织,不是按功能模块罗列
- 再推导组件(C-NNN):从页面需求中提取可复用的交互单元
Step 5: 组件定义(对应ui-spec §2)
为每个组件定义完整规范:
- 变体: 不仅列出状态名(default/hover/active/disabled/error),还需描述各状态的视觉差异(如hover时颜色变化方向、disabled时的透明度处理)
- Props: 类型定义完整
- 视觉说明: 组件的空间比例、内间距、关键视觉特征(如按钮的高度比例、图标与文字的间距关系)
- 交互说明: 关键交互行为和反馈方式
Step 6: 页面布局(对应ui-spec §3)
为每个页面定义布局:
- 空间构成: 描述页面的空间节奏——哪里密集(操作区)、哪里留白(呼吸空间)、视觉重心在哪里
- 布局描述: 区域划分、组件排列方式,足以让开发者还原而无需猜测
- 状态流: loading/empty/populated/error 四态的具体视觉表现(如loading用骨架屏还是加载动画,empty态的引导文案和插图)
Step 7: 响应式策略
- 定义断点和各断点下的布局变化
- 说明哪些组件在小屏下隐藏、折叠或变形
Step 8: 组件目录维护
- 整理组件需求,去重合并同类组件
- 检查组件间一致性(token引用、命名风格)
- 确保组件复用,避免重复定义
- Token变量化,确保全局一致
Step 9: [Penpot可选] 设计一致性验证
若 {INSTRUCTION_FILE} 设计工具 为 penpot,调用 penpot-review 验证设计文件与ui-spec的一致性
Anti-Patterns
- 禁止: 跳过 Token 阶段直接画组件 —— Token 是设计系统基础,未先确立会让组件层风格漂移,后期返工成本高
- 禁止: 在 ui-spec 写交互逻辑细节("点击后弹出 X 然后 Y")—— 交互流转属于产品需求层,ui-spec 只承载视觉与结构契约
- 禁止: 用截图 / 图片代替组件结构描述 —— ui-spec 必须是文字可索引的契约,否则 implementer 无法精确还原也无法被 reviewer 校对
- 避免: 一次设计所有页面 —— 按 P-xxx 分批,每批闭环 Token → 组件 → 页面,避免后期单点改动引发全局连锁
效率策略
- 设计方向先行,避免Token定义完成后才发现方向不对
- 设计系统先行,确保组件一致性
- 组件复用优先,减少重复定义
Decide Fit First
Design Intent
How To Use It
Boundaries And Review