ui-design
UI 样式修改协作流程。当用户要求修改页面样式、调整布局、改 UI 细节时使用。通过"截图定位 → 现状描述 → 方案选择 → 改代码 → 微调"的结构化流程,减少沟通偏差,避免浪费 token。
Best use case
ui-design is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
UI 样式修改协作流程。当用户要求修改页面样式、调整布局、改 UI 细节时使用。通过"截图定位 → 现状描述 → 方案选择 → 改代码 → 微调"的结构化流程,减少沟通偏差,避免浪费 token。
Teams using ui-design should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/ui-design/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How ui-design Compares
| Feature / Agent | ui-design | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
UI 样式修改协作流程。当用户要求修改页面样式、调整布局、改 UI 细节时使用。通过"截图定位 → 现状描述 → 方案选择 → 改代码 → 微调"的结构化流程,减少沟通偏差,避免浪费 token。
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
用户要求修改页面的 UI 样式(布局、间距、颜色、组件搭配等视觉层面的调整)。通过结构化的协作流程完成修改,确保每一步都对齐目标,不做无效猜测。 ## 核心原则 - **不猜,不抢跑** — 没有对齐目标之前,绝不动代码 - **截图是第一语言** — 主动要求用户提供截图,用截图定位问题 - **ASCII 画方案** — 布局方案用 ASCII 画出来,文字描述容易产生歧义 - **每次只改一个点** — 不要一次改多个地方,逐步逼近目标 ## 工作流程 ### 第 1 步:定位问题 用户说想改某个地方时,先做两件事: 1. **读代码** — 读取相关文件,理解当前实现 2. **描述现状** — 用 ASCII 画出当前布局,向用户确认:"我看到的是这样,对吗?" ``` 示例: ┌─────────────────────────────────────────────┐ │ 📈 标题 [🔄] │ │ 副标题说明文字 │ │ 🔍 [搜索框... ] │ ├─────────────────────────────────────────────┤ ``` **禁止**:跳过这一步直接问"你想改成什么样"。必须先让用户确认你理解了现状。 ### 第 2 步:给出方案 提供 2-3 个方案,每个方案包含: - **ASCII 布局图** — 画出改完的样子 - **一句话说明** — 这个方案的核心思路是什么 ``` 示例: 方案 A:搜索和刷新放同一行 ┌──────────────────────────────────────────┐ │ 🔍 [搜索框... ] [🔄] │ └──────────────────────────────────────────┘ 方案 B:刷新挪到标题行 ┌──────────────────────────────────────────┐ │ 📈 标题 [🔄] │ │ 🔍 [搜索框... ] │ └──────────────────────────────────────────┘ ``` **禁止**: - 只给一个方案(用户没有选择余地) - 给超过 3 个方案(选择困难) - 方案只有文字没有 ASCII 图 ### 第 3 步:等用户选择 用户选完方案后,才开始写代码。 **禁止**:用户还没选就开始改代码。 ### 第 4 步:改代码 执行最小改动,只改用户选定方案涉及的部分。 **禁止**:顺手改其他地方、优化代码结构、加注释。 ### 第 5 步:微调 改完后让用户看效果。用户可能会提出微调: - "加个边框" - "颜色太深" - "间距再大一点" 微调是**具体的、小的修改**,直接执行,不需要再走方案选择流程。 如果用户的反馈不够具体(比如"感觉不对"),主动追问: - "是大小的问题、颜色的问题、还是位置的问题?" - "和旁边哪个元素搭配起来不协调?" ## 沟通规范 ### 用户应该提供的 | 信息 | 说明 | |---|---| | 截图 | 标注出想改的区域 | | 问题描述 | "这两个元素搭配不协调"、"间距太大" | | 选择方案 | 从给出的方案中选一个 | ### AI 应该做的 | 阶段 | 输出 | |---|---| | 定位 | ASCII 现状图 | | 方案 | 2-3 个 ASCII 方案图 + 一句话说明 | | 改码 | 最小改动,只改选定方案 | | 微调 | 直接执行具体调整 | ### AI 绝不应该做的 - 用户说"改布局"就直接猜想法然后改代码 - 一次给出大段代码重构 - 微调阶段还在给多个方案让用户选 - 顺手改用户没提到的地方
Related Skills
design-exploration
新功能设计探索流程。当用户有模糊想法要做新功能/新模块时使用。通过"需求收敛 → 技术调研 → ASCII 批量探索 → HTML 设计稿 → 全状态覆盖 → 需求总结"的结构化流程,从模糊想法产出可交付的设计参考文档,作为 PRD 阶段的输入。
writing-assistant
写作助手 - 当用户说"我想写XX"、"帮我梳理选题"、"怎么形成框架"、"给我组织思路"时触发。根据观点清晰度自动选择最优路线:清晰观点走"框架→内容",模糊观点走"挖掘→选题→框架→内容"。
weekly-report
帮助用户梳理周报,按照完整逻辑展示工作价值和边界。当用户说"写周报"、"周报"、"梳理周报"、"整理工作"时触发。
vision-exploration
终局愿景探索。用户抛出一个模糊 idea,AI 主导引导,通过"追问价值 → 挖掘动机 → 推导演化 → 画终局"的链路,帮用户看到未来最远的可能性。不设限,不收敛,纯发散。
version-planner
帮助用户把产品需求拆解成渐进式版本规划。当用户说"拆版本"、"版本规划"、"MVP怎么做"、"分阶段实现"时触发。
thought-mining
思维挖掘助手 - 通过对话帮助用户把脑子里的零散想法倒出来、记录下来、整理成文章。覆盖从思维挖掘到成稿的完整流程。
thinking-partner
思考拍档 - 陪你从混沌中理清局面,锁定核心问题,拆解卡点,共创解法,落地行动
req-change-workflow
Standardize requirement/feature changes in an existing codebase (especially Chrome extensions) by turning "改需求/需求变更/调整交互/改功能/重构流程" into a repeatable loop: clarify acceptance criteria, confirm current behavior from code, assess impact/risk, design the new logic, implement with small diffs, run a fixed regression checklist, and update docs/decision log. Use when the user feels the change process is chaotic, when edits tend to sprawl across files, or when changes touch manifest/service worker/OAuth/storage/UI and need reliable verification + rollback planning.
project-map-builder
生成或更新用户指定文件夹的 PROJECT_MAP.md。适用于用户要求目录地图/项目地图/代码仓概览/文件夹级说明/更新已有 PROJECT_MAP.md 的场景。必须先询问要扫描的文件夹范围,禁止默认全仓库扫描;支持单目录或多目录(合并或分别生成)。
product-naming
产品命名协作流程。当用户想给产品/项目/模块起名字时使用。通过"灵魂挖掘 → 约束提取 → 路线发散 → 方向选择 → 竞品验证 → 最终确认"的结构化流程,从模糊想法产出有品牌生命力的名字,避免拍脑袋起名。
priority-judge
优先级判断助手 - 帮用户从混沌的待办事项中判断优先级,确定现在该做什么。当用户说"我有很多事要做"、"帮我理一下"、"排个优先级"、"今天该做什么"时触发。
prd-doc-writer
Write and iteratively refine PRD/需求文档 with a story-driven structure and strict staged confirmations (journey map alignment, per-story single-point confirmation, final generation gate). Use when the user asks to 梳理/撰写/完善 PRD、需求文档、用户故事、验收标准,并希望用 ASCII 线框图与 Mermaid(流程图/状态图/时序图)来减少歧义、共同完成文档。