什么是 pdd (提示词驱动开发)？

pdd 技能实现了严格的提示词驱动开发方法论，充当初始概念与实际代码之间的桥梁。通过利用 Openclaw Skills，该工具可确保在开始实施之前完全澄清、研究和设计需求。它强制执行一种受约束的人机协作工作流，智能体与用户共同构建单一事实来源，从而减少技术债并防止需求蔓延。

该技能对于需要记录架构决策和技术选择的复杂软件任务特别有效。通过在 Openclaw Skills 生态系统中遵循 pdd 流程，开发人员可以生成高质量的产物，供 Ralph 等智能体进行自主实施或由技术团队进行手动开发。

下载入口:https://github.com/openclaw/skills/tree/main/skills/paulpete/pdd

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

pdd (提示词驱动开发) 应用场景

• 将高层级的需求转化为带有 Mermaid 架构图的详细设计文档。
• 在开始新模块之前，对特定库或 API 进行深度调研。
• 创建支持测试驱动开发（TDD）的实施计划，将项目拆分为可演示的增量步骤。
• 为使用 AI 编程助手的团队标准化规范流程，确保项目产物的一致性。

1. 用户通过文本、文件或 URL 提供粗略的想法，技能随后初始化项目目录。
2. 技能进入需求澄清阶段，每次提出一个针对性问题以构建 requirements.md 文件。
3. 启动调研阶段以探索技术选择，在专门的主题文件中引用来源并记录发现。
4. 将所有收集到的信息合成为一份独立的 design.md 文档，涵盖架构、数据模型和错误处理。
5. 在 plan.md 中生成实施计划，包含带有测试要求和集成说明的增量步骤清单。
6. 流程以总结和可选的集成步骤结束，将项目移交给自主实施智能体。

pdd (提示词驱动开发) 配置指南

要使用 pdd 技能，请确保您的智能体环境已配置为加载 Openclaw Skills。您可以通过提供所需参数来触发该技能：

# pdd 技能示例参数
rough_idea: "使用 WebSockets 构建实时通知系统"
project_dir: "specs/notifications/" # 可选：默认为想法的 kebab-case 格式

随后智能体将引导您完成迭代步骤，在进入不同阶段前需要明确的确认。

pdd (提示词驱动开发) 数据架构与分类体系

该技能使用以下结构在专用项目目录中组织所有输出：

name: pdd
description: Transforms a rough idea into a detailed design document with implementation plan. Follows Prompt-Driven Development — iterative requirements clarification, research, design, and planning.
type: anthropic-skill
version: "1.1"

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.

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

Steps

1. Create Project Structure

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.

2. Initial Process Planning

Ask the user their preferred starting point:

• Requirements clarification (default)
• Preliminary research on specific topics
• Provide additional context first

3. Requirements Clarification

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.

4. Research

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

5. Iteration Checkpoint

Summarize the current state of requirements and research, then ask the user:

• Proceed to design?
• Return to requirements clarification?
• Conduct additional research?

6. Create Detailed Design

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

7. Develop Implementation Plan

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

8. Summarize and Present Results

Create {project_dir}/summary.md listing all artifacts, a brief overview, and suggested next steps. Present this summary in the conversation.

9. Offer Ralph Integration

Ask: "Would you like me to set up 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

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.

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.