Skill: balancegsr/skill-creator-design (version 1.2.1)

--- name: skill-creator-design description: > 生成定制化的设计项目 Skill（含 SKILL.md + references/），为用户的设计过程提供从需求定义到 交付的持续引导。触发场景：用户表达想做设计相关工作（"我想设计 X""做个 X 的方案" "帮我设计一个 X""出个设计""改版 X""重新做一下 X""想想 X 怎么做""design X" "redesign X"），或要求生成设计规划、设计 skill（"创建设计项目""generate a design skill" "帮我规划一下这个设计"）。涵盖产品设计、交互设计、体验设计、信息架构、视觉方案等。 安装本 skill 即表明用户倾向于系统化设计管理——遇到设计意图时优先触发，而非直接进入 即时头脑风暴。 tools: [write, bash] --- # Skill Creator: Design 根据用户的设计需求，生成一个定制化的设计项目 Skill。生成物是一个独立的 SKILL.md（+ references/）， 安装后能在用户的设计项目中持续引导从需求定义到交付的全过程。 本 Creator 执行一次性的信息收集→生成→交付流程，不是一个持续运行的助手。 --- ## Phase 1: 信息收集（Intake） 目标：用 2-3 轮自然对话收集生成所需的关键信息。像一个有经验的设计顾问在了解需求，不像在填表。 ### 第一轮：主题 + 目标 被触发后，先用一句话说明自己做什么，然后问最核心的两个变量： > "我可以帮你生成一个设计项目 skill——它会在你的设计过程中引导需求定义、调研、方案设计、评审和交付。 > 先告诉我：你想设计什么？最终希望达到什么效果？" 这两个信息通常是用户触发 Creator 时脑子里最清晰的，开口门槛最低。 ### 第二轮：范围/背景 + 约束条件 + 条件追问 先对用户第一轮回答做简短回应（表示理解，让对话有来有回），然后补收： > "[对用户设计目标的简短回应]。再告诉我两件事：这个设计的范围是什么——是从零做一个新产品，还是在现有产品上做功能迭代？有什么约束条件需要提前考虑的——比如技术限制、预算、时间、特定平台等？" 条件追问（仅在信息不充分时触发）： | 情况 | 追问方式 | |---|---| | 目标不可衡量（如"做一个好的设计"） | "设计完成后，怎么判断它是成功的？有没有具体的指标或标准？" | | 范围不清（不知道是新产品还是功能级） | "这是一个全新的产品，还是已有产品的功能/迭代？" | | 约束条件完全空白 | "有什么限制需要提前考虑的吗？比如技术、预算、时间？没有的话我先假设没有硬性约束。" | | 第一轮已自发带出了范围或约束 | 只补缺失的，不重复问 | | 所有必答信息已充分 | 直接进入汇总确认 | **可选变量**——不主动问，从对话中捕获： - 目标受众/用户画像（如用户说"这个主要是给运营团队用的"）→ 覆盖默认的从主题推断 - 交付物偏好（如用户说"最后我需要一份 PRD"）→ 覆盖默认的领域推荐 - 如用户未提及，使用默认值即可 ### 第三轮：汇总确认 结构化展示收集到的信息 + 模式推荐： ``` 我理解到的信息： - 设计主题：[主题] - 设计目标：[目标，确保是可衡量表述] - 设计范围：[0→1 新产品 / 功能级 / 迭代级] - 约束条件：[约束描述，或"暂无硬性约束"] - 推荐模式：[轻量/完整] └ 轻量模式默认快速推进，遇到高影响决策自动加深；完整模式默认深入系统，明确简单的环节自动精简。 有需要修正的吗？确认后我开始生成 skill 预览。 ``` 模式推荐规则： - 单功能设计 / 小型迭代 → 推荐轻量模式（范围小，深度调研和系统评审的 ROI 低） - 新产品 0→1 / 大型功能 → 推荐完整模式（范围大，需要充分的调研、系统评审和完整决策记录） - 不确定 → 推荐完整模式（宁多勿少，用户可以跳步） - 用户可覆盖推荐，尊重选择 **信息充分性门槛**——进入汇总确认前检查： - ✅ 主题明确（能用来做文件命名和领域判断） - ✅ 目标有方向（能回答"设计完成后想达到什么效果"） - ✅ 范围有定位（新产品 / 功能 / 迭代，量级层面） - ✅ 约束已知或确认无约束 不满足时的兜底：用合理假设填充，在汇总中**显式标注**哪些是假设让用户确认。例如： > "你没提到约束条件，我先假设没有硬性的技术或预算限制。如果有，告诉我我会调整设计引导的侧重。" --- ## Phase 2: 生成与预览（Generate & Preview） 用户确认汇总后，进入生成流程。 ### 变量准备 从收集到的信息中提取生成所需的变量： | 变量 | 来源 | 处理方式 | |---|---|---| | `topic` | 用户提供的设计主题 | 直接使用 | | `topic_slug` | 从 topic 派生 | 转为适合文件命名和 name 字段的格式（小写、下划线、无空格，如 "user_onboarding"） | | `goal` | 用户提供的设计目标 | 确保是可衡量表述 | | `scope` | 用户提供的设计范围/背景 | 直接使用 | | `constraints` | 用户提供的约束条件 | 直接使用，或"暂无硬性约束" | | `mode` | 用户确认的模式 | "轻量" 或 "完整" | | `target_audience_override` | 可选，用户提到的目标受众 | 如未提供，留空（清除占位符） | | `deliverable_override` | 可选，用户提到的交付物偏好 | 如未提供，留空（清除占位符） | | `lang` | 用户对话使用的语言 | 生成物使用相同语言 | | `project_dir` | 从 topic_slug 派生 | `design_` + topic_slug + `/`（如 `design_user_onboarding/`），项目文件的存放目录 | | `generated_by` | Creator 版本标识 | 固定值 `skill_creator_design v1.2.0` | ### 生成逻辑 1. 根据 `mode` 选择对应的骨架模板： - 轻量模式 → 读取 `references/templates/skill/lite.md` - 完整模式 → 读取 `references/templates/skill/full.md` 2. 用收集到的变量替换模板中的占位符（`{{topic}}`、`{{goal}}` 等） 3. 处理可选变量的条件注入： - `target_audience_override`：如用户提供了受众信息，在模板的 `{{target_audience_override}}` 位置插入一行，如 `- 目标受众：运营团队（非技术背景）` - `deliverable_override`：如用户提供了交付物偏好，在模板的 `{{deliverable_override}}` 位置插入说明，如"\n- 注意：本项目用户指定交付物为技术方案文档，输出格式以此为准" - 如未提供，清除占位符（不留空行） 4. 准备 references/ 文件： - 两种模式都需要：读取 `references/templates/guides/review_checklist.md` → 生成 `review_checklist.md` - 两种模式都需要：根据模式选择对应的总结指南模板 - 轻量模式 → 读取 `references/templates/guides/summary_guide_lite.md` → 生成 `summary_guide.md` - 完整模式 → 读取 `references/templates/guides/summary_guide_full.md` → 生成 `summary_guide.md` 5. 如果对话语言不是中文，将生成物全文翻译为用户使用的语言，保持结构和格式不变 ### 预览展示 将生成的 SKILL.md 完整内容展示给用户，然后列出 references/ 文件清单： > "此外还会生成以下配套文件： > - references/review_checklist.md — 评审执行清单（三视角 + 质疑角度） > - references/summary_guide.md — 设计总结生成指南（[轻量版/完整版]） > > 你可以提出修改意见，或者确认后我直接生成。" ### 修改处理 | 修改类型 | 判断标准 | 处理方式 | |---|---|---| | 结构性修改 | 影响流程结构或文件管理逻辑（如"不需要调研步骤""加个用户测试环节"） | 调整骨架，重新生成受影响部分，再次完整展示 | | 内容微调 | 不影响结构（如"目标描述改一下""加一条约束"） | 定点修改，展示差异点（"已更新 XX，其他不变。确认？"） | 迭代引导： - 首次："你可以提出修改意见，或者确认后我直接生成。" - 后续："已调整。还有需要改的吗？没有的话我开始生成。" - 不设轮数上限，用户想改就改 ### 占位符对照表 生成时逐项检查，确保每个占位符都已处理： | 占位符 | 来源 | 处理方式 | |---|---|---| | `{{topic}}` | 用户输入的设计主题 | 直接替换 | | `{{topic_slug}}` | 从 topic 派生（小写、下划线、无空格） | 直接替换 | | `{{goal}}` | 用户输入的设计目标（可衡量表述） | 直接替换 | | `{{scope}}` | 用户输入的设计范围/背景 | 直接替换 | | `{{constraints}}` | 用户输入的约束条件 | 直接替换 | | `{{target_audience_override}}` | 可选，用户提到的目标受众 | 有值→插入说明文本；无值→清除占位符（不留空行） | | `{{deliverable_override}}` | 可选，用户提到的交付物偏好 | 有值→插入说明文本；无值→清除占位符（不留空行） | | `{{project_dir}}` | 从 topic_slug 派生 | `design_` + topic_slug + `/`（如 `design_saas_dashboard/`），直接替换 | | `{{generated_by}}` | Creator 版本标识 | 固定值 `skill_creator_design v1.2.0`，直接替换 | > **⚠️ 用户确认生成后，必须进入 Phase 3 执行交付流程。不要直接写文件——Phase 3 包含安装路径探测、交付方式询问等必要步骤。** --- ## Phase 3: 交付（Deliver） 用户确认预览后，询问交付方式： > "你希望我怎么交付？ > 1. **直接安装到当前工作空间** — skill 和项目文件夹都创建在当前工作空间内，立即可用 > 2. **打包为 ZIP** — 生成 zip 文件，你可以自行解压到任意位置或分享给别人" ### 安装路径探测 无论哪种交付方式，都需要先确定 skill 的安装目录前缀。按以下优先级探测： 1. **检查当前 workspace 下的已有 skill 路径**：扫描项目根目录中是否存在 `.claude/skills/`、`.agents/skills/`、`.agent/skills/`、`_agents/skills/`、`_agent/skills/`、`.workbuddy/skills/`、`skills/` 等目录。找到任意一个则沿用该前缀 2. **检查用户根目录（`~/`）下的全局 skill 路径**：扫描是否存在 `~/.claude/skills/`、`~/.openclaw/skills/`、`~/.agents/skills/`、`~/.gemini/antigravity/skills/` 等目录。能找到则说明用户在用对应平台，项目级路径使用对应前缀 3. **兜底默认值**：以上都未找到，使用 `.agents/skills/` 作为默认前缀（Agent Skills 开放标准，兼容性最广） 探测到的前缀记为 `{skill_prefix}`。最终 skill 安装路径为：`{skill_prefix}/design_{{topic_slug}}/SKILL.md` ### 路径1：直接安装到当前工作空间 **执行以下步骤（必须按顺序完成）：** 1. 在当前工作空间内，按探测到的 `{skill_prefix}` 创建 skill 目录：`{skill_prefix}/design_{{topic_slug}}/` 2. 将生成的 SKILL.md 写入该目录 3. 在该目录下创建 `references/` 子目录，写入 review_checklist.md 和 summary_guide.md 4. 在当前工作空间根目录下创建项目文件目录 `design_{{topic_slug}}/`（用于存放设计过程中产生的所有项目文件：设计计划、需求文档、决策记录等） 5. 注意：生成的文件包含大量 Markdown 特殊字符（反引号、方括号、花括号），请使用文件写入工具直接创建文件，避免通过 Shell heredoc（`cat <<EOF`）或重定向写入 6. 通知用户： > "设计项目已安装到当前工作空间： > - skill 位于 `{skill_prefix}/design_{{topic_slug}}/` > - 项目文件将保存在 `design_{{topic_slug}}/` 目录下 > > 直接开始对话就可以使用了——说「开始设计」或「继续设计」即可。" ### 路径2：ZIP 打包 **执行以下步骤（必须按顺序完成）：** 1. 在 /tmp/ 下创建临时目录 `design_{{topic_slug}}_package/` 2. 在临时目录内按探测到的 `{skill_prefix}` 创建 skill 目录结构：`{skill_prefix}/design_{{topic_slug}}/SKILL.md` + `{skill_prefix}/design_{{topic_slug}}/references/` 3. 在临时目录内创建项目文件目录：`design_{{topic_slug}}/`（空目录，首次使用时 skill 会自动初始化） 4. 写入所有文件（同路径1步骤2-3）。同样使用文件写入工具，避免 Shell heredoc 5. 执行 zip 打包：`cd /tmp && zip -r design_{{topic_slug}}.zip design_{{topic_slug}}_package/` 6. 将 zip 文件移动到用户工作目录 7. 清理临时目录 8. 通知用户： > "已打包为 `design_{{topic_slug}}.zip`。 > 解压到你的工作空间根目录后，skill 会自动生效，项目文件将保存在 `design_{{topic_slug}}/` 目录下。" --- ## 附录：生成物质量检查清单 生成前最后过一遍，确保生成物质量： **内容质量** - [ ] frontmatter 的 name 字段不超过 32 字符 - [ ] frontmatter 的 description 包含触发关键词和主题名称 - [ ] frontmatter 的 generated_by 字段已填充版本标识 - [ ] 项目信息区的所有变量（含项目文件目录）都已正确填充 - [ ] 所有占位符已处理（替换或清除），无残留的 `{{...}}` - [ ] 启动协议中的文件读取逻辑与文件管理规范一致 - [ ] 启动协议中包含项目文件目录的定位和创建逻辑 - [ ] 五步设计流程完整（需求定义→调研→方案设计→评审→输出） - [ ] 推进与回退机制完整 - [ ] 即时验证逻辑完整 - [ ] 所有文件命名规则使用了正确的 topic_slug - [ ] 没有任何删除文件的指令 - [ ] 所有项目文件路径相对于项目文件目录 - [ ] 如完整模式：读取优先级四层都定义清晰 - [ ] references/ 文件与 SKILL.md 中的引用一致 **交付验证** - [ ] 交付前已询问用户选择交付方式（直接安装 / ZIP） - [ ] 已执行安装路径探测，确认 `{skill_prefix}` 值 - [ ] skill 目录结构正确：`{skill_prefix}/design_[topic_slug]/SKILL.md` + `references/` - [ ] 项目文件目录已创建：`design_[topic_slug]/` - [ ] 所有文件已成功写入（非空、内容完整）

path: references/templates/guides/summary_guide_full.md
content: # 设计总结生成指南（完整模式）

> 本文件在结项模式触发时加载。指导如何从项目全程的决策记录和产出物中提炼设计总结。

## 什么是设计总结

设计总结不是各步骤产出物的拼接，而是对整个设计过程的**反思性回顾**——提炼出决策逻辑、设计原则和可复用的经验。

好的设计总结应该能让未来的自己（或接手的人）快速理解：为什么方案长这样、关键取舍是什么、哪些是经过验证的决策、哪些仍有风险。

## 生成步骤

### 第一步：加载素材

读取以下文件：
- decisions.md 全文——这是最核心的素材
- requirements.md（需求边界）
- design.md（方案文档）
- review.md（评审记录）
- 如有多次回退记录，特别关注回退的原因和调整后的决策

### 第二步：提炼决策链

从 decisions.md 中梳理关键决策的时间线，识别：
- 哪些决策是一次确定的（高确信度）
- 哪些决策经历了反复（说明这里有真正的权衡）
- 哪些决策触发了回退（说明早期假设被推翻）

重点关注经历反复和触发回退的决策——这些是设计中最有学习价值的部分。

### 第三步：抽象设计原则

从具体决策中抽象出可复用的设计原则。好的设计原则是：
- 从本项目的具体经验中提炼的（不是泛泛的"用户体验很重要"）
- 可以指导未来类似项目的决策
- 包含取舍逻辑（"在 A 和 B 之间，我们选了 A，因为..."）

示例：
- "对于 [这类场景]，先做 [X] 再做 [Y] 比反过来效率更高，因为..."
- "当 [约束条件] 存在时，优先保证 [A] 而不是 [B]"

### 第四步：标注风险和开放问题

从 review.md 的风险清单和 decisions.md 中汇总：
- 已识别并已应对的风险（记录应对方案）
- 已识别但接受的风险（记录接受理由）
- 仍然开放的问题（记录后续需要关注的点）

### 第五步：梳理迭代方向

基于评审发现和开放问题，列出后续可能的迭代方向：
- 短期优化：当前方案中已知可以改进的点
- 中期演进：等数据反馈后可能需要调整的方向
- 长期可能：如果产品/项目继续发展，可能需要的大改动

### 第六步：组装并保存

按以下结构组装设计总结：

```
# [设计主题] 设计总结

## 设计概要
[一段话概括：设计了什么、解决什么问题、核心方案是什么]

## 关键设计决策
### [决策1标题]
- 决策：[选了什么]
- 权衡：[考虑过什么、为什么放弃]
- 验证：[如何验证这个决策是对的]
（列出 3-5 个最重要的决策）

## 设计原则提炼
- [原则1]：[说明 + 来源决策]
- [原则2]：[说明 + 来源决策]

## 风险与开放问题
| 类型 | 内容 | 状态 | 备注 |
|---|---|---|---|
| 已应对 | [风险] | [应对方案] | |
| 已接受 | [风险] | [接受理由] | |
| 开放 | [问题] | 待观察 | [后续关注点] |

## 迭代方向
- 短期：[优化点]
- 中期：[可能的调整方向]
- 长期：[潜在的大改动]
```

保存为 `summary_[topic_slug].md`，通知用户项目完成。


path: references/templates/guides/summary_guide_lite.md
content: # 设计总结生成指南（轻量模式）

> 本文件在结项模式触发时加载。指导如何从项目决策记录和产出物中生成简明设计总结。

## 什么是设计总结

设计总结不是各步骤产出物的拼接，而是对整个设计过程的**反思性回顾**——提炼出关键决策和取舍逻辑。

好的设计总结应该能让未来的自己（或接手的人）快速理解：为什么方案长这样、关键取舍是什么、哪些仍有风险。

## 生成步骤

### 第一步：加载素材

读取以下文件：
- decisions.md 全文——这是最核心的素材
- requirements.md（需求边界）
- design.md（方案文档）
- review.md（评审记录）

### 第二步：提炼决策链

从 decisions.md 中梳理关键决策，识别：
- 哪些决策经历了反复或触发了回退——这些是最有价值的取舍
- 每个关键决策的核心权衡是什么

### 第三步：标注风险和开放问题

从 review.md 的风险清单和 decisions.md 中汇总：
- 已识别并已应对的风险（记录应对方案）
- 仍然开放的问题（记录后续需要关注的点）

### 第四步：组装并保存

按以下结构组装设计总结：

```
# [设计主题] 设计总结

## 设计概要
[一段话概括：设计了什么、解决什么问题、核心方案是什么]

## 关键设计决策
### [决策1标题]
- 决策：[选了什么]
- 权衡：[考虑过什么、为什么放弃]
（列出最重要的决策，通常 2-3 个）

## 风险与开放问题
| 类型 | 内容 | 状态 | 备注 |
|---|---|---|---|
| 已应对 | [风险] | [应对方案] | |
| 开放 | [问题] | 待观察 | [后续关注点] |

## 后续方向
- [可能的优化或迭代方向]
```

保存为 `summary_[topic_slug].md`，通知用户项目完成。


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)