design-style-picker
- 作者仓库星标 0
- 作者更新于 2026年8月24日 15:33
- 作者仓库 claude-code-skills
Design Style Picker
Purpose
Use this skill to turn vague taste into concrete visual choices. The goal is not to guess one final design; it is to generate a structured set of options that exposes the user's taste boundary quickly.
Core Rule
Do not ask the user to describe an abstract style if they already said they cannot. Generate comparable visual evidence, let them pick, then implement from the selected references.
Workflow
Restate The Real Target
- Say what the user is actually choosing: design-system style, business app surface, landing page, deck, component library, etc.
- Separate the primary artifact from validation samples. If the task is a design system, business screens are optional validation samples, not the main deliverable.
- Preserve any existing UI, assets, tokens, layout, brand cues, and domain context unless the user explicitly asks to discard them.
Collect Existing Assets First
- Inspect the current rendered UI or screenshots.
- Read design tokens, CSS variables, component names, key images, brand/domain references, and existing screenshots.
- Treat current assets as the starting vocabulary. Do not generate unrelated "fresh" concepts over them.
Generate A Matrix, Not Minor Variants
- Use at least two axes when taste is unclear:
- Vertical ladder: one dimension changes by large steps, such as color intensity 20/35/50/65/80.
- Horizontal directions: different organization strategies, such as data-driven color, brand spine, warm product imagery, scenario modules, or governance-led layout.
- Make options visibly different. If two images look like siblings, regenerate one with a clearer contrast.
- Prefer batch generation. The user is waiting for selection, not watching one slow image at a time.
- Use at least two axes when taste is unclear:
Use Color As A System
- "Less colorful" does not mean black-and-white. It usually means fewer competing focal points.
- Keep the product palette alive, but assign color roles:
- Broad zones and section bands for architecture.
- Data visualization and evidence systems for multi-color semantics.
- Brand/risk colors for rare, high-signal emphasis.
- Neutral components for routine UI.
- Include explicit upper-bound samples when the user is tuning color: safe, middle, high, and overload boundary.
Review Before Presenting
- Open generated images yourself.
- Mark which are likely too dead, too colorful, too generic, too business-system-like, or closest to the target.
- Present file paths and a short decision note for each useful candidate.
Implement From Selected Images
- Extract principles, not pixels: color roles, layout density, focal hierarchy, component treatment, image use, governance/data placement.
- Fuse selected references explicitly. Example: "Use H02 for color placement and V04 for palette intensity."
- Keep implementation scoped to the existing UI unless the user asks for a new artifact.
- Run rendered visual QA after implementation.
Prompt Pattern
When generating images, include:
This is an evolution of the existing UI/design system, not a replacement.
Preserve these assets: <tokens, imagery, sections, components, brand cues>.
Axis: <vertical ladder or horizontal direction>.
Variant name: <clear label>.
Color/visual rule: <specific budget or organization method>.
Primary focal point: <one thing>.
Avoid: <known rejected styles from the user>.
Lessons To Preserve
- A user saying "not colorful" may mean "no dozens of equal-weight small color chips", not "remove all color".
- A user saying "more weight" may mean visual authority and hierarchy, not dark-mode control room.
- For design-system work, do not replace the system with a business dashboard. Business screens can validate style, but should not become the answer.
- Always create deliberate boundary samples. They make "too much" visible and speed up selection.
- After selection, fuse the chosen references and name what each contributes.
References
- Read
references/selection-playbook.mdwhen running a full style-selection session or when the user gives taste corrections during image exploration.
- 流狐分类
- 设计与多媒体
- 作者声明 Agent
- 未找到明确声明;不据此推断已兼容或已测试
- 静态检查
- 88 / 100 · 启发式扫描,不代表运行安全
- 作者 / 版本 / 许可
- @daymade · 未声明 license
- 流狐 Token 估算
- 低消耗
- 流狐接入估算
- 即装即用
- 是否需要外部 API Key
- 未发现要求
- 检测到的系统要求
- 未声明
- 底层运行要求
- 未声明
- 检测到的文件与系统行为
-
- 只读
- 允许写入 / 修改
- 检测到的网络行为
- 仅限本地
- 安装命令数
- 无(仅作为资料)
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
作者没有在当前 SKILL.md 中定义固定输出样例。 Use this skill to turn vague taste into concrete visual choices. The goal is not to guess one final design; it is to generate a structured set of options that exposes the user's taste boundary quickly.
Do not ask the user to describe an abstract style if they already said they cannot. Generate comparable visual evidence, let them pick, then implement from the selected references.
Restate The Real Target Say what the user is actually choosing: design-system style, business app surface, landing page, deck, component library, etc. Separate the primary artifact from validation samples. If the task is a design system, business screens are…
When generating images, include:
A user saying "not colorful" may mean "no dozens of equal-weight small color chips", not "remove all color". A user saying "more weight" may mean visual authority and hierarchy, not dark-mode control room. For design-system work, do not replace the system with…
Read references/selection-playbook.md when running a full style-selection session or when the user gives taste corrections during image exploration.
# Design Style Picker
## Purpose
Use this skill to turn vague taste into concrete visual choices. The goal is not to guess one final design; it is to generate a structured set of options that exposes the user's taste boundary quickly.
## Core Rule
Do not ask the user to describe an abstract style if they already said they cannot. Generate comparable visual evidence, let them pick, then implement from the selected references.
## Workflow
1. **Restate The Real Target**
- Say what the user is actually choosing: design-system style, business app surface, landing page, deck, component library, etc.
- Separate the primary artifact from validation samples. If the task is a design system, business screens are optional validation samples, not the main deliverable.
- Preserve any existing UI, assets, tokens, layout, brand cues, and domain context unless the user explicitly asks to discard them.
2. **Collect Existing Assets First**
- Inspect the current rendered UI or screenshots.
- Read design tokens, CSS variables, component names, key images, brand/domain references, and existing screenshots.
- Treat current assets as the starting vocabulary. Do not generate unrelated "fresh" concepts over them.
3. **Generate A Matrix, Not Minor Variants**
- Use at least two axes when taste is unclear:
- Vertical ladder: one dimension changes by large steps, such as color intensity 20/35/50/65/80.
- Horizontal directions: different organization strategies, such as data-driven color, brand spine, warm product imagery, scenario modules, or governance-led layout.
- Make options visibly different. If two images look like siblings, regenerate one with a clearer contrast.
… 作者原文负责流程事实;流狐只索引当前章节、要点、文件与命令。
章节 -> Purpose → Core Rule → Workflow → Prompt Pattern → Lessons To Preserve → References
要点 -> Restate The Real Target · Collect Existing Assets First · Generate A Matrix, Not Minor Variants · Use Color As A System · Review Before Presenting · Implement From Selected Images
文件/命令 -> references/selection-playbook.md · brand/domain · 20/35/50/65/80. · Brand/risk · governance/data · UI/design · Color/visual
内容 SHA-256 -> 5ad70282cbcc
方法与流程
适用与边界
原文中的明确线索
references/selection-playbook.md、brand/domain、20/35/50/65/80.、Brand/risk、governance/data、UI/design、Color/visual