prd

prd

使用此技能编写可供实现 Agent 执行的 PRD。

PRD 是一份交接文档。使用此技能时不要编写代码。

输出位置

除非项目有更具体的本地约定，或用户要求使用其他位置，否则将 PRD 文件保存在 .dev/<topic-slug>/ 下。

默认文件：

• .dev/<topic-slug>/prd.md - 合约：问题、范围、需求、验收标准、任务和验证。
• .dev/<topic-slug>/checklist.md - 从 PRD 的任务中提取的可勾选任务清单，供 implement 用作实时清单（参见清单结构）。
• .dev/<topic-slug>/context-notes.md - 代码库探索所得的背景说明（关键文件、约定、限制），避免 implement 重复探索。

如果主题 slug 不明确，请根据功能名称选择一个简短的 kebab-case slug，并在写入文件前说明。

输入

优先使用以下输入之一：

• clarify 交接摘要。
• 信息足够详细的用户功能请求。
• 现有项目文档，例如 CLAUDE.md、AGENTS.md、README.md、规格说明或相邻的 PRD。

如果仍存在重大歧义，请提出一个阻塞性问题，或建议先运行 /clarify。

工作流程

1. 根据需要先探索代码库再编写内容——阅读相关的项目指南、代码和配置，确保 PRD 立足于项目的实际情况。
2. 明确问题、目标、用户和当前范围。
3. 将范围与非目标分开说明。
4. 从高层次说明预期的技术结构变更。
5. 编写带编号、可测试的需求。
6. 编写可由人员、命令、浏览器、API 响应、数据库记录或日志检查的验收标准。
7. 根据需求推导任务。不要在任务中虚构未声明的范围。
8. 分别定义 Agent 验证和人工验证。
9. 以实现结果报告规范收尾。
10. 根据任务编写 checklist.md（参见清单结构），并根据代码库探索结果编写 context-notes.md，确保交接给 implement 的信息完整。

必需的 PRD 结构

# PRD: <feature>

## Summary

## Problem And Goal

## Users And Use Cases

## Pre-Work

## Non-Goals

## Requirements

## Acceptance Criteria

## Verification - Agent

## Verification - Human

## Technical Structure And Changes

## Tasks

## Risks And Open Decisions

## Implementation Result Report Contract

清单结构

checklist.md 是 PRD 任务的可执行形式，也是 implement 在构建过程中勾选的清单。请与 Tasks 和 Acceptance Criteria 部分保持同步；不要在此处添加 PRD 未声明的范围。

每个任务都带有可追溯标签，以便 implement 据此生成结构化任务清单：

• (req: R1) - 任务所实现的需求。
• (ac: AC1) - 任务所负责的验收标准。如果任务纯属准备工作且没有对应的验收标准，则省略。
• (after: T1) - 存在执行顺序要求时，必须先完成的任务。请使用 T<n> 任务 ID 引用任务。没有前置任务时省略。

任务编号格式为 T1、T2……，以便 after: 可以引用任务。

# Checklist: <feature>

## Tasks

- [ ] T1 <task 1> (req: R1) (ac: AC1)
- [ ] T2 <task 2> (req: R2) (ac: AC2) (after: T1)

## Acceptance Criteria

- [ ] AC1 <criterion 1>
- [ ] AC2 <criterion 2>

## Human Checks

- [ ] <thing a person must confirm>

规则

• 使用韩语编写 PRD。必需 PRD 结构中的章节标题保持原样，但正文、需求、验收标准和任务均使用韩语编写。
• 需求必须描述可观察到的行为。
• 验收标准必须包含验证路径。
• 任务必须对应需求或验证。
• 如果没有预期的结构变更，请明确说明。
• PRD 应可直接用于实现，而非用于营销。
• 不要因为相关想法看起来有用，就扩大 MVP 的范围。