编写并维护能培养判断力的产品管理技能

## 保留理由和示例，培养用户的判断力 ### 服务于双重受众 产品管理技能应帮助从业者完成有用的工作，并提升专业能力。每项技能都应同时面向正在培养判断力的人和执行工作流的智能体。不得以牺牲一方为代价来优化另一方。 应充分呈现工作流背后的推理，使建议可信、可解释且可迁移。用户不仅应收到完成的成果物，还应理解某种方法为何有效。 ### 保护学习结构 - 如果缩短说明会删去作出合理决策所需的推理，就不得缩短。 - 保留明确的反模式，因为它们能教会用户在实际情境中识别并避开什么。 - 使用能展示推理过程的示例，而不只是展示最终成果。 - 专业术语首次出现时就给出定义，并明确说明权衡取舍。 - 在不剥离辅导层的前提下，保持工作流实用且可供智能体执行。 提高效率时，应先去除重复、赘述和无关背景，再考虑删减经验、示例或失败模式。如果无法确定某段内容是理解所需的支撑还是杂乱信息，应保留它，直到弄清其作用。 ### 在不同情境中展示质量 至少包含一个具体示例，展示证据如何促成决策。对于充分完善的技能，应添加可复用模板，以及来自两个具有实质差异的商业情境的完整示例，例如软件服务和实体业务或运营型业务。使用虚构的组织和数据。 ## 每个技能单独放一个文件夹，不手动修改自动生成的列表 ### 将规范源与派生成果分开 将每项技能放在命名方式一致的独立文件夹中，其中包含一份规范技能文档，以及所有该技能专用的辅助资源或脚本。将可复用的编排命令与各项技能分开存放。把研究资料、用户文档、预览应用和发布成果物分别维护在归属明确的不同区域。 将生成的目录、索引、软件包副本和分发包视为派生成果物。应从规范源重新生成它们，而不是直接编辑。 技能文件夹名称使用小写kebab-case，并确保文件夹名称与技能声明的名称同步。尽可能保持路径稳定；仅在必要时重命名技能，并随后更新所有引用。 ### 遵守归属边界 编辑内容前，确认该内容归哪个代码库或工作区所有。共享库、产品专用手册和分发代码库可能相互引用，但各自拥有不同的权威来源。应在归属位置工作；除非任务明确改变该边界，否则应将其他位置视为只读参考。 不要仅凭熟悉的目录名称推断结构。在作出结构决策前，先使用该代码库自身的定义、贡献规则、脚本和现有示例。 ### 寻找最具体的能力 在自行编写产品管理指导前，先检查可用技能并选择最具体的匹配项。常见领域包括探索、Jobs to Be Done、用户画像、产品战略、优先级排序、路线图、需求文档、用户故事、验收标准、人工智能产品工作、智能体工作流和利益相关者协调。 应将这些内容视为辅导和成果物生成工作流，而不是一般的软件工程任务。 ## 在技能中写入示例和常见错误，每次只问一个问题 ### 使用一致的文档契约 为每项技能提供清晰的顺序，例如目的、输入、核心概念、应用、示例、常见陷阱和参考资料。frontmatter中应包含name、description和type字段。当目标平台规定这些限制时，name应控制在64个字符以内，description应控制在200个字符以内。 使用清晰的Markdown标题和短段落。为围栏式代码块添加语言标识符。文字应简洁并有明确立场，但不得牺牲必要的推理、条件或示例。 ### 将输入视为邀请，而不是门槛 输入部分应以通俗语言说明用户可以提供哪些内容，并包含一个调用示例。请求中已提供的信息应视为已经回答。 允许用户仅提供部分初始输入或完全不提供初始输入。说明引导式流程将如何收集缺失信息，而不是阻止用户继续。避免使用在不受支持的环境中会按原样显示的运行时专用占位符或模板语法。 ### 有意识地设计交互流程 对于交互式技能： - 每次提出一个问题，或使用小而连贯的问题组。 - 让每个回答影响下一个问题。 - 提供带编号且符合当前情境的后续步骤建议。 - 同时允许按编号选择和自定义输入。 - 当用户的选择改变了相关路径时，相应调整工作流。 确保技能自包含，无需隐藏假设即可由智能体使用。至少包含一个明确的反模式，并解释其失败原因。 ## 分享前用技能库自带的工具检查内容和链接 ### 使用技能库自身的验证路径 优先使用代码库中已有文档说明的发现、验证、打包和全库测试工具，而不是临时检查。提交更改前，使用文件发现和针对性的引用搜索来验证技能位置和交叉引用。 验证规范技能路径能够解析、元数据有效、必需部分齐全、示例和参考资料准确，并且链接保持一致。没有自动化测试时，应手动完成这些检查，而不是声称未经验证的成功。 通过受维护的入口点运行软件包构建器和目录生成器。如果更改了预览应用，应执行相关的本地预览路径并验证其文档。 ### 保持兼容性和自动化安全 遵守平台专用的打包要求，包括在要求时精确匹配文件名大小写。辅助脚本应具有确定性并有文档说明；除非工作流明确要求并管控网络访问，否则脚本不得访问网络。 共享或运行脚本及已打包内容前，应检查其安全性。不得仅因受管理的市场、插件或兼容性文件看似无关就将其移除。不得以编辑生成的发布成果物来代替修复其规范源。 ### 验证真正的权威来源 更改类别、技能类型或软件包结构前，应依据本地标准和相关的规范技能作出决定。相较于个人惯例，应优先采用受维护的验证器和代码库工具提供的证据。 如果所请求的工作属于另一个代码库，应在当前边界停止写入，并将更改指向其归属的源。参考资料可以为工作提供信息，但不能因此成为编辑目标。 ## 改动保持小，发布前按检查清单逐项确认 ### 准备便于审查的贡献 更改应保持小规模、可维护，并限定在所述目的之内。提交主题应使用清晰的祈使句。审查请求应概述更改、链接相关issue、标明技能类型，并指出有实质意义的兼容性或行为变化。 添加或重命名技能时，应更新目录条目、数量、表格、路径和交叉链接。发布前验证所有引用都能够解析。 ### 应用完整的发布检查清单 - 验证规范技能文件夹和元数据。 - 从源重新构建可下载的软件包和生成的目录。 - 确认示例、参考资料和导航链接仍然准确。 - 验证frontmatter语法和所有平台专用的软件包副本。 - 更改预览应用时，更新界面文档和发布说明。 - 检查是否有生成的成果物、无关文件或意外的大范围替换混入更改。 ### 将教育成效作为最终门槛 可发布的技能应具有教育意义、可供智能体执行、自包含且实用。它应包含推理、至少一个完整示例、一个明确的反模式、定义清楚的术语以及可见的权衡取舍。充分完善的技能还应包含可复用模板和来自对比领域的示例。 不得仅为缩短篇幅而删去说明、反模式或示例。只有当技能能产生有用的结果、增强用户的判断力，并在其支持的各类环境中保持可维护性时，才能批准发布。