mcpField
P
prd-writing

prd-writing

github.com/asyrafhussin文档处理95671 次安装9 周前更新
代码仓库

关于 prd-writing

用于编写可执行产品需求文档（PRD）的分步技能，涵盖需求探索、起草、评审、修订与保存，并以 7 类 25 条规则为参考。

主要功能

  1. 01六步 PRD 工作流
  2. 02起草前先探索需求
  3. 03标准 12 部分结构
  4. 04可测试的需求与验收标准
  5. 05根据评审迭代修订

适用场景

  1. 01起草功能 PRD
  2. 02探索新项目的需求
  3. 03对齐范围与成功指标
  4. 04根据反馈修订 PRD

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/asyrafhussin/agent-skills --skill prd-writing

安装后在 Claude Code 中输入/prd-writing确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

AGENTS.md
metadata.json
README.md
rules/
_sections.md
_template.md
disc-clarifying-questions.md
disc-codebase-exploration.md
disc-problem-first.md
disc-stakeholder-alignment.md
metric-kpis.md
metric-measurable-success.md
metric-no-vague-language.md
quality-acceptance-criteria.md
quality-iterative-review.md
req-functional.md
req-non-functional.md
req-user-personas.md
req-user-stories.md
scope-dependencies.md
scope-non-goals.md
scope-out-of-scope.md
struct-executive-summary.md
struct-output-location.md
struct-prd-template.md
struct-single-source-of-truth.md
struct-standard-sections.md
tech-api-routes.md
tech-auth-model.md
tech-data-model.md
tech-integration-points.md

详细介绍

PRD 编写

清晰、可执行的产品需求文档编写分步工作流。按照以下 6 个步骤执行，并将 7 个类别中的 25 条规则作为参考。

元数据

  • 版本： 1.0.0
  • 规则数量： 7 个类别中的 25 条规则
  • 许可证： MIT

工作流

按顺序执行以下步骤。仅当用户已提供相关信息时，才跳过相应步骤。完成需求探索前，切勿开始起草。

第 1 步：评估项目状态

确定当前项目的情况：

  • 现有项目 — 已有代码 → 先探索代码库（模型、路由、控制器、身份验证和模式）。参见 disc-codebase-exploration。
  • 空项目／绿地项目 — 尚无代码 → 先询问用户想构建什么。共同头脑风暴，直到明确产品构想和核心功能，然后询问计划采用的技术栈、架构决策和限制条件。
第 2 步：提出澄清问题

提出 3-5 个有针对性的问题，补足信息缺口。存在明确选项时，使用字母选项（A/B/C）；需要自由文本回答时，使用开放式问题。重点关注：

  1. 问题 — 我们要解决什么问题？为什么是现在？
  2. 用户 — 目标用户是谁？
  3. 范围 — 哪些事情不应该纳入？
  4. 成功 — 如何判断已完成？
  5. 限制条件 — 时间线、预算、团队规模？

将未知事项标记为 TBD，而不是自行假设。参见 disc-clarifying-questions。

第 3 步：起草 PRD

使用 struct-prd-template 中的模板，并填写全部 12 个部分：

  1. 执行摘要 — 1 个段落：问题、解决方案、影响
  2. 问题陈述 — 问题是什么、涉及谁、证据、为何是现在
  3. 目标与成功指标 — 3-5 个可衡量的 KPI
  4. 用户画像 — 主要和次要用户的角色／目标／痛点
  5. 用户故事与验收标准 — 使用“作为……／我想……／以便……”句式，并附复选框
  6. 功能需求 — 编号为 FR-1、FR-2 等
  7. 非功能需求 — 性能、安全性、无障碍性，并给出具体数值
  8. 技术规格 — 数据模型、身份验证、路由、集成
  9. 范围之外 — 我们不会构建的内容及原因
  10. 非目标 — 我们不会针对哪些方面进行优化
  11. 依赖项与风险 — 阻碍因素、负责人及缓解措施
  12. 待解决问题 — 尚未解决的事项、负责人及截止日期

起草时需遵循的关键规则：

  • 从问题开始，而不是解决方案（disc-problem-first）
  • 用数字替换模糊表述（metric-no-vague-language）
  • 每项需求都必须可测试（quality-acceptance-criteria）
  • 复杂的验收标准使用 Given/When/Then 格式
第 4 步：提交审核

向用户展示草稿。明确询问：

  • 问题陈述是否符合你的理解？
  • 用户故事是否遗漏了任何工作流？
  • 范围边界是否正确？
  • 有什么待解决的问题需要我处理？
第 5 步：根据反馈修改

整合反馈、解决待解决问题并更新 PRD。如果 PRD 将与团队共享，请添加审核历史记录。

第 6 步：保存 PRD

使用 kebab-case 命名，将文件保存到 docs/prd/{feature-name}.md。添加 frontmatter：

---
title: Feature Name
status: draft
author: Author Name
created: YYYY-MM-DD
updated: YYYY-MM-DD
---

规则参考

以下 25 条规则为各步骤提供详细指导。需要更多背景信息时，请阅读相关规则。

1. 需求探索（关键）
  • disc-problem-first - 从问题开始，而不是解决方案
  • disc-clarifying-questions - 写作前提出澄清问题
  • disc-codebase-exploration - 起草前探索代码库
  • disc-stakeholder-alignment - 与利益相关者就目标和限制条件达成一致
2. 结构（关键）
  • struct-standard-sections - 使用标准化的 PRD 章节
  • struct-executive-summary - 撰写简洁的执行摘要
  • struct-prd-template - 提供可直接使用的 PRD 模板
  • struct-output-location - 将 PRD 保存到统一的文件位置
  • struct-single-source-of-truth - PRD 是某项功能的权威参考
3. 需求（高优先级）
  • req-user-personas - 定义目标用户画像
  • req-user-stories - 编写包含验收标准的用户故事
  • req-functional - 定义具体的功能需求
  • req-non-functional - 定义非功能需求
4. 范围（高优先级）
  • scope-out-of-scope - 明确界定范围之外的内容
  • scope-non-goals - 列出非目标，以保护时间线
  • scope-dependencies - 确定依赖项和阻碍因素
5. 指标（高优先级）
  • metric-measurable-success - 定义可衡量的成功标准
  • metric-no-vague-language - 用可量化的基准替换模糊用语
  • metric-kpis - 定义 3-5 项关键绩效指标
6. 技术（中优先级）
  • tech-data-model - 记录数据模型及其关系
  • tech-auth-model - 定义身份验证和授权
  • tech-api-routes - 记录 API 和路由结构
  • tech-integration-points - 确定第三方集成
7. 质量（中优先级）
  • quality-acceptance-criteria - 编写可测试的验收标准
  • quality-iterative-review - 在定稿前根据反馈反复迭代

参考资料

完整汇总文档

如需查看包含所有规则详述的完整指南：AGENTS.md

评论

支持 Markdown