Back to Details

pdd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Prompt-Driven Development

Prompt-Driven Development（提示驱动开发）

Overview

概述

Transform a rough idea into a detailed design with an implementation plan. The process is iterative: clarify requirements, research, design, plan — moving between phases as needed.
将粗略想法转化为包含实施计划的详细设计方案。流程采用迭代式：澄清需求、开展研究、进行设计、制定规划——可根据需要在各阶段间切换。

Important Notes

重要说明

These rules apply across ALL steps:
  • User-driven flow: Never proceed to the next step without explicit user confirmation. At each transition, ask the user what they want to do next.
  • Iterative: The user can move between requirements clarification and research at any time. Always offer this option at phase transitions.
  • Record as you go: Append questions, answers, and findings to project files in real time — don't batch-write at the end.
  • Mermaid diagrams: Include diagrams for architectures, data flows, and component relationships in research and design documents.
  • Sources: Cite references and links in research documents when based on external materials.
  • Planning only: This SOP produces planning artifacts. You MUST NOT implement code, run containers, execute scripts, or begin any implementation work. If the user wants implementation, direct them to 
    ralph run
    .
以下规则适用于所有步骤：
  • 用户驱动流程： 未获得用户明确确认前，不得进入下一步。在每个阶段转换时，询问用户接下来想要执行的操作。
  • 迭代式： 用户可随时在需求澄清和研究阶段之间切换。在阶段转换时必须提供该选项。
  • 实时记录： 实时将问题、答案和发现追加到项目文件中——不得在最后批量撰写。
  • Mermaid 图表： 在研究和设计文档中包含架构、数据流和组件关系的Mermaid图表。
  • 来源标注： 若研究文档基于外部资料，需引用参考文献和链接。
  • 仅用于规划： 本SOP仅产出规划类产物。不得编写代码、运行容器、执行脚本或开展任何实施工作。若用户希望进行实施，引导其使用
    ralph run
    命令。

Parameters

参数

  • rough_idea (required): The initial concept or idea to develop
  • project_dir (optional, default: 
    specs/{task_name}/
    ): Base directory for all artifacts. 
    {task_name}
    is derived as kebab-case from the idea (e.g., "build a rate limiter" → 
    rate-limiter
    ). Aligns with Ralph's spec-driven pipeline.
Constraints:
  • You MUST ask for all required parameters upfront in a single prompt
  • You MUST support multiple input methods: direct text, file path, URL
  • You MUST derive 
    task_name
    from the rough idea as kebab-case
  • You MUST NOT overwrite an existing project directory — ask for a new path if it already has contents
  • rough_idea（必填）：待开发的初始概念或想法
  • project_dir（可选，默认值：
    specs/{task_name}/
    ）：所有产物的基础目录。
    {task_name}
    由想法转换为短横线分隔的小写格式（例如："build a rate limiter" → 
    rate-limiter
    ）。与Ralph的规格驱动流水线对齐。
约束条件：
  • 必须在单个提示中提前询问所有必填参数
  • 必须支持多种输入方式：直接文本、文件路径、URL
  • 必须将rough_idea转换为短横线分隔的小写格式作为
    task_name
  • 不得覆盖现有项目目录——若目录已有内容，需询问新路径

Steps

步骤

1. Create Project Structure

1. 创建项目结构

Create the directory and initial files:
  • {project_dir}/rough-idea.md
    — the provided rough idea
  • {project_dir}/requirements.md
    — Q&A record (initially empty)
  • {project_dir}/research/
    — directory for research notes
Inform the user the structure feeds into Ralph's spec-driven presets.
Gate: You MUST NOT proceed to Step 2 until the user confirms the project structure is acceptable.
创建目录和初始文件：
  • {project_dir}/rough-idea.md
    —— 存储提供的粗略想法
  • {project_dir}/requirements.md
    —— 问答记录（初始为空）
  • {project_dir}/research/
    —— 研究笔记目录
告知用户该结构可对接Ralph的规格驱动预设。
关卡： 必须在用户确认项目结构可接受后，才能进入步骤2。

2. Initial Process Planning

2. 初始流程规划

Ask the user their preferred starting point:
  • Requirements clarification (default)
  • Preliminary research on specific topics
  • Provide additional context first
Gate: You MUST wait for the user to choose before proceeding. You MUST NOT automatically start requirements clarification or research without explicit user direction.
询问用户偏好的起始点：
  • 需求澄清（默认选项）
  • 针对特定主题开展初步研究
  • 先提供额外上下文
关卡： 必须等待用户选择后再继续。不得在未获得用户明确指示的情况下，自动启动需求澄清或研究工作。

3. Requirements Clarification

3. 需求澄清

Guide the user through questions to refine the idea into a thorough specification.
Constraints:
  • You MUST ask ONE question at a time — do not list multiple questions
  • You MUST NOT pre-populate answers or batch-write Q&A to requirements.md
  • You MUST follow this cycle for each question:
    1. Formulate and append question to requirements.md
    2. Present to user, wait for complete response
    3. Append answer to requirements.md
    4. Proceed to next question
  • You MUST ask the user if requirements clarification is complete before moving on
Cover edge cases, user experience, technical constraints, and success criteria. Suggest options when the user is unsure.
Gate: You MUST NOT proceed to Research or Design until the user explicitly confirms requirements clarification is complete. You MUST offer the option to conduct research if questions arise that would benefit from additional information.
通过引导用户回答问题，将想法细化为完整的规格说明。
约束条件：
  • 必须一次只提出一个问题——不得列出多个问题
  • 不得预先填充答案或批量撰写问答内容到requirements.md
  • 针对每个问题必须遵循以下循环：
    1. 拟定问题并追加到requirements.md
    2. 呈现给用户，等待完整回复
    3. 将答案追加到requirements.md
    4. 进入下一个问题
  • 在进入下一阶段前，必须询问用户需求澄清是否完成
涵盖边缘情况、用户体验、技术约束和成功标准。当用户不确定时，可提供选项参考。
关卡： 必须在用户明确确认需求澄清完成后，才能进入研究或设计阶段。若出现需要补充信息的问题，必须提供开展研究的选项。

4. Research

4. 研究阶段

Conduct research on technologies, libraries, or existing code to inform the design.
Constraints:
  • You MUST propose a research plan to the user and incorporate their suggestions
  • You MUST document findings in 
    {project_dir}/research/
    as separate topic files
  • You MUST periodically check in with the user to share findings and confirm direction
  • You MUST summarize key findings before moving on
Gate: You MUST NOT proceed to the Iteration Checkpoint until the user confirms research is sufficient. You MUST offer to return to requirements clarification if research uncovers new questions.
针对技术、库或现有代码开展研究，为设计提供依据。
约束条件：
  • 必须向用户提出研究计划，并纳入用户的建议
  • 必须将研究发现记录在
    {project_dir}/research/
    目录下的独立主题文件中
  • 必须定期与用户同步研究发现，确认方向
  • 在进入下一阶段前，必须总结关键研究发现
关卡： 必须在用户确认研究足够充分后，才能进入迭代检查点。若研究中发现新问题，必须提供返回需求澄清阶段的选项。

5. Iteration Checkpoint

5. 迭代检查点

Summarize the current state of requirements and research, then ask the user:
  • Proceed to design?
  • Return to requirements clarification?
  • Conduct additional research?
Gate: You MUST NOT proceed to design without explicit user confirmation. You MUST support iterating between requirements and research as many times as needed.
总结当前需求和研究的进展，然后询问用户：
  • 进入设计阶段？
  • 返回需求澄清阶段？
  • 开展额外研究？
关卡： 必须在获得用户明确确认后，才能进入设计阶段。必须支持在需求和研究阶段之间进行多次迭代。

6. Create Detailed Design

6. 创建详细设计

Create 
{project_dir}/design.md
as a standalone document with these sections:
  • Overview
  • Detailed Requirements (consolidated from requirements.md)
  • Architecture Overview
  • Components and Interfaces
  • Data Models
  • Error Handling
  • Acceptance Criteria (Given-When-Then format for machine verification)
  • Testing Strategy
  • Appendices (Technology Choices, Research Findings, Alternative Approaches)
Constraints:
  • You MUST write the design as standalone — understandable without reading other files
  • You MUST consolidate all requirements from requirements.md
  • You MUST include an appendix summarizing research (technology choices, alternatives, limitations)
  • You MUST review the design with the user and iterate on feedback
Gate: You MUST NOT proceed to the implementation plan until the user explicitly approves the design. You MUST offer to return to requirements or research if gaps are identified during design review.
创建
{project_dir}/design.md
作为独立文档，包含以下章节：
  • 概述
  • 详细需求（从requirements.md整合而来）
  • 架构概述
  • 组件与接口
  • 数据模型
  • 错误处理
  • 验收标准（采用Given-When-Then格式，便于机器验证）
  • 测试策略
  • 附录（技术选型、研究发现、替代方案）
约束条件：
  • 设计文档必须独立可懂——无需参考其他文件
  • 必须整合requirements.md中的所有需求
  • 必须包含总结研究内容的附录（技术选型、替代方案、局限性）
  • 必须与用户一同评审设计，并根据反馈进行迭代
关卡： 必须在用户明确批准设计后，才能进入实施计划阶段。若在设计评审中发现漏洞，必须提供返回需求或研究阶段的选项。

7. Develop Implementation Plan

7. 制定实施计划

Create 
{project_dir}/plan.md
— a numbered series of incremental implementation steps.
Guiding principle: Each step builds on previous steps, results in working demoable functionality, and follows TDD practices. No orphaned code — every step ends with integration. Core end-to-end functionality should be available as early as possible.
Constraints:
  • You MUST include a checklist at the top of plan.md tracking each step
  • You MUST format as "Step N:" with: objective, implementation guidance, test requirements, integration notes, and demo description
  • You MUST ensure the plan covers all aspects of the design without duplicating design details
Gate: You MUST NOT proceed to the summary until the user reviews and approves the implementation plan.
创建
{project_dir}/plan.md
—— 按编号排列的增量式实施步骤列表。
指导原则： 每个步骤都基于前序步骤，产出可演示的可用功能，并遵循TDD实践。无孤立代码——每个步骤结束时都需完成集成。核心端到端功能应尽早实现。
约束条件：
  • 必须在plan.md顶部包含跟踪每个步骤的检查清单
  • 必须以“步骤N：”格式编写，包含：目标、实施指南、测试要求、集成说明、演示描述
  • 必须确保计划覆盖设计的所有方面，且不重复设计细节
关卡： 必须在用户评审并批准实施计划后，才能进入总结阶段。

8. Summarize and Present Results

8. 总结并展示成果

Create 
{project_dir}/summary.md
listing all artifacts, a brief overview, and suggested next steps. Present this summary in the conversation.
创建
{project_dir}/summary.md
，列出所有产物、简要概述和建议的下一步操作。在对话中呈现该总结。

9. Offer Ralph Integration

9. 提供Ralph集成选项

Ask: "Would you like me to create a PROMPT.md for Ralph to implement this autonomously?"
If yes, create a concise PROMPT.md (under 100 lines) with:
  • Objective statement
  • Key requirements
  • Acceptance criteria (Given-When-Then)
  • Reference to 
    specs/{task_name}/
Suggest the appropriate command:
  • Full pipeline: 
    ralph run --config presets/pdd-to-code-assist.yml
  • Simpler flow: 
    ralph run --config presets/spec-driven.yml
If the user declines, acknowledge and conclude the session.
Gate: You MUST NOT run 
ralph run
or begin any implementation. This SOP ends here. Implementation is a separate step the user initiates themselves.
询问用户：“是否需要我为Ralph创建PROMPT.md以实现自主实施？”
若用户同意，创建简洁的PROMPT.md（不超过100行），包含：
  • 目标陈述
  • 核心需求
  • 验收标准（Given-When-Then格式）
  • 指向
    specs/{task_name}/
    的参考链接
推荐相应命令：
  • 完整流水线：
    ralph run --config presets/pdd-to-code-assist.yml
  • 简化流程：
    ralph run --config presets/spec-driven.yml
若用户拒绝，确认后结束会话。
关卡： 不得运行
ralph run
或开展任何实施工作。本SOP在此结束。实施是用户自主启动的独立步骤。

Example

示例

Input: "I want to build a template management feature for our internal tool — create, edit, share templates, generate documents with custom fields."
Output: A 
specs/template-management/
directory containing rough-idea.md, requirements.md, research/, design.md, plan.md, and summary.md — plus optionally a PROMPT.md for autonomous implementation.
输入： “我想为我们的内部工具构建模板管理功能——创建、编辑、分享模板，支持自定义字段生成文档。”
输出： 一个
specs/template-management/
目录，包含rough-idea.md、requirements.md、research/、design.md、plan.md和summary.md——可选包含用于自主实施的PROMPT.md。

Troubleshooting

故障排除

Requirements stall: Suggest switching to a different aspect, provide examples, or pivot to research to unblock decisions.
Research limitations: Document what's missing, suggest alternatives with available information, ask user for additional context. Don't block progress.
Design complexity: Break into smaller components, focus on core functionality first, suggest phased implementation, return to requirements to re-prioritize.
需求停滞： 建议切换到其他方面、提供示例或转向研究阶段以推进决策。
研究局限性： 记录缺失的内容，基于现有信息提供替代方案，询问用户补充上下文。不得阻碍进度。
设计复杂度高： 拆分为更小的组件，先聚焦核心功能，建议分阶段实施，返回需求阶段重新排序优先级。