ralph-tui-prd

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Ralph TUI PRD Generator

Ralph TUI PRD生成器

Create detailed Product Requirements Documents optimized for AI agent execution via ralph-tui.

创建针对通过ralph-tui执行的AI Agent优化的详细产品需求文档。

The Job

任务流程

Receive a feature description from the user
Ask 3-5 essential clarifying questions (with lettered options) - one set at a time
Always ask about quality gates (what commands must pass)
After each answer, ask follow-up questions if needed (adaptive exploration)
Generate a structured PRD when you have enough context
Output the PRD wrapped in
```
[PRD]...[/PRD]
```
markers for TUI parsing

Important: Do NOT start implementing. Just create the PRD.

接收用户提供的功能描述
提出3-5个关键的澄清问题（带字母选项）- 每次一组
务必询问质量门禁相关问题（需要通过哪些命令）
每次收到回答后，如有需要提出跟进问题（自适应探索）
当获取足够上下文后，生成结构化的PRD
输出用
```
[PRD]...[/PRD]
```
标记包裹的PRD，以便TUI解析

重要提示： 不要开始实现功能，仅需创建PRD。

Step 1: Clarifying Questions (Iterative)

步骤1：澄清问题（迭代式）

Ask questions one set at a time. Each answer should inform your next questions. Focus on:

Problem/Goal: What problem does this solve?
Core Functionality: What are the key actions?
Scope/Boundaries: What should it NOT do?
Success Criteria: How do we know it's done?
Integration: How does it fit with existing features?
Quality Gates: What commands must pass for each story? (REQUIRED)

每次提出一组问题。每个回答都应指导后续问题的方向。重点关注：

问题/目标： 该功能解决什么问题？
核心功能： 关键操作有哪些？
范围/边界： 该功能不应该做什么？
成功标准： 如何判断功能已完成？
集成： 如何与现有功能集成？
质量门禁： 每个用户故事必须通过哪些命令？（必填项）

Format Questions Like This:

问题格式示例：

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

This lets users respond with "1A, 2C" for quick iteration.

1. 该功能的主要目标是什么？
   A. 改善用户入门体验
   B. 提升用户留存率
   C. 减少支持负担
   D. 其他：[请说明]

2. 目标用户是谁？
   A. 仅新用户
   B. 仅现有用户
   C. 所有用户
   D. 仅管理员用户

这样用户可以通过回复“1A, 2C”快速完成迭代。

Quality Gates Question (REQUIRED)

质量门禁问题（必填项）

Always ask about quality gates - these are project-specific:

What quality commands must pass for each user story?
   A. pnpm typecheck && pnpm lint
   B. npm run typecheck && npm run lint
   C. bun run typecheck && bun run lint
   D. Other: [specify your commands]

For UI stories, should we include browser verification?
   A. Yes, use dev-browser skill to verify visually
   B. No, automated tests are sufficient

务必询问质量门禁相关问题——这些是项目特定要求：

每个用户故事必须通过哪些质量验证命令？
   A. pnpm typecheck && pnpm lint
   B. npm run typecheck && npm run lint
   C. bun run typecheck && bun run lint
   D. 其他：[请指定命令]

对于UI相关的用户故事，是否需要包含浏览器验证？
   A. 是，使用dev-browser skill进行可视化验证
   B. 否，自动化测试已足够

Adaptive Questioning

自适应提问

After each response, decide whether to:

Ask follow-up questions (if answers reveal complexity)
Ask about a new aspect (if current area is clear)
Generate the PRD (if you have enough context)

Typically 2-4 rounds of questions are needed.

每次收到回答后，决定：

提出跟进问题（如果回答揭示了复杂性）
询问新的方面（如果当前领域已明确）
生成PRD（如果已获取足够上下文）

通常需要2-4轮提问。

Step 2: PRD Structure

步骤2：PRD结构

Generate the PRD with these sections:

生成包含以下部分的PRD：

1. Introduction/Overview

1. 引言/概述

Brief description of the feature and the problem it solves.

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

2. Goals

2. 目标

Specific, measurable objectives (bullet list).

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

3. Quality Gates

3. 质量门禁

CRITICAL: List the commands that must pass for every user story.

markdown

undefined

关键： 列出每个用户故事必须通过的命令。

markdown

undefined

Quality Gates

质量门禁

These commands must pass for every user story:

```
pnpm typecheck
```
- Type checking
```
pnpm lint
```
- Linting

For UI stories, also include:

Verify in browser using dev-browser skill


This section is extracted by conversion tools (ralph-tui-create-json, ralph-tui-create-beads) and appended to each story's acceptance criteria.

每个用户故事必须通过以下命令：

```
pnpm typecheck
```
- 类型检查
```
pnpm lint
```
- 代码检查

对于UI相关故事，还需包含：

使用dev-browser skill在浏览器中验证


该部分会被转换工具（ralph-tui-create-json、ralph-tui-create-beads）提取，并附加到每个故事的验收标准中。

4. User Stories

4. 用户故事

Each story needs:

Title: Short descriptive name
Description: "As a [user], I want [feature] so that [benefit]"
Acceptance Criteria: Verifiable checklist of what "done" means

Each story should be small enough to implement in one focused AI agent session.

Format:

markdown

undefined

每个故事需要包含：

标题： 简短描述性名称
描述： "作为[用户角色]，我希望[功能]，以便[收益]"
验收标准： 可验证的完成标准清单

每个故事应足够小，以便在一个AI Agent会话中完成。

格式：

markdown

undefined

US-001: [Title]

US-001: [标题]

Description: As a [user], I want [feature] so that [benefit].

Acceptance Criteria:

Specific verifiable criterion
Another criterion


**Note:** Do NOT include quality gate commands in individual story criteria - they are defined once in the Quality Gates section and applied automatically during conversion.

**Important:**
- Acceptance criteria must be verifiable, not vague
- "Works correctly" is bad
- "Button shows confirmation dialog before deleting" is good
- Each story should be independently completable

描述： 作为[用户角色]，我希望[功能]，以便[收益]。

验收标准：

具体可验证的标准
另一项标准


**注意：** 不要在单个故事的验收标准中包含质量门禁命令——这些命令在“质量门禁”部分统一定义，并在转换时自动应用。

**重要提示：**
- 验收标准必须可验证，不能模糊
- “正常工作”是不合格的表述
- “删除前按钮显示确认对话框”是合格的表述
- 每个故事应可独立完成

5. Functional Requirements

5. 功能需求

Numbered list of specific functionalities:

"FR-1: The system must allow users to..."
"FR-2: When a user clicks X, the system must..."

Be explicit and unambiguous.

编号列表形式的具体功能：

"FR-1: 系统必须允许用户..."
"FR-2: 当用户点击X时，系统必须..."

表述需明确、无歧义。

6. Non-Goals (Out of Scope)

6. 非目标（范围外内容）

What this feature will NOT include. Critical for managing scope.

该功能不包含的内容。这对于范围管理至关重要。

7. Technical Considerations (Optional)

7. 技术考虑（可选）

Known constraints or dependencies
Integration points with existing systems
Performance requirements

已知约束或依赖
与现有系统的集成点
性能要求

8. Success Metrics

8. 成功指标

How will success be measured?

如何衡量成功？

9. Open Questions

9. 待解决问题

Remaining questions or areas needing clarification.

剩余的问题或需要澄清的领域。

Writing for AI Agents

为AI Agent编写PRD

The PRD will be executed by AI coding agents via ralph-tui. Therefore:

Be explicit and unambiguous
User stories should be small (completable in one session)
Acceptance criteria must be machine-verifiable where possible
Include specific file paths if you know them
Reference existing code patterns in the project

PRD将通过ralph-tui由AI编码Agent执行。因此：

表述需明确、无歧义
用户故事应足够小（可在一个会话中完成）
验收标准应尽可能可被机器验证
如果已知，包含具体文件路径
参考项目中现有的代码模式

Output Format

输出格式

CRITICAL: Wrap the final PRD in markers for TUI parsing:

[PRD]

关键： 将最终PRD用标记包裹，以便TUI解析：

[PRD]

PRD: Feature Name

PRD: 功能名称

Overview

概述

...

Quality Gates

质量门禁

...

User Stories

用户故事

... [/PRD]


**File naming:** The TUI will save to `./tasks/prd-[feature-name].md`

---

... [/PRD]


**文件命名：** TUI会将文件保存至`./tasks/prd-[feature-name].md`

---

Example Conversation Flow

对话流程示例

User: Create a PRD for adding dark mode to the TUI

Assistant: I'll help you create a PRD for dark mode. Let me ask a few questions:

What is the primary goal? A. Reduce eye strain for long sessions B. Match system theme preference C. Provide visual customization D. Other
Should the setting persist? A. Yes, save to config file B. No, session only C. Follow system preference

User: 1A, 2A

Assistant: Great! A couple more questions:

Which components need dark mode support? A. All TUI components B. Only the main execution view C. Main view + settings D. Other
What quality commands must pass for each story? A. pnpm typecheck && pnpm lint B. npm run typecheck && npm run lint C. bun run typecheck D. Other: [specify]
For UI stories, include browser verification? A. Yes, use dev-browser skill B. No, automated tests sufficient

User: 3A, 4A, 5A

Assistant: Perfect, I have enough to generate the PRD.

[PRD]

用户： 为TUI添加深色模式创建PRD

助手： 我将帮你创建深色模式的PRD。让我问几个问题：

主要目标是什么？ A. 减少长时间使用时的眼部疲劳 B. 匹配系统主题偏好 C. 提供视觉自定义选项 D. 其他
设置是否需要持久化？ A. 是，保存至配置文件 B. 否，仅在当前会话有效 C. 跟随系统偏好

用户： 1A, 2A

助手： 很好！再问几个问题：

哪些组件需要支持深色模式？ A. 所有TUI组件 B. 仅主执行视图 C. 主视图+设置 D. 其他
每个故事必须通过哪些质量验证命令？ A. pnpm typecheck && pnpm lint B. npm run typecheck && npm run lint C. bun run typecheck D. 其他：[请指定]
对于UI相关故事，是否包含浏览器验证？ A. 是，使用dev-browser skill B. 否，自动化测试已足够

用户： 3A, 4A, 5A

助手： 完美，我已获取足够信息生成PRD。

[PRD]

PRD: Dark Mode for Ralph TUI

PRD: Ralph TUI深色模式

Overview

概述

Add dark mode support to ralph-tui to reduce eye strain during long orchestration sessions. The feature will apply to all TUI components and persist the user's preference in the config file.

为ralph-tui添加深色模式支持，以减少长时间编排会话中的眼部疲劳。该功能将应用于所有TUI组件，并将用户偏好保存至配置文件。

Goals

目标

Provide a comfortable viewing experience in low-light environments
Persist theme preference across sessions
Apply consistent styling to all TUI components

在低光环境下提供舒适的观看体验
跨会话持久化主题偏好
为所有TUI组件应用一致的样式

Quality Gates

质量门禁

These commands must pass for every user story:

```
pnpm typecheck
```
- Type checking
```
pnpm lint
```
- Linting

For UI stories, also include:

Verify in browser using dev-browser skill

每个用户故事必须通过以下命令：

```
pnpm typecheck
```
- 类型检查
```
pnpm lint
```
- 代码检查

对于UI相关故事，还需包含：

使用dev-browser skill在浏览器中验证

User Stories

用户故事

US-001: Add theme configuration

US-001: 添加主题配置

Description: As a user, I want to set my preferred theme (light/dark) so that it persists across sessions.

Acceptance Criteria:

Add
```
theme
```
field to
```
.ralph-tui.yaml
```
schema
Support values: "light", "dark", "system"
Default to "light" for backwards compatibility

描述： 作为用户，我希望设置偏好主题（亮色/暗色），以便跨会话保持设置。

验收标准：

为
```
.ralph-tui.yaml
```
schema添加
```
theme
```
字段
支持值："light"、"dark"、"system"
为保持向后兼容性，默认值为"light"

US-002: Create dark theme color palette

US-002: 创建深色主题调色板

Description: As a user, I want a soft-contrast dark theme that's easy on the eyes.

Acceptance Criteria:

Define dark palette with gray tones (not pure black)
Ensure sufficient contrast ratios (WCAG AA)
Colors work well for all UI states (selected, hover, disabled)

描述： 作为用户，我希望有一个低对比度的深色主题，以减轻眼部负担。

验收标准：

定义基于灰色调的深色调色板（非纯黑）
确保足够的对比度（符合WCAG AA标准）
颜色适用于所有UI状态（选中、悬停、禁用）

US-003: Apply theme to TUI components

US-003: 为TUI组件应用主题

US-004: Add theme toggle in settings

US-004: 在设置中添加主题切换按钮

Description: As a user, I want to toggle themes from within the TUI settings.

Acceptance Criteria:

Theme option visible in settings view
Changes apply immediately without restart
Changes persist to config file

描述： 作为用户，我希望能在TUI设置中切换主题。

验收标准：

设置视图中显示主题选项
更改后立即生效，无需重启
更改保存至配置文件

Functional Requirements

功能需求

FR-1: Theme setting must be readable from
```
.ralph-tui.yaml
```
FR-2: Theme must apply on TUI startup
FR-3: Theme changes in settings must apply immediately
FR-4: All text must maintain readability in both themes

FR-1: 必须能从
```
.ralph-tui.yaml
```
中读取主题设置
FR-2: 主题必须在TUI启动时应用
FR-3: 设置中的主题更改必须立即生效
FR-4: 所有文本在两种主题下都必须保持可读性

Non-Goals

非目标

System theme auto-detection (future enhancement)
Custom color schemes beyond light/dark
Per-component theme overrides

系统主题自动检测（未来增强功能）
亮色/暗色之外的自定义配色方案
组件级主题覆盖

Technical Considerations

技术考虑

Use existing OpenTUI theming capabilities if available
Consider creating a ThemeContext for React components
Minimize re-renders when theme changes

如果可用，使用现有OpenTUI主题功能
考虑为React组件创建ThemeContext
主题更改时最小化重渲染

Success Metrics

成功指标

All components render correctly in dark mode
No accessibility contrast issues
Theme persists across sessions

所有组件在深色模式下正确渲染
无可访问性对比度问题
主题跨会话持久化

Open Questions

待解决问题

Should we detect system theme preference automatically in v2? [/PRD]

在v2版本中是否应自动检测系统主题偏好？ [/PRD]

Checklist

检查清单

Before outputting the PRD:

Asked clarifying questions with lettered options
Asked about quality gates (REQUIRED)
Asked follow-up questions when needed
Quality Gates section included with project-specific commands
User stories are small and independently completable
User stories do NOT include quality gate commands (they're in the Quality Gates section)
Functional requirements are numbered and unambiguous
Non-goals section defines clear boundaries
PRD is wrapped in
```
[PRD]...[/PRD]
```
markers

输出PRD前请确认：

提出了带字母选项的澄清问题
询问了质量门禁相关问题（必填项）
必要时提出了跟进问题
包含了项目特定命令的质量门禁部分
用户故事足够小且可独立完成
用户故事中未包含质量门禁命令（这些命令在“质量门禁”部分统一定义）
功能需求编号且表述明确
非目标部分定义了清晰的边界
PRD用
```
[PRD]...[/PRD]
```
标记包裹