prd

STARTER_CHARACTER = 📋

PRD 生成器

生成一份 PRD。

工作内容

1. 接收用户提供的功能描述
2. 阅读代码仓库，为规格说明提供依据
3. 提出澄清问题（提供字母选项）；视需要进行多轮迭代
4. 根据回答生成结构化 PRD
5. 保存到 .llmtmp/prd.md（如果提供了 slug，则保存到 .llmtmp/prd-<slug>.md）

注意

不要开始实现，只需创建 PRD。

Slug 生成

如果用户提供了 slug，就使用它。否则，根据功能标题生成：全部小写，仅使用字母数字和连字符，最长 20 个字符。

第 1 步：收集上下文

提问前先阅读代码仓库。缺乏信息的问题会浪费用户的时间，也会导致规格说明含糊。按以下顺序查阅资料：

1. README.md（项目根目录）
2. 如果存在，则查阅 CLAUDE.md（项目根目录）
3. .llmdocs/ 中的所有 .md 文件
4. 用户在提示词中指定的任何文件
5. 与功能相关的代码：针对功能描述中提及的术语，使用 grep、Glob 或 Serena 符号搜索（例如，对于身份验证功能，查找身份验证中间件、JWT 验证器、身份映射代码）

阅读足够多的内容，了解现有内容、采用的惯例、代码仓库使用的术语，以及该功能会涉及哪些文件。这样，问题才能针对实际代码库，而不是假设情况。

第 2 步：澄清问题

仅在初始提示不够明确时提出关键问题。重点关注：

• 问题／目标：要解决什么问题？
• 核心功能：关键操作有哪些？
• 范围／边界：不应包含什么？
• 成功标准：如何判断已完成？

后续轮次

多轮提问是预期情况，并非例外。第一轮回答后，进一步阅读代码或用户的回复通常会发现新的决策点。只要有尚未解决的决策，或用户提出异议，就应再进行一轮带字母选项的问题。PRD 应反映对话的最终结果，而非第一个答案。

用户也可能要求 CLANKER 修改 PRD 草稿；将其视为又一轮后续沟通。

问题格式如下

1. What is the primary goal of this feature?
   A. Improve user onboarding experience
   B. Increase user retention
   C. Reduce support burden
   D. Other: [please specify]

2. Who is the target user?
   A. New users only
   B. Existing users only
   C. All users
   D. Admin users only

3. What is the scope?
   A. Minimal viable version
   B. Full-featured implementation
   C. Just the backend/API
   D. Just the UI

这样，用户可以用“1A、2C、3B”快速回复并推进迭代。选项应缩进。

第 3 步：PRD 结构

PRD 面向初级开发者或 AI Agent。内容应明确、不使用行话，包含编号要求和具体示例。

生成 PRD 时应包含以下章节：

1. 简介／概述

简要描述该功能及其解决的问题。

2. 目标

具体、可衡量的目标（项目符号列表）。

3. 用户故事

每个故事都需要：

• 标题：简短且具有描述性的名称
• 描述：“[用户角色] 需要 [功能]，以便 [收益]”，其中 [用户角色] 是受益者（平台运营人员、终端用户、管理员），绝不能是实现者
• 验收标准：可验证的功能断言，描述该故事本身的行为

每个故事的范围应足够小，可在一次专注的工作时段内完成实现。

格式：

### US-001: [Title]

**Description:** A [user role] needs [feature] so that [benefit].

**Acceptance Criteria:**

- [ ] Specific verifiable functional criterion
- [ ] Another verifiable functional criterion
- [ ] **[UI stories only]** Observable outcome verified in a browser session

注意

验收标准规则：

• 应是可验证的功能断言，描述该故事本身的行为。“正常工作”是不合格的。“删除前显示确认对话框”是合格的。
• [用户角色] 是受益者（平台运营人员、终端用户、管理员）。绝不能是实现者、CLANKER、“我们”、“开发者”或“AI”。
• 代码质量要求（lint 通过、测试通过、类型检查通过）是交付基线，不是功能标准。不要将其写入验收标准。
• 每项标准都应独立完整。不要跨故事引用（例如“在本次运行中通过 US-011 扩大”）。将执行顺序移至“技术考量”部分。
• UI 标准应说明可观察到的结果（“浏览器会话显示强制重新身份验证界面”），而不是说明验证工具。

4. 非目标（不在范围内）

说明此功能不会包含什么。这对控制范围至关重要。

5. 设计考量

UI/UX 要求、原型链接、可复用的现有组件。不适用时填写“n/a”。

6. 技术考量

约束、依赖项、集成点、性能要求。不适用时填写“n/a”。

7. 成功指标

如何衡量成功？例如：

• “将完成 X 所需的时间缩短 50%”
• “将转化率提高 10%”

8. 待解决问题

尚未解决的问题。最多列出 3 个。待解决问题是阻碍事项，而非可了解可不了解的信息。

输出

• 格式：Markdown（.md）
• 位置：.llmtmp/
• 文件名：prd.md 或 prd-<slug>.md

示例

请参阅 references/example-prd.md 中的完整示例。

检查清单

保存 PRD 前：

• 使用字母选项提出了澄清问题
• 已纳入用户的回答
• 用户故事简短，且包含可验证的验收标准
• “非目标”部分明确界定了范围
• “待解决问题”最多包含 3 项
• 已保存到 .llmtmp/prd.md（或 .llmtmp/prd-<slug>.md）

如果任何一项未通过，请修正并重新验证后再保存。