关于 spec-generator
将产品想法及相关材料整理成开发团队可执行的产品规格说明。它会收集缺失背景、明确假设,并按结构化格式编写产品规格,而非功能或 API 规格。
主要功能
- 01解读笔记、草图和截图
- 02针对关键缺口集中提问
- 03明确假设与默认方案
- 04编写完整的产品规格说明
- 05将结果保存为 Markdown 文件
适用场景
- 01将初步产品想法整理成团队简报
- 02把草图和笔记转化为规格说明
- 03在开发规划前澄清未知事项
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ unlearndev/ skills --skill spec-generator安装后在 Claude Code 中输入/spec-generator确认已加载。
详细介绍
规格生成技能
将一个模糊的产品想法(可能附有草图、截图、笔记或其他文档)转化为清晰、结构完善的产品规格文档,供开发团队据此开展工作。
输出始终是产品规格。这涵盖面向客户的产品、内部工具和面向员工的系统——它们都属于产品。绝不生成功能规格、API 规格或集成规格。
优秀成果的标准
优秀的规格应当:
- 简洁而完整——不冗长,也无遗漏
- 使用通俗易懂的语言,不用企业套话
- 必要时明确表达建议(例如建议合理的默认技术栈或行为),同时指出团队仍需决定的事项
- 揭示隐含假设,并将其明确写出
- 让人感觉是由一位深思熟虑、考虑周全的资深产品经理或技术负责人撰写的
流程
第 1 步:收集并理解输入
盘点用户提供的所有内容:
- 文字描述——哪怕只有一句话,也足以开始
- 上传的文件——全部阅读:笔记、现有文档、数据模型、线框图、截图、原型图
- 图片——仔细查看,提取其中隐含的功能、流程和约束
起草前,先审阅用户提供的所有内容,并找出会显著影响规格的缺口。如果用户没有提供预期的技术栈,务必询问——它可能会影响项目方向和功能。对于其他无法根据现有输入合理推断的问题,也要询问;不要询问已经明确,或可以通过合理默认值决定的事项。问题应简洁,并一次性归类提出,不要分多轮询问。
第 2 步:起草规格
使用下方模板。根据需要调整章节——并非每份规格都需要所有章节。自行判断。省略不适用的章节,不要用占位文本填充。
规格模板
# [Product Name] — Specification
> **Context:** [1–2 sentences on why this is being built and what informed this spec — e.g. team discussions, user research, a UI sketch.]
## Overview
[2–4 sentences. What is this? Who uses it? What problem does it solve? What is it NOT?]
---
## Goals
- [Concrete, measurable goal]
- [Another goal]
- [Keep this list short — 3–6 items]
---
## User Roles
### [Role Name]
- [What they can do]
- [What they cannot do / what they see or don't see]
- [How they authenticate or access the system]
[Repeat for each role]
---
## Core Features
### 1. [Feature Name]
[Description. Be specific — what does the user do, what happens, what are the constraints? Mention edge cases where relevant.]
### 2. [Feature Name]
[...]
[Continue for all major features, numbered.]
---
## Technical Stack
- **[Layer]** — [Technology]
- **[Layer]** — [Technology]
写作指南
具体明确,不要含糊。 不要写“用户可以管理自己的账户”,而应写“用户可以更新电子邮箱地址,并通过发送到注册邮箱的链接重置密码”。
用合理的默认值消除歧义。 如果用户没有指定某项内容(例如分页条数限制),就选一个合理的值并注明。不要留空。
区分面向客户的内容与内部内容。 如果有两类受众(例如终端用户和员工),应在结构上清晰区分——分设章节,并分别描述角色。
标明隐含约束。 如果输入内容暗示了某种约束(例如草图中没有搜索栏 → 搜索可能不在范围内),请在相关功能描述中明确指出。
技术栈为可选项。 仅当技术栈已知或有充分依据可推断时才纳入。如果未知,则完全省略该章节。建议技术时,先进行网页搜索,确保推荐仍然最新且是当前的标准选择——避免使用已被替代或已不再普遍使用的包或库。
绝不添加“范围外”章节。 规格模板是唯一可用的结构——不要添加模板之外的任何章节。
输出格式
将规格生成为 .md 文件,并保存到 /mnt/user-data/outputs/spec.md。使用 present_files 向用户展示该文件。
展示文件后,提供简短摘要(最多 1–2 句),说明你所作的任何重要假设。