evanflow-prd

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

EvanFlow: PRD

Vocabulary

术语

See

evanflow

meta-skill.

请查看

evanflow

元技能。

When to Use

使用场景

Substantial new feature requiring stakeholder alignment
Pre-sprint scoping
A spec exists in conversation but needs structured form for the team

SKIP when: the work is small enough for

evanflow-brainstorming

→

evanflow-writing-plans

directly.

需要利益相关方对齐的重大新功能
迭代前的范围规划
需求已在沟通中明确，但需要整理成团队可用的结构化形式

跳过场景：任务足够小时，可直接使用

evanflow-brainstorming

→

evanflow-writing-plans

流程。

The Flow

流程步骤

1. Read Context (don't interview)

1. 读取上下文（无需访谈）

The skill name is "to-prd" not "interview-to-prd" for a reason. Synthesize from what's already known:

```
CLAUDE.md
```
for project conventions
```
CONTEXT.md
```
for domain language
```
docs/adr/
```
for prior architectural decisions
Recent commits and
```
docs/stakeholder/*.md
```
for in-flight initiatives
The conversation up to this point

Only ask the user for things you genuinely cannot derive.

本技能名为“to-prd”而非“interview-to-prd”是有原因的。从已知信息中合成内容：

```
CLAUDE.md
```
：项目约定
```
CONTEXT.md
```
：领域术语
```
docs/adr/
```
：过往架构决策记录
近期提交记录和
```
docs/stakeholder/*.md
```
：进行中的倡议
当前为止的对话内容

仅在确实无法从现有信息推导时，才向用户询问。

2. Identify Major Modules

2. 识别核心模块

Sketch the modules to build/modify, emphasizing deep modules (small interface, complex internals). Apply the deletion test to each — does this module earn its existence?

梳理需要构建/修改的模块，重点关注深度模块（接口简洁、内部逻辑复杂）。对每个模块执行删除测试——该模块是否有存在的必要？

3. Validate Architecture

3. 验证架构

Confirm with the user:

The module list (correct, exhaustive, no gaps)
Which components require test coverage (you can't test everything)
Which existing patterns to follow vs. diverge from

向用户确认以下内容：

模块列表是否准确、全面且无遗漏
哪些组件需要测试覆盖（无需覆盖所有内容）
遵循现有模式还是进行创新

4. Write the PRD

4. 撰写PRD

Default location:

docs/specs/YYYY-MM-DD-<feature>.md

. Use the user's preferred path if they have one.

Structure:

markdown

undefined

默认存储位置：

docs/specs/YYYY-MM-DD-<feature>.md

。若用户有偏好路径，可使用用户指定的路径。

结构如下：

markdown

undefined

[Feature Name] PRD

[功能名称] PRD

Problem

问题描述

One paragraph: what's broken or missing in the current product, and who feels the pain.

一段文字说明当前产品存在的问题或缺失的功能，以及受影响的用户群体。

Solution

解决方案

One paragraph: the shape of the answer, named in domain language.

一段文字说明解决方案的大致形态，使用领域术语命名。

User stories

用户故事

As a <role>, I can <action> so that <outcome>.
(List 5-15)

作为<角色>，我可以<执行操作>，以便<达成目标>。
（列出5-15条）

Architecture

架构设计

Module list with one-line responsibility per module. Reference existing files where relevant. No code paths.

模块列表，每个模块附带一行职责说明。相关联的现有文件可进行引用。无需描述代码路径。

Testing strategy

测试策略

What behaviors must be covered. Integration vs. unit. Real services vs. test doubles.

必须覆盖的行为内容。集成测试vs单元测试。真实服务vs测试替身。

Scope

范围界定

In:

Out:

包含：

排除：

Open questions

待解决问题

Things needing decision before the plan can be written.

undefined

在制定计划前需要决策的事项。

undefined

5. Optional: Create GitHub Issue

5. 可选：创建GitHub Issue

If the user wants the PRD as a GitHub issue, ASK before running
gh issue create
. Never auto-file.

若用户希望将PRD转为GitHub Issue，在执行
gh issue create
前必须询问用户。禁止自动创建。

Hard Rules

硬性规则

Synthesize, don't interrogate. Ask only for genuinely unknown things.
Domain language from
CONTEXT.md
. Use canonical terms.
External behavior over implementation. Testing strategy describes what to verify, not how.
Asks before
gh issue create
. No auto-file.
Never auto-commit. PRD doc gets staged; user confirms before commit.

合成而非询问。仅在确实存在未知信息时才向用户提问。
使用
CONTEXT.md
中的领域术语。采用标准规范术语。
优先关注外部行为而非实现细节。测试策略描述需要验证的内容，而非验证方式。
创建gh issue前需询问。禁止自动创建。
禁止自动提交。PRD文档仅暂存，需用户确认后再提交。

Hand-offs

流程衔接

PRD approved, ready for plan →
```
evanflow-writing-plans
```
. If the PRD's module list shows 3+ independent components sharing a contract, the plan should be structured for
```
evanflow-coder-overseer
```
.
New domain terms emerged →
```
evanflow-glossary
```
to update
```
CONTEXT.md
```
PRD reveals architecture concerns →
```
evanflow-improve-architecture
```
first
PRD's interface design needs more thought →
```
evanflow-design-interface
```
before plan

PRD已获批，准备制定计划 → 转交
```
evanflow-writing-plans
```
。若PRD的模块列表显示有3个及以上共享契约的独立组件，计划需按
```
evanflow-coder-overseer
```
的结构制定。
出现新领域术语 → 转交
```
evanflow-glossary
```
以更新
```
CONTEXT.md
```
PRD暴露出架构问题 → 先转交
```
evanflow-improve-architecture
```
处理
PRD的接口设计需进一步完善 → 制定计划前先转交
```
evanflow-design-interface
```
处理