prd

prd — 产品的战略层

它会访谈操作者，并产出产品的战略定义：愿景、问题、用户、范围、竞争对手、机会、未决问题和术语表。它是进入这套方法的入口——规格说明由此而来。

它始终写入大脑中已加载产品节点的 context/，绝不会写入正文仓库。 节点头部 repo: 中声明的仓库就是正文：规格说明、技术决策、实际构建成果。战略层位于头部，而不在正文中。

访谈依据 .agents/skills/grill/SKILL.md#method 中的方法施加压力：只引用该标题，不复制内容。对方法的任何更改都只在该处进行一次。

它产出的文件

这些文件会放入已加载产品节点的 context/。如果节点尚无 context/，则先创建 README.md，其余文件会随着访谈完成逐步生成。

文件	回答的问题
README.md	索引：产品是什么、各文件按什么顺序填写、当前状态
vision.md	最终系统是什么样、要发展到什么程度
problem.md	它解决什么问题、为谁解决、为什么是现在、如何判断是否奏效
users.md	它卖给谁、他们今天用什么替代方案
scope.md	它不做什么、不卖给谁、硬性约束、首个版本包含什么
competitors.md	它与什么竞争、有何不同
opportunities.md	可能值得做但尚未决定的事项
open-questions.md	尚待决定的事项——这是动态文件，随着事项敲定，内容会逐渐清空；问题位于其中的 [!QUESTION] 提示框内
glossary.md	该领域的术语

此列表中的任何文件都不会写入正文仓库。如果完成某个部分必须修改正文仓库或解析器，该工具不会执行：它会说明情况并停止——这是引入它的规格说明所规定的停止条件，并非本次会话的决定。

如果没有产品节点，这八个通用文件名不会散落在会话启动时所在的文件夹中，以免覆盖用户已有文件；它们会放入当前文件夹下的 product-context/ 文件夹：product-context/vision.md、product-context/problem.md、product-context/users.md、product-context/scope.md、product-context/competitors.md、product-context/opportunities.md、product-context/open-questions.md、product-context/glossary.md。如果已加载产品节点，则目标位置仍与上述完全相同，为 context/。

KPI 树不属于这里：它归另一工具的指标简报所有；如果它已经存在，此技能会引用它，但不会生成它。

阶段 1 — 提问前先阅读大脑已有的信息

第一个问题之前：

1. 确认已加载的产品节点及其 context/——如果不存在，则在本次访谈中创建。
2. 完整阅读 context/ 中已有的文件。这是一个增量过程：分阶段完成；已填写的部分绝不会在未事先说明的情况下被覆盖。
3. 阅读所属组织的上下文；如果存在，也要阅读相关的定期研究——它位于节点的 research/ 中，与 context/ 并列。
4. 告知操作者你读了什么，以及据此可以自行填写哪些部分。只有之后才开始访谈，且仅针对缺失内容提问——不询问系统已有文字说明的内容。

阶段 2 — 访谈

问题分轮提出，具体方式遵循 .agents/skills/grill/SKILL.md#method 中的定义；每个问题都要附上一句话，说明该部分为何会影响决策。没有这句话，问题就会显得像官僚流程。

逼出真相的六个问题

机会与业务阶段，先于解决方案：

1. 有什么最有力的证据表明有人想要它？不是兴趣，而是行为。
2. 他们现在用什么来解决这个问题？如果答案是“什么都不用”，那他们为什么即使没有这个也过得很好？
3. 给我说一个具体的人。他的职位是什么？如果他不解决这个问题，会有什么后果？
4. 这个星期就有人愿意付钱的最小版本是什么？
5. 你观察别人使用它或尝试解决问题时，有什么让你感到意外？
6. 三年后，这会变得更有必要，还是更没必要？

研究阶段

结论不是凭空编造的：如果尚未进行研究，就会如实说明，并提供相应的探索工具。问题涵盖目标群体、明确排除的对象，以及操作者今天已经在用的替代方案。

解决方案阶段

讨论要构建什么之前，先质疑前提：这是正确的问题吗？如果什么都不做会怎样？是否已有现成方案可以解决？只有之后才讨论愿景、拆分方案、不做什么及其重新启动条件、硬性约束，以及各项假设及其失效条件。

如何施加压力

.agents/skills/grill/SKILL.md#method 中的方法决定何时反问、进行几轮，以及如何应对第二次抵触。这里不再重复：直接应用该方法。

替代方案阶段，必须进行

确定解决方案之前，先提出 2 或 3 条路径，并说明每条路径的投入、风险，以及会复用哪些现有成果：

• 最小可发布方案 — 这个星期就能发布的最小版本，
• 最经得起发展的方案 — 产品发展壮大时需要返工最少的方案，
• 重新界定问题的侧向方案 — 一条不只是“同样的东西，做得更小”的出路。

由操作者选择其中一条。没有这个阶段，文档记录的只是第一个想法，而不是最好的方案。

明确缺口规则

只有操作者明确决定不回答时，才记录缺口，并且始终注明由谁填补。塞满缺口的文件不是交付成果，而是伪装成完整内容的失败。如果出现缺口是因为从未询问过相关部分，那就不算缺口，而是尚未完成的工作，应继续访谈。

写入前先展示

修改任何文件之前，先向操作者准确展示将要写入的内容——展示正文，而不是摘要——并等待其确认。只写入访谈涉及的文件；已经完整的文件不覆盖。某个术语表词条若在一轮中得到操作者的“是”确认，其准确文本此前已经展示过：按方法要求，确认后就写入，不再重复展示。

最终结论

结束时必须明确给出以下三种结论之一：

• 已完成 — 信息足以编写规格说明。
• 基本完成，但仍有保留 — 可以继续推进，并列出尚待解决的问题。
• 缺少上下文 — 说明哪个文件尚未完成，以及完成它需要什么。

最低要求门槛：如果 glossary.md、scope.md 或主体架构仍为空，就暂时不能据此产出规格说明。必须明确说明，绝不能留待之后才发现。

目标位置

此技能会在生成交付物之前解析目标位置，而不是之后。三种情况， 两个目标位置：

• 已加载产品节点：交付物写入该节点的 research/<YYYY-MM-DD>-<name>.md。
• 有知识库，但没有产品节点——尚无工作区，或有工作区但没有产品节点：交付物写入当前文件夹中的文件。
• 完全没有知识库：交付物写入当前文件夹中的文件。

没有产品节点时，文件仍会写入当前文件夹。结束消息只写刚刚写入的路径，然后结束——这是此技能的正常结束方式，不是需要特别说明的异常情况。

此技能绝不会询问要使用哪个目标位置，也绝不会另设第三个目标位置。

此技能包的其余部分每次安装一个技能。先检查 .agents/skills/，再检查 .claude/skills/（同一个技能同时存在于两处时只算一次），并且只提供尚未安装的技能——每个会话只提供一次：首次在该会话中结束此技能时提供，之后结束同一或其他交付物时不再提供：

• grill — npx skills add pedroromeroluna/ai-first-product-skills --skill grill

一次安装整个技能包：npx skills add pedroromeroluna/ai-first-product-skills。此命令会安装技能包提供的所有技能；上面列出的任何技能都需通过指定名称来安装。