brainstorm-prd

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

brainstorm-prd — Interview and draft a PRD

brainstorm-prd — 访谈并起草PRD

Interview the user about a feature or large change, then write a PRD that captures the outcome. The PRD is a product artifact. It describes the problem, the users, what "done" looks like, and the decisions made.

通过访谈用户了解某项功能或重大变更的信息，然后撰写一份PRD记录访谈成果。PRD是一种产品工件，用于描述问题、目标用户、完成状态定义以及已做出的决策。

Phase 1 — Read the project context

阶段1 — 阅读项目背景

Read the project first. Keep this brief.

Read
```
CLAUDE.md
```
and any nested ones, if present.
Skim the README,
```
docs/
```
, and main entry points to learn the project type.
If the idea overlaps, replaces, or extends existing code, invoke the
```
feature-dev:code-explorer
```
agent strictly to inform your questions.

先阅读项目相关内容，此步骤需简洁。

阅读
```
CLAUDE.md
```
及其中的嵌套文档（若存在）。
浏览README、
```
docs/
```
目录及主入口文件，了解项目类型。
如果该想法与现有代码重叠、替代或扩展现有功能，需严格调用
```
feature-dev:code-explorer
```
工具来辅助设计问题。

Phase 2 — Interview the user

阶段2 — 访谈用户

Reach shared understanding of what to build and why.

达成对需构建内容及原因的共识。

Start

开始

If the user gave the feature idea, acknowledge it in one line and ask your first question. If not, ask an open question: what feature or change do they want to think through.

如果用户已经给出功能想法，用一句话确认后提出第一个问题。如果没有，提出开放式问题：他们想要探讨哪项功能或变更。

How to ask questions

提问方式

Ask one question at a time, forked on the previous answer. If they said "B2B", do not ask consumer-app questions. If they said "this replaces X", do not treat it as greenfield.
Ask non-obvious questions. Go after edge cases, tradeoffs, failure modes, conflicts between users, what the system must not do, and what "good enough" means.
Cover these angles by the end: the problem, who suffers from it today, what success looks like to the user, the interaction model, edge cases and failure modes, scope boundaries, dependencies, and risks.
Open early, converge late. Save small-enumerable forks for later, once the space is explored.

每次只提一个问题，基于用户上一个回答展开。如果用户提到“B2B”，就不要问面向消费类应用的问题；如果用户提到“这将替代X”，就不要将其视为全新项目。
提出非显而易见的问题。关注边缘场景、权衡取舍、失败模式、用户间的冲突、系统绝对不能做的事，以及“足够好”的定义。
最终需覆盖以下维度：问题是什么、当前受影响的用户群体、用户眼中的成功标准、交互模式、边缘场景与失败模式、范围边界、依赖关系以及风险。
前期开放式提问，后期逐步收敛。先探索整体方向，再处理细分的可枚举分支。

How to format questions

问题格式

Free text is the default. Ask in plain prose. Let the user answer in their own words.
Use
```
AskUserQuestion
```
only for genuine small-enumerable forks: 2–4 discrete categorical answers, such as
```
sync
```
vs
```
async
```
or
```
in scope
```
vs
```
out of scope
```
. If you cannot enumerate the options cleanly, ask in free text.
Do not label any option "Recommended". A label anchors the user and suppresses answers you did not list.
Express your view in the question, not as a tool label. Frame it as a hypothesis the user can reject: "My instinct is real-time matters more here because the feedback loop makes the feature useful — but batch is simpler. Which direction feels right, and why?"

默认使用自由文本提问。用平实的语言提问，让用户用自己的话回答。
仅当存在明确的2-4个离散分类选项时，才使用
```
AskUserQuestion
```
，比如
```
sync
```
与
```
async
```
、
```
在范围内
```
与
```
在范围外
```
。如果无法清晰枚举选项，就用自由文本提问。
不要给任何选项标注“推荐”。标注会引导用户，限制他们给出未列出的答案。
在问题中表达你的观点，但不要用工具标签。将其表述为用户可以拒绝的假设：“我的直觉是实时性在这里更重要，因为反馈循环能让功能更实用——但批量处理更简单。你觉得哪个方向更合适，原因是什么？”

What to avoid asking

避免提问的内容

These belong in a tech spec, not a PRD. Do not ask about them. If the user goes there, redirect.

Class names, function names, module layout
Specific libraries, frameworks, or databases (unless the product requirement constrains this — e.g. "must work offline")
File paths, routes, API endpoint naming
Implementation algorithms or data structures

To redirect, say: "That's a great question for a tech spec — for the PRD I want to capture the product need behind it."

这些内容属于技术规格文档范畴，而非PRD。不要询问此类问题，如果用户提及，需引导回到PRD的核心内容。

类名、函数名、模块布局
特定的库、框架或数据库（除非产品需求对此有约束——例如“必须支持离线使用”）
文件路径、路由、API端点命名
实现算法或数据结构

引导话术示例：“这是一个适合技术规格文档的好问题——在PRD中，我需要捕捉背后的产品需求。”

When to stop

停止访谈的时机

Stop when you could write a PRD a teammate reads cold and understands:

What problem this solves and why it matters
What is in scope and what is out
User stories with acceptance criteria
The tradeoffs considered and the decisions made
The main risks and edge cases

If unsure, ask one more question about the thinnest area. Do not drag the interview out once the picture is clear.

当你可以写出一份让同事无需额外背景就能理解的PRD时，停止访谈：

该功能解决的问题及其重要性
包含与排除的范围
带有验收标准的用户故事
已考虑的权衡取舍及做出的决策
主要风险与边缘场景

如果不确定，可以针对最薄弱的环节再提一个问题。一旦整体情况清晰，就不要拖延访谈。

Phase 3 — Recap and confirm

阶段3 — 回顾与确认

Before writing the file, show the user a recap in chat:

A one-paragraph summary of the feature.
The proposed PRD outline: section headings with 1–2 bullets each.
The proposed filename: a kebab-cased slug, e.g.
```
docs/prd/user-onboarding-revamp.md
```
.

Ask whether this matches, or if anything needs to change. Make corrections. If a correction reveals a real gap, return to Phase 2 for a few more questions.

在撰写文件前，在聊天中向用户展示回顾内容：

一段关于该功能的总结性文字。
拟议的PRD大纲：每个章节标题附带1-2个要点。
拟议的文件名：短横线分隔的小写名称，例如
```
docs/prd/user-onboarding-revamp.md
```
。

询问用户内容是否匹配，是否需要修改。根据反馈调整。如果调整后发现存在实际信息缺口，返回阶段2补充几个问题。

Phase 4 — Write the PRD

阶段4 — 撰写PRD

Write the file after the user confirms.

在用户确认后撰写文件。

File handling

文件处理

Target path:
```
docs/prd/<kebab-feature-name>.md
```
relative to the project root.
Create
```
docs/prd/
```
silently if it does not exist.
If the target file already exists, stop and ask the user to:
1. Overwrite
2. Append as a revision under a dated heading
3. Write to a different filename (ask for the new slug)

目标路径：相对于项目根目录的
```
docs/prd/<kebab-feature-name>.md
```
。
如果
```
docs/prd/
```
目录不存在，自动创建。
如果目标文件已存在，停止操作并询问用户选择：
1. 覆盖原文件
2. 在带日期的标题下追加修订内容
3. 写入新的文件名（询问新的短横线分隔名称）

PRD template

PRD模板

The template is

references/prd-template.md

. Read it before writing. Use it as the exact output structure.

Rules for filling it in:

Fill every section from the interview. If a section has nothing, write
```
_None identified during interview._
```
.
The
```
## Target users
```
section is conditional. Include it only when the interview surfaced more than one distinct user type that interacts with the feature differently. With one user type, fold it into Overview and omit the section.
The Decisions log has a threshold. Log only forks where a real alternative was considered and rejected. Skip cosmetic choices. If you cannot name a real alternative, it is not a decision.

模板文件为

references/prd-template.md

。撰写前先阅读该模板，并严格按照其结构输出内容。

填写规则：

利用访谈内容填充每个章节。如果某个章节没有内容，填写
```
_访谈期间未识别到相关内容。_
```
。
```
## 目标用户
```
章节为可选。仅当访谈中发现存在多种不同的用户类型，且他们与该功能的交互方式不同时，才包含此章节。如果只有一种用户类型，将相关内容合并到概述中并省略该章节。
决策日志有记录阈值。仅记录存在真实备选方案且已做出取舍的分支。忽略无关紧要的选择。如果无法说出真实的备选方案，则不视为决策。

Writing style for the PRD

PRD撰写风格

Write the PRD in ASD-STE100 (Simplified Technical English). One idea per sentence. Keep sentences under ~20 words. Use present tense and active voice. Use one word per meaning. No idioms, no metaphors. This applies to the document only; keep the interview conversational.
Write in the user's voice and domain. Keep their nouns exactly. If they said "workspace", do not write "tenant". ASD-STE100 governs sentence structure, not their vocabulary.
Be specific. "Users should get clear feedback" is weak. "When a sync fails, show which records were affected and why" is useful.
Make acceptance criteria testable from the user's perspective. Given / When / Then is a fine default; plain bullets are fine when they read better.
Keep the PRD short.

使用ASD-STE100（简化技术英语）撰写PRD。每句表达一个想法，句子长度控制在约20词以内。使用现在时和主动语态，一词一意。不使用习语、隐喻。此规则仅适用于PRD文档；访谈过程中保持对话式风格。
使用用户的语言和领域术语。严格保留用户使用的名词。如果用户说“workspace”，不要写成“tenant”。ASD-STE100仅规范句子结构，不限制用户的词汇选择。
内容要具体。*“用户应获得清晰的反馈”表述模糊，“同步失败时，显示受影响的记录及原因”*才有用。
验收标准需从用户视角可测试。Given/When/Then是不错的默认格式；当纯要点表述更清晰时，也可使用纯要点。
保持PRD简洁。

Phase 5 — Hand off

阶段5 — 交付

After writing the file:

Tell the user the path where the PRD was saved.
Summarize in 2–3 bullets: what was decided, what is still open, and a suggested next step (e.g. "to plan implementation, the
feature-dev:code-architect
agent is built for that").

Do not implement anything. This skill ends at the PRD.

文件撰写完成后：

告知用户PRD的保存路径。
用2-3个要点总结：已做出的决策、仍未确定的内容，以及建议的下一步行动（例如*“如需规划实现方案，
```
feature-dev:code-architect
```
工具专为该场景设计”*）。

不要进行任何实现工作。该工具的任务在PRD完成后即结束。