
Ui Design
Run a five-step UI change workflow—confirm current layout with ASCII, offer 2–3 ASCII options, then minimal code edits and small tweaks.
Install
npx skills add https://github.com/yunshu0909/yunshu_skillshub --skill ui-designWhat is this skill?
- 5-step flow: locate issue → propose 2–3 ASCII options → user picks → minimal code change → fine-tune
- Hard gate: read code and ASCII-describe current UI before asking desired end state
- Each option requires ASCII layout diagram plus one-sentence rationale; never only text
- Fine-tune step handles small concrete tweaks without restarting full option selection
- Core rules: no guesswork, no drive-by refactors, one change target per iteration
Adoption & trust: 1 installs on skills.sh; 658 GitHub stars; 2/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
Recommended Skills
Journey fit
Incremental layout and style edits happen during Build when the product UI already exists and needs aligned iteration without rework. Frontend subphase covers spacing, color, and component placement changes driven by screenshots and code reading.
Common Questions / FAQ
Is Ui Design safe to install?
skills.sh reports 2 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.
SKILL.md
READMESKILL.md - Ui Design
用户要求修改页面的 UI 样式(布局、间距、颜色、组件搭配等视觉层面的调整)。通过结构化的协作流程完成修改,确保每一步都对齐目标,不做无效猜测。 ## 核心原则 - **不猜,不抢跑** — 没有对齐目标之前,绝不动代码 - **截图是第一语言** — 主动要求用户提供截图,用截图定位问题 - **ASCII 画方案** — 布局方案用 ASCII 画出来,文字描述容易产生歧义 - **每次只改一个点** — 不要一次改多个地方,逐步逼近目标 ## 工作流程 ### 第 1 步:定位问题 用户说想改某个地方时,先做两件事: 1. **读代码** — 读取相关文件,理解当前实现 2. **描述现状** — 用 ASCII 画出当前布局,向用户确认:"我看到的是这样,对吗?" ``` 示例: ┌─────────────────────────────────────────────┐ │ 📈 标题 [🔄] │ │ 副标题说明文字 │ │ 🔍 [搜索框... ] │ ├─────────────────────────────────────────────┤ ``` **禁止**:跳过这一步直接问"你想改成什么样"。必须先让用户确认你理解了现状。 ### 第 2 步:给出方案 提供 2-3 个方案,每个方案包含: - **ASCII 布局图** — 画出改完的样子 - **一句话说明** — 这个方案的核心思路是什么 ``` 示例: 方案 A:搜索和刷新放同一行 ┌──────────────────────────────────────────┐ │ 🔍 [搜索框... ] [🔄] │ └──────────────────────────────────────────┘ 方案 B:刷新挪到标题行 ┌──────────────────────────────────────────┐ │ 📈 标题 [🔄] │ │ 🔍 [搜索框... ] │ └──────────────────────────────────────────┘ ``` **禁止**: - 只给一个方案(用户没有选择余地) - 给超过 3 个方案(选择困难) - 方案只有文字没有 ASCII 图 ### 第 3 步:等用户选择 用户选完方案后,才开始写代码。 **禁止**:用户还没选就开始改代码。 ### 第 4 步:改代码 执行最小改动,只改用户选定方案涉及的部分。 **禁止**:顺手改其他地方、优化代码结构、加注释。 ### 第 5 步:微调 改完后让用户看效果。用户可能会提出微调: - "加个边框" - "颜色太深" - "间距再大一点" 微调是**具体的、小的修改**,直接执行,不需要再走方案选择流程。 如果用户的反馈不够具体(比如"感觉不对"),主动追问: - "是大小的问题、颜色的问题、还是位置的问题?" - "和旁边哪个元素搭配起来不协调?" ## 沟通规范 ### 用户应该提供的 | 信息 | 说明 | |---|---| | 截图 | 标注出想改的区域 | | 问题描述 | "这两个元素搭配不协调"、"间距太大" | | 选择方案 | 从给出的方案中选一个 | ### AI 应该做的 | 阶段 | 输出 | |---|---| | 定位 | ASCII 现状图 | | 方案 | 2-3 个 ASCII 方案图 + 一句话说明 | | 改码 | 最小改动,只改选定方案 | | 微调 | 直接执行具体调整 | ### AI 绝不应该做的 - 用户说"改布局"就直接猜想法然后改代码 - 一次给出大段代码重构 - 微调阶段还在给多个方案让用户选 - 顺手改用户没提到的地方