尧图网页设计 
knowledge-work-plugins 产品管理插件 write-spec 技能从问题陈述到结构化 PRD 的完整实战指南【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins本指南以 write-spec 技能文档 为骨架结合 knowledge-work-plugins 仓库中 product-management 插件的连接器配置、命令体系与配套技能系统讲解如何在 Claude Cowork 中把一句模糊的想法或用户请求逐步转化为一份可直接驱动研发、设计、数据团队落地的产品需求文档PRD。读完本文你将掌握 write-spec 的五步工作流、PRD 八个标准章节的写作规范、INVEST 用户故事标准、MoSCoW/P0-P1-P2 需求分级方法、前置/滞后指标定义以及防止范围蔓延的实操手段。一、write-spec 是什么插件的定位与使用方式write-spec 是 product-management 插件 中负责把想法变成规格的核心技能。在插件的完整 PM 工作流里它与/brainstorm头脑风暴、/roadmap-update路线图、/synthesize-research研究综合、/stakeholder-update干系人同步、/competitive-brief竞品简报等命令共同覆盖了从创意产生、需求定义到落地跟进的全链路而 write-spec 正是其中将模糊输入转化为可执行文档的关键一环。从技能文件头部的 frontmatter 可以看出它的适用时机name: write-spec description: Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec. argument-hint: feature or problem statement即当需要把模糊想法或用户请求转成结构化文档、为功能划定目标与非目标、定义成功指标和验收标准、或把大需求拆分成分阶段规格时都应当触发该技能。它既支持作为独立技能被自动调用也支持通过斜杠命令显式触发/write-spec $ARGUMENTS例如在会话中直接输入/write-spec We need to add SSO support for enterprise customers或在触发后回答 Claude 的追问。安装该插件后Claude Code 下使用claude plugin install product-managementknowledge-work-pluginsCowork 中可直接从插件市场安装技能会在相关场景下自动生效。二、五步工作流从想法到 PRD 的完整链路技能文档定义了一个五步渐进式工作流核心原则是对话式收集信息绝不一次性倾倒问题清单。第 1 步理解功能Understand the Feature向用户询问要规格化的对象接受以下任一输入形态功能名称如 SSO support问题陈述如 Enterprise customers keep asking for centralized auth用户请求如 Users want to export their data as CSV模糊想法如 We should do something about onboarding drop-off第 2 步收集上下文Gather Context以对话方式而非问卷式逐项收集最重要的先问边问边补齐。需要覆盖的信息维度包括维度要弄清的问题用户问题这个功能解决什么问题谁正在经历它目标用户服务哪些用户群体成功指标我们如何知道它起作用了约束条件技术约束、时间线、法规要求、依赖关系先例之前尝试过吗已有解决方案吗第 3 步从已连接工具拉取上下文Pull Context from Connected Tools这是 write-spec 区别于纯手工写 PRD 的关键能力。插件采用工具类别占位符机制——技能文档中出现的~~project tracker、~~knowledge base、~~design等记号代表用户实际接入的对应类别 MCP 服务器。根据 product-management/CONNECTORS.md本插件预配置的类别包括类别占位符内置服务器其他可选项目跟踪器~~project trackerLinear、Asana、monday.com、ClickUp、Atlassian (Jira/Confluence)Shortcut、Basecamp知识库~~knowledge baseNotionConfluence、Guru、Coda设计~~designFigmaSketch、Adobe XD产品分析~~product analyticsAmplitude、PendoMixpanel、Heap、FullStory用户反馈~~user feedbackIntercomProductboard、Canny、UserVoice各类别接入后的具体拉取行为如下项目跟踪器搜索相关 ticket、epic 或功能拉取已有需求与验收标准识别对其他工作项的依赖知识库搜索相关研究文档、历史规格或设计文档提取用户研究结论查找会议纪要与决策记录设计拉取相关 mockup、线框图或设计探索搜索与该功能相关的设计系统组件。关键原则如果这些工具未连接就完全基于用户提供的信息工作不要要求用户去连接工具直接利用现有信息继续推进。第 4 步生成 PRDGenerate the PRD产出包含 Problem Statement、Goals、Non-Goals、User Stories、Requirements、Open Questions、Timeline Considerations 等标准章节的结构化 PRD每个章节的写作规范见下文PRD 结构。第 5 步评审与迭代Review and Iterate生成 PRD 后询问用户是否有需要调整的章节主动提出对特定章节进行扩展提议创建后续产物设计简报design brief、工程 ticket 拆解engineering ticket breakdown、干系人汇报稿stakeholder pitch。这里与插件生态形成闭环——后续产物可以继续调用本插件的其他技能例如把研究综合为 synthesize-research 的输入、把同步动作交给 stakeholder-update规模估算则可参考 sprint-planning 的容量规划模板。三、PRD 结构八个章节的写作规范1. Problem Statement问题陈述用 2-3 句话描述用户问题说明谁在经历该问题、频率如何说明不解决的代价用户痛点、业务影响、竞争风险必须以证据为基础用户研究、支持数据、指标或客户反馈。2. Goals目标列出 3-5 个具体、可衡量的结果每个目标都要回答我们怎么知道它成功了区分用户目标用户获得什么与业务目标公司获得什么目标是结果而非产出例如 reduce time to first value by 50%缩短首次价值时间 50%而不是 build onboarding wizard做一个引导向导。3. Non-Goals非目标列出 3-5 个本功能明确不做的事指出本版本范围外的邻近能力对每个非目标简要说明为何排除影响不足、过于复杂、独立立项、时机未到非目标的作用实现阶段防止范围蔓延并向干系人设定预期。4. User Stories用户故事采用标准格式As a [user type], I want [capability] so that [benefit]作为某类用户我想拥有某能力以便获得某收益。书写准则见下一节。5. Requirements需求按 Must-Have (P0)、Nice-to-Have (P1)、Future Considerations (P2) 三级分类每项需求都需附验收标准。6. Open Questions开放问题列出实现前或实现中需要解答的问题为每个问题标注由谁回答engineering、design、legal、data、stakeholder区分阻塞性问题必须开工前回答与非阻塞性问题可在实现中解决。7. Timeline Considerations时间线考虑硬性截止日期合同承诺、活动、合规日期对其他团队工作或发布节奏的依赖若功能过大无法一次发布给出建议的分期方案phasing。四、用户故事写作INVEST 标准与常见误区优质用户故事的六条标准INVEST标准含义Independent独立可以单独开发和交付Negotiable可协商细节可以讨论故事不是合同Valuable有价值给用户而非仅团队交付价值Estimable可估算团队能大致估算工作量Small足够小一个 sprint/迭代内可完成Testable可测试有明确的验证方式用户故事常见错误过于模糊As a user, I want the product to be faster——到底什么该更快预设解决方案As a user, I want a dropdown menu——应描述需求而非 UI 控件没有收益As a user, I want to click a button——为什么要达成什么过于庞大As a user, I want to manage my team——应拆分为具体能力内部视角As the engineering team, we want to refactor the database——这是任务不是用户故事。官方示例SSO 场景As a team admin, I want to configure SSO for my organization so that my team members can log in with their corporate credentialsAs a team member, I want to be automatically redirected to my companys SSO login so that I do not need to remember a separate passwordAs a team admin, I want to see which members have logged in via SSO so that I can verify the rollout is working注意其中对用户类型的具体化team admin 而非 user、对能力的描述聚焦要达成什么而非怎么做、以及收益句明确解释价值所在。五、需求分级P0/P1/P2 与 MoSCoW 框架技能文档同时提供了两套可互为参考的分级体系。P0 / P1 / P2 分级PRD 内嵌Must-Have (P0)功能没有这些就无法发布代表功能的最小可用版本。判断标准是自问如果砍掉这个功能还能解决核心问题吗若不能它就是 P0。Nice-to-Have (P1)能显著改善体验但没有它们核心用例依然成立。这些通常会成为发布后的快速跟进项fast follow-ups。Future Considerations (P2)v1 明确不做但设计上要为未来留出空间。记录 P2 可以防止意外做出阻碍未来的架构决策。每项需求还应写出清晰无歧义的预期行为描述、附带验收标准、注明技术考量或约束、标记对其他团队或系统的依赖。MoSCoW 框架Must have没有则功能不可行不可商量Should have对发布重要但不关键高优先级快速跟进Could have时间允许则做砍掉也不会推迟交付Wont have (this time)明确不做未来版本可能 revisit。分级技巧对 P0 要严格must-have 清单越紧凑交付和学习越快如果一切都是 P0那就没有 P0——质疑每个 must-have没有它我们真的不发布吗P1 应该是你确信很快会做的而不是愿望清单P2 是架构保险——即使现在不构建它们也引导设计决策。六、成功指标前置指标、滞后指标与目标设定Leading Indicators前置指标——发布后数天到数周内快速变化Adoption rate采用率符合条件的用户中尝试该功能的百分比Activation rate激活率完成核心动作的用户百分比Task completion rate任务完成率成功达成目标的用户百分比Time to complete完成时间核心工作流耗时Error rate错误率用户遇到错误或死路的频率Feature usage frequency使用频率用户回访使用该功能的频率。Lagging Indicators滞后指标——数周到数月才显现Retention impact留存影响该功能是否改善用户留存Revenue impact收入影响是否驱动升级、扩张或新收入NPS / satisfaction change满意度变化是否改善用户对产品的感受Support ticket reduction工单减少是否降低支持负载Competitive win rate竞争胜率是否帮助赢得更多订单。目标设定Setting Targets目标要具体50% adoption within 30 days而非 high adoption基于同类功能、行业基准或明确假设设定基线同时设定 success成功阈值与 stretch挑战目标定义测量方法用什么工具、什么查询、什么时间窗口明确评估时点发布后 1 周、1 个月还是 1 个季度。七、验收标准Given/When/Then 与清单两种写法Given/When/Then 格式Given [前置条件或上下文] When [用户采取的动作] Then [预期结果]官方示例SSOGiven the admin has configured SSO for their organizationWhen a team member visits the login pageThen they are automatically redirected to the organizations SSO provider清单格式Admin can enter SSO provider URL in organization settingsTeam members see Log in with SSO button on login pageSSO login creates a new account if one does not existSSO login links to existing account if email matchesFailed SSO attempts show a clear error message验收标准书写技巧覆盖 happy path、错误情形与边界情形描述预期行为而非实现细节包含不应该发生什么负面测试用例每条标准应可独立测试避免模糊词汇fast、user-friendly、intuitive——要明确定义其具体含义。八、范围管理识别与阻止范围蔓延范围蔓延的典型信号规格批准后需求不断追加小改动累积成显著更大的项目团队在构建没用户要求的功能顺手做个……发布日期在没有明确重定范围的情况下不断推迟干系人不断加需求却不移除任何东西。阻止范围蔓延的手段每份规格都写明显式非目标要求任何范围增加都伴随范围移除或时间线延长在规格中清晰区分 v1 与 v2对照原始问题陈述复查规格——每部分是否都服务于它给调查时间盒time-box如果 2 天内搞不清 X就砍掉它为范围外的好点子建立 parking lot停车区供未来取用。九、输出格式与 Tips输出格式使用带清晰标题的 Markdown。保持文档可快速扫读——忙碌的干系人应当只读标题和加粗文字就能抓住要点。技能 Tips原文要点对范围要有主见一个紧凑、定义清晰的规格好过一个铺开但模糊的规格如果用户的想法对一个规格来说太大建议拆成分阶段先规格化第一阶段成功指标必须具体可衡量而非模糊表述如 improve user experience非目标与目标同等重要——它们防止实现阶段的范围蔓延开放问题应当是真正开放的——不要把能从上下文回答的问题写进去。十、在仓库生态中的纵深理解与其他命令/技能的衔接write-spec 并非孤立存在。从 product-management/README.md 的示例工作流可以看到完整的 PRD 编写会话通常这样展开You: /write-spec Claude: What feature or problem are you speccing out? You: We need to add SSO support for enterprise customers Claude: [Asks about target users, constraints, success metrics] Claude: [Generates full PRD with problem statement, user stories, requirements, success metrics, open questions]而 brainstorm 命令 在会话结束时也明确提供衔接入口Want me to turn the top idea into a one-pager? → 指向/write-spec说明 write-spec 天然承接头脑风暴的输出。反之write-spec 生成的 PRD 又可为 sprint-planning 提供 backlog 输入——该技能要求Every item has a clear owner and clear acceptance criteria正是 write-spec 输出结构所保证的。成功指标的跨技能一致性write-spec 中定义的 North Star / 前置指标 / 滞后指标体系与同插件 metrics-review 技能 中的产品指标层级North Star → L1 健康指标 → L2 诊断指标完全对齐。也就是说write-spec 在立项时写下的指标可以在后续的周度/月度/季度 metrics review 中直接复用同一套层级与目标实现规格即度量基线的闭环。这也解释了为何技能文档强调目标必须可测量——它最终要落到 metrics-review 的 Scorecard 表格里被持续追踪。工具无关性的设计理念从 CONNECTORS.md 可以看出整个插件体系是**工具无关tool-agnostic**的工作流按类别项目跟踪器、知识库、设计等描述而不是绑定具体产品.mcp.json只是预配置了特定 MCP 服务器同类别的任何 MCP 服务器都可以工作。这意味着 write-spec 技能中~~project tracker的搜索逻辑无论用户接的是 Linear、Asana 还是 Jira 都同样成立——这是该技能可在不同企业技术栈间平滑迁移的底层保证。十一、最佳实践清单一次高质量 PRD 会话的检查项综合技能文档全文一次成功的/write-spec会话应满足信息收集是对话式的——最重要的先问边聊边补而非一次倾倒所有问题上下文优先来自已连接工具——项目跟踪器、知识库、设计工具能提供比口头描述更扎实的证据每个章节都有明确产出标准——问题陈述有证据、目标可衡量、非目标有理由、故事按 INVEST 标准、需求分级并附验收标准、开放问题标定负责人、时间线覆盖硬期限与依赖范围是刻意管理的——显式非目标 停车区 时间盒任何追加需求都要有对应移除产出可快速扫读——标题与加粗承载主干信息忙碌的干系人 30 秒内能抓住要点收尾时主动提议迭代与后续产物——扩展章节、拆 ticket、出设计简报或干系人汇报稿。这些规范全部可在 write-spec 技能源文件 中逐一核对并可通过安装 product-management 插件 后在 Cowork 或 Claude Code 中实际体验。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 knowledge-work-plugins 产品管理插件 write-spec 技能：从问题陈述到结构化 PRD 的完整实战指南
knowledge-work-plugins 产品管理插件 write-spec 技能从问题陈述到结构化 PRD 的完整实战指南【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins本指南以 write-spec 技能文档 为骨架结合 knowledge-work-plugins 仓库中 product-management 插件的连接器配置、命令体系与配套技能系统讲解如何在 Claude Cowork 中把一句模糊的想法或用户请求逐步转化为一份可直接驱动研发、设计、数据团队落地的产品需求文档PRD。读完本文你将掌握 write-spec 的五步工作流、PRD 八个标准章节的写作规范、INVEST 用户故事标准、MoSCoW/P0-P1-P2 需求分级方法、前置/滞后指标定义以及防止范围蔓延的实操手段。一、write-spec 是什么插件的定位与使用方式write-spec 是 product-management 插件 中负责把想法变成规格的核心技能。在插件的完整 PM 工作流里它与/brainstorm头脑风暴、/roadmap-update路线图、/synthesize-research研究综合、/stakeholder-update干系人同步、/competitive-brief竞品简报等命令共同覆盖了从创意产生、需求定义到落地跟进的全链路而 write-spec 正是其中将模糊输入转化为可执行文档的关键一环。从技能文件头部的 frontmatter 可以看出它的适用时机name: write-spec description: Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec. argument-hint: feature or problem statement即当需要把模糊想法或用户请求转成结构化文档、为功能划定目标与非目标、定义成功指标和验收标准、或把大需求拆分成分阶段规格时都应当触发该技能。它既支持作为独立技能被自动调用也支持通过斜杠命令显式触发/write-spec $ARGUMENTS例如在会话中直接输入/write-spec We need to add SSO support for enterprise customers或在触发后回答 Claude 的追问。安装该插件后Claude Code 下使用claude plugin install product-managementknowledge-work-pluginsCowork 中可直接从插件市场安装技能会在相关场景下自动生效。二、五步工作流从想法到 PRD 的完整链路技能文档定义了一个五步渐进式工作流核心原则是对话式收集信息绝不一次性倾倒问题清单。第 1 步理解功能Understand the Feature向用户询问要规格化的对象接受以下任一输入形态功能名称如 SSO support问题陈述如 Enterprise customers keep asking for centralized auth用户请求如 Users want to export their data as CSV模糊想法如 We should do something about onboarding drop-off第 2 步收集上下文Gather Context以对话方式而非问卷式逐项收集最重要的先问边问边补齐。需要覆盖的信息维度包括维度要弄清的问题用户问题这个功能解决什么问题谁正在经历它目标用户服务哪些用户群体成功指标我们如何知道它起作用了约束条件技术约束、时间线、法规要求、依赖关系先例之前尝试过吗已有解决方案吗第 3 步从已连接工具拉取上下文Pull Context from Connected Tools这是 write-spec 区别于纯手工写 PRD 的关键能力。插件采用工具类别占位符机制——技能文档中出现的~~project tracker、~~knowledge base、~~design等记号代表用户实际接入的对应类别 MCP 服务器。根据 product-management/CONNECTORS.md本插件预配置的类别包括类别占位符内置服务器其他可选项目跟踪器~~project trackerLinear、Asana、monday.com、ClickUp、Atlassian (Jira/Confluence)Shortcut、Basecamp知识库~~knowledge baseNotionConfluence、Guru、Coda设计~~designFigmaSketch、Adobe XD产品分析~~product analyticsAmplitude、PendoMixpanel、Heap、FullStory用户反馈~~user feedbackIntercomProductboard、Canny、UserVoice各类别接入后的具体拉取行为如下项目跟踪器搜索相关 ticket、epic 或功能拉取已有需求与验收标准识别对其他工作项的依赖知识库搜索相关研究文档、历史规格或设计文档提取用户研究结论查找会议纪要与决策记录设计拉取相关 mockup、线框图或设计探索搜索与该功能相关的设计系统组件。关键原则如果这些工具未连接就完全基于用户提供的信息工作不要要求用户去连接工具直接利用现有信息继续推进。第 4 步生成 PRDGenerate the PRD产出包含 Problem Statement、Goals、Non-Goals、User Stories、Requirements、Open Questions、Timeline Considerations 等标准章节的结构化 PRD每个章节的写作规范见下文PRD 结构。第 5 步评审与迭代Review and Iterate生成 PRD 后询问用户是否有需要调整的章节主动提出对特定章节进行扩展提议创建后续产物设计简报design brief、工程 ticket 拆解engineering ticket breakdown、干系人汇报稿stakeholder pitch。这里与插件生态形成闭环——后续产物可以继续调用本插件的其他技能例如把研究综合为 synthesize-research 的输入、把同步动作交给 stakeholder-update规模估算则可参考 sprint-planning 的容量规划模板。三、PRD 结构八个章节的写作规范1. Problem Statement问题陈述用 2-3 句话描述用户问题说明谁在经历该问题、频率如何说明不解决的代价用户痛点、业务影响、竞争风险必须以证据为基础用户研究、支持数据、指标或客户反馈。2. Goals目标列出 3-5 个具体、可衡量的结果每个目标都要回答我们怎么知道它成功了区分用户目标用户获得什么与业务目标公司获得什么目标是结果而非产出例如 reduce time to first value by 50%缩短首次价值时间 50%而不是 build onboarding wizard做一个引导向导。3. Non-Goals非目标列出 3-5 个本功能明确不做的事指出本版本范围外的邻近能力对每个非目标简要说明为何排除影响不足、过于复杂、独立立项、时机未到非目标的作用实现阶段防止范围蔓延并向干系人设定预期。4. User Stories用户故事采用标准格式As a [user type], I want [capability] so that [benefit]作为某类用户我想拥有某能力以便获得某收益。书写准则见下一节。5. Requirements需求按 Must-Have (P0)、Nice-to-Have (P1)、Future Considerations (P2) 三级分类每项需求都需附验收标准。6. Open Questions开放问题列出实现前或实现中需要解答的问题为每个问题标注由谁回答engineering、design、legal、data、stakeholder区分阻塞性问题必须开工前回答与非阻塞性问题可在实现中解决。7. Timeline Considerations时间线考虑硬性截止日期合同承诺、活动、合规日期对其他团队工作或发布节奏的依赖若功能过大无法一次发布给出建议的分期方案phasing。四、用户故事写作INVEST 标准与常见误区优质用户故事的六条标准INVEST标准含义Independent独立可以单独开发和交付Negotiable可协商细节可以讨论故事不是合同Valuable有价值给用户而非仅团队交付价值Estimable可估算团队能大致估算工作量Small足够小一个 sprint/迭代内可完成Testable可测试有明确的验证方式用户故事常见错误过于模糊As a user, I want the product to be faster——到底什么该更快预设解决方案As a user, I want a dropdown menu——应描述需求而非 UI 控件没有收益As a user, I want to click a button——为什么要达成什么过于庞大As a user, I want to manage my team——应拆分为具体能力内部视角As the engineering team, we want to refactor the database——这是任务不是用户故事。官方示例SSO 场景As a team admin, I want to configure SSO for my organization so that my team members can log in with their corporate credentialsAs a team member, I want to be automatically redirected to my companys SSO login so that I do not need to remember a separate passwordAs a team admin, I want to see which members have logged in via SSO so that I can verify the rollout is working注意其中对用户类型的具体化team admin 而非 user、对能力的描述聚焦要达成什么而非怎么做、以及收益句明确解释价值所在。五、需求分级P0/P1/P2 与 MoSCoW 框架技能文档同时提供了两套可互为参考的分级体系。P0 / P1 / P2 分级PRD 内嵌Must-Have (P0)功能没有这些就无法发布代表功能的最小可用版本。判断标准是自问如果砍掉这个功能还能解决核心问题吗若不能它就是 P0。Nice-to-Have (P1)能显著改善体验但没有它们核心用例依然成立。这些通常会成为发布后的快速跟进项fast follow-ups。Future Considerations (P2)v1 明确不做但设计上要为未来留出空间。记录 P2 可以防止意外做出阻碍未来的架构决策。每项需求还应写出清晰无歧义的预期行为描述、附带验收标准、注明技术考量或约束、标记对其他团队或系统的依赖。MoSCoW 框架Must have没有则功能不可行不可商量Should have对发布重要但不关键高优先级快速跟进Could have时间允许则做砍掉也不会推迟交付Wont have (this time)明确不做未来版本可能 revisit。分级技巧对 P0 要严格must-have 清单越紧凑交付和学习越快如果一切都是 P0那就没有 P0——质疑每个 must-have没有它我们真的不发布吗P1 应该是你确信很快会做的而不是愿望清单P2 是架构保险——即使现在不构建它们也引导设计决策。六、成功指标前置指标、滞后指标与目标设定Leading Indicators前置指标——发布后数天到数周内快速变化Adoption rate采用率符合条件的用户中尝试该功能的百分比Activation rate激活率完成核心动作的用户百分比Task completion rate任务完成率成功达成目标的用户百分比Time to complete完成时间核心工作流耗时Error rate错误率用户遇到错误或死路的频率Feature usage frequency使用频率用户回访使用该功能的频率。Lagging Indicators滞后指标——数周到数月才显现Retention impact留存影响该功能是否改善用户留存Revenue impact收入影响是否驱动升级、扩张或新收入NPS / satisfaction change满意度变化是否改善用户对产品的感受Support ticket reduction工单减少是否降低支持负载Competitive win rate竞争胜率是否帮助赢得更多订单。目标设定Setting Targets目标要具体50% adoption within 30 days而非 high adoption基于同类功能、行业基准或明确假设设定基线同时设定 success成功阈值与 stretch挑战目标定义测量方法用什么工具、什么查询、什么时间窗口明确评估时点发布后 1 周、1 个月还是 1 个季度。七、验收标准Given/When/Then 与清单两种写法Given/When/Then 格式Given [前置条件或上下文] When [用户采取的动作] Then [预期结果]官方示例SSOGiven the admin has configured SSO for their organizationWhen a team member visits the login pageThen they are automatically redirected to the organizations SSO provider清单格式Admin can enter SSO provider URL in organization settingsTeam members see Log in with SSO button on login pageSSO login creates a new account if one does not existSSO login links to existing account if email matchesFailed SSO attempts show a clear error message验收标准书写技巧覆盖 happy path、错误情形与边界情形描述预期行为而非实现细节包含不应该发生什么负面测试用例每条标准应可独立测试避免模糊词汇fast、user-friendly、intuitive——要明确定义其具体含义。八、范围管理识别与阻止范围蔓延范围蔓延的典型信号规格批准后需求不断追加小改动累积成显著更大的项目团队在构建没用户要求的功能顺手做个……发布日期在没有明确重定范围的情况下不断推迟干系人不断加需求却不移除任何东西。阻止范围蔓延的手段每份规格都写明显式非目标要求任何范围增加都伴随范围移除或时间线延长在规格中清晰区分 v1 与 v2对照原始问题陈述复查规格——每部分是否都服务于它给调查时间盒time-box如果 2 天内搞不清 X就砍掉它为范围外的好点子建立 parking lot停车区供未来取用。九、输出格式与 Tips输出格式使用带清晰标题的 Markdown。保持文档可快速扫读——忙碌的干系人应当只读标题和加粗文字就能抓住要点。技能 Tips原文要点对范围要有主见一个紧凑、定义清晰的规格好过一个铺开但模糊的规格如果用户的想法对一个规格来说太大建议拆成分阶段先规格化第一阶段成功指标必须具体可衡量而非模糊表述如 improve user experience非目标与目标同等重要——它们防止实现阶段的范围蔓延开放问题应当是真正开放的——不要把能从上下文回答的问题写进去。十、在仓库生态中的纵深理解与其他命令/技能的衔接write-spec 并非孤立存在。从 product-management/README.md 的示例工作流可以看到完整的 PRD 编写会话通常这样展开You: /write-spec Claude: What feature or problem are you speccing out? You: We need to add SSO support for enterprise customers Claude: [Asks about target users, constraints, success metrics] Claude: [Generates full PRD with problem statement, user stories, requirements, success metrics, open questions]而 brainstorm 命令 在会话结束时也明确提供衔接入口Want me to turn the top idea into a one-pager? → 指向/write-spec说明 write-spec 天然承接头脑风暴的输出。反之write-spec 生成的 PRD 又可为 sprint-planning 提供 backlog 输入——该技能要求Every item has a clear owner and clear acceptance criteria正是 write-spec 输出结构所保证的。成功指标的跨技能一致性write-spec 中定义的 North Star / 前置指标 / 滞后指标体系与同插件 metrics-review 技能 中的产品指标层级North Star → L1 健康指标 → L2 诊断指标完全对齐。也就是说write-spec 在立项时写下的指标可以在后续的周度/月度/季度 metrics review 中直接复用同一套层级与目标实现规格即度量基线的闭环。这也解释了为何技能文档强调目标必须可测量——它最终要落到 metrics-review 的 Scorecard 表格里被持续追踪。工具无关性的设计理念从 CONNECTORS.md 可以看出整个插件体系是**工具无关tool-agnostic**的工作流按类别项目跟踪器、知识库、设计等描述而不是绑定具体产品.mcp.json只是预配置了特定 MCP 服务器同类别的任何 MCP 服务器都可以工作。这意味着 write-spec 技能中~~project tracker的搜索逻辑无论用户接的是 Linear、Asana 还是 Jira 都同样成立——这是该技能可在不同企业技术栈间平滑迁移的底层保证。十一、最佳实践清单一次高质量 PRD 会话的检查项综合技能文档全文一次成功的/write-spec会话应满足信息收集是对话式的——最重要的先问边聊边补而非一次倾倒所有问题上下文优先来自已连接工具——项目跟踪器、知识库、设计工具能提供比口头描述更扎实的证据每个章节都有明确产出标准——问题陈述有证据、目标可衡量、非目标有理由、故事按 INVEST 标准、需求分级并附验收标准、开放问题标定负责人、时间线覆盖硬期限与依赖范围是刻意管理的——显式非目标 停车区 时间盒任何追加需求都要有对应移除产出可快速扫读——标题与加粗承载主干信息忙碌的干系人 30 秒内能抓住要点收尾时主动提议迭代与后续产物——扩展章节、拆 ticket、出设计简报或干系人汇报稿。这些规范全部可在 write-spec 技能源文件 中逐一核对并可通过安装 product-management 插件 后在 Cowork 或 Claude Code 中实际体验。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考