specsfy-mvp-milestone-interviewer

探索具有开发需求的 MVP

必须完成的准备工作

执行此技能前，必须先在项目根目录加载 $specsfy-setup。如果发生自动交接，请在此步骤前重新加载。复用对话中已确认的根目录；如果 setup 指出有待处理事项，请勿继续。

交互模式

交互模式：perguntas。 提出任何问题前，请阅读并遵循 .specsfy/Spec.md 中的 Contrato de perguntas numeradas。

此技能负责协调 MVP 的输入流程。它将 MVP.md 导入为 milestone 1.0，只选择开发需求，并为每项选定需求创建一个候选 backlog。业务背景仍保留在源文件中。随后，加载负责相应工作的技能，逐一访谈每个 backlog，并且只有在每个阶段的结果得到确认后才继续。

加载可用上下文

1. 读取任何文件前，先解析使用方项目的根目录。如果它是 Git 子模块，通过 git -C <raiz> rev-parse --show-superproject-working-tree 找出超级项目。非空输出只会将这个父级根目录加入搜索范围。不要遍历其他父级目录。

2. 如果使用方根目录中存在常规文件 MVP.md，则读取该文件。如果该文件不存在且根目录是子模块，则读取超级项目中的 MVP.md。本地文件优先。保留所查询的来源，并将其作为已声明的上下文；不要用它取代对方所说的内容。

3. 提出第一个问题前，只运行一次导入器：

   node \
     .agents/skills/specsfy-mvp-milestone-interviewer/scripts/importar_mvp.mjs \
     --root <raiz>
   

   导入器根据 MVP.md 创建 specs/milestones/M01.md，并且只为可归类为可开发的软件交付项的主题创建 backlog 和 spec。愿景、受众、原则、背景、指标以及其他不包含待构建行为的记录，仅保留在 MVP.md 中；不要为它们创建 Inbox，也不要将它们复制到 milestone。 在写入开发文件前，只有在片段中找到明确标签或明确无歧义的表述时，才应用默认值，例如 Problema、 Público、Resultado、Contexto 或客观描述功能的句子。 在 backlog 和输出 JSON 中记录这些默认值及其依据。如果片段不足以支持某项答案，则保留空缺，不要编造一个看似合理的值。每个 backlog 都会保留一段来自导入片段的记录。创建期间，backlog 的状态为 Captured；结束时会附上 Draft spec，并将状态改为 Promoted，指向该 spec；spec 保持 Definition Gate: Pending。如果 M01.md 已存在，不要覆盖任何文件，并告知负责人。

4. 按照相同顺序读取 BRAND.md：先读取使用方根目录中的文件，只有在根目录是子模块时才将超级项目作为备用来源。提问过程中使用该文件来保持语言、受众、价值主张和品牌边界的一致性。不要将其内容复制到派生文件中。

5. 将 MVP.md 记录为导入器所创建的每个 backlog 的来源。不要创建、移动或修改上下文文件。

6. 仅在有助于避免重复或矛盾时，才读取 PROJECT.md、Inboxes、现有 backlog 和 spec。这些内容仍与本次会话中收到的表述保持独立。

7. 将导入器返回的 JSON 视为本次会话的有序 backlog 队列。每个条目都有 title、backlog 和 spec。上下文主题不会进入队列，因为它们仅保留在 MVP.md 中。

导入前，请执行与 Inbox 相同的敏感数据筛查。如果源文件包含凭据、token、私钥或敏感个人数据，不要生成 milestone，也不要在消息中复现这些值。

保留会话

1. 根据收到的第一个主题，生成格式为 DESC-AAAAMMDD-<slug> 的稳定标识。
2. 每次用户回复后，将语义内容记录到另一个 Inbox 中，并沿用同一会话和下一个轮次。如果用户只回复 1、2 或 3，则在构建 --input、--summary、--signals 和其他字段之前，将数字替换为所选选项的完整文本。原始输入可以记入交互追踪，但不得用作 milestone 的上下文。绝不编辑、合并或替换之前的记录。每个为确认而提出的 milestone 假设也要记录到一个 Inbox 中。
3. 每次调用都要提供 --sources：列出所查阅的 MVP.md 和 BRAND.md 路径，即使它们来自超级项目；如果文件缺失，则注明。
4. 每次写入前，应用 $specsfy-01-inbox 的敏感数据筛查。如果筛查阻止记录，则暂停对话，直到收到可安全记录的文本。
5. 使用巴西葡萄牙语编写分析、摘要、元数据和生成的任何 milestone。如果源内容或原始回复使用其他语言，只将其保留为引文，并用巴西葡萄牙语记录其含义。

使用 Inbox 脚本填写记录字段，并添加会话：

node .agents/skills/specsfy-01-inbox/scripts/capturar_inbox.mjs \
  --input "<texto integral da pessoa>" \
  --title "<tema da descoberta>" \
  --session "DESC-AAAAMMDD-<slug>" \
  --turn "<número sequencial>" \
  --sources "<situação de MVP.md e BRAND.md>" \
    [campos de análise da Inbox] [--root <raiz>]

提问前先解决默认项

导入后，按以下顺序处理每个主题：

1. 重新阅读原文段落、自动应用的默认项、待办事项和 milestone M01。
2. MVP 明确声明或导入器明确记录的内容，均视为已确认的回答。
3. 如果只有一种与 MVP 实质兼容的选项，则将其作为显而易见的默认项，并记录规范化后的表述和来源。不要要求确认已经明确的回答。
4. 如果存在多种合理解读、来源冲突或信息缺失，不要默默做出选择。只将这一点转化为下一个编号问题，并优先提供最兼容的建议。
5. 每次收到回复后，重新评估所有字段。不要重复已经回答的问题，也不要提出问题来确认有依据的默认项。

只有当 MVP 没有提供答案、需要做出实际选择，或存在歧义或矛盾时，才提出问题。导入结果必须明确说明哪些内容已自动解决，哪些仍需用户决定。

筛选要开发的内容

加载 $specsfy-02-backlog 前，先对主题分类：

1. 可开发：描述一项功能、页面、流程、集成、数据、自动化、可执行规则或系统行为。创建待办事项和 Draft spec。
2. 背景信息：描述愿景、受众、定位、原则、问题、指标、前提、背景或限制，但未声明软件交付内容。将其保留在 MVP.md 中；不要创建 Inbox、待办事项或 spec。
3. 如果无法确定属于哪类，只有在原文包含可验证的构建动词或对象时，才将其归类为可开发，例如 开发、实现、创建、允许、登记、查询 或 集成。否则，将主题保留为背景信息，并记录原因。

不要仅仅因为产品描述可能有助于未来的实现，就把它转成待办事项。待办事项代表本次导入中将要开发的交付内容。

编排各技能的发现流程

对于导入器返回队列中的每个条目，按以下顺序执行，不得跳过任何职责：

1. 宣布 自动切换：$specsfy-mvp-milestone-interviewer 至 $specsfy-02-backlog；原因：访谈从 MVP 派生的 backlog； 预期结果：经确认答复完善后的 backlog，并针对候选 backlog 路径加载 $specsfy-02-backlog。
2. 首先阅读随该 backlog 提供的 MVP 记录，并据此填写已明确声明的答复。仅针对仍然存在的空缺、歧义或矛盾进行自适应访谈。每轮保留一个问题，在选项文本中明确说明数字选项，并遵守每个领域最多八个问题的限制。
3. 如果 backlog 或访谈表明缺少或含糊不清的待保存信息，则宣布切换至 $specsfy-data-discovery，完成数据访谈，然后以 .specsfy/DATABASE.md 为上下文继续处理 backlog。
4. 每处理完一个 backlog，都要返回此技能，在会话摘要中记录该条目的状态，然后继续处理队列中的下一个 backlog。由于调用此技能是为了导入 MVP，因此每个 backlog 自动完善完成后，都要加载 $specsfy-03-specify 并据此创建一份 Draft spec。 第 10 节必须保留主菜单和导航区域：使用 MVP 中声明的信息；如果缺少相关信息，则标记为 待处理。不得实现代码、执行任务或提升 Definition Gate。
5. 队列处理完毕后，确认每个可开发主题都有 backlog 和 Draft spec，且没有任何上下文主题在 Specsfy 中生成产物。 执行 specsfy milestones sync --project <根目录>，并加载 $specsfy-milestone-governor，以核对 M01 的关联和进度。 自动生成 Draft 不代表获得实现或最终验证的授权。

进行自适应对话

1. 从目标、服务对象和可观察到的问题开始。
2. 每次捕获信息后，重新阅读本次会话的所有 Inboxes。展示一份简短摘要，区分收到的表述和对话中的假设。
3. 根据核心约定组织每轮内容：一个带编号的问题、具体选项、编写其他答复和继续。
4. 仅探索了解用户旅程、必要数据、角色、规则、集成、限制、演示和验证所需的内容。对于每项不明确的待保存信息，都要加载 $specsfy-data-discovery，并先完成该项发现，再处理下一个问题。不要套用固定表单，也不要重复询问已保留的答复。
5. 当对方结束或推迟某个领域时，记录对方的表述，并在摘要中指出对应的 Inbox。不要自行填补空缺。

结束并后续处理

结束时，告知会话标识、M01、按顺序排列的已生成 backlog 和 Draft spec 清单、已确认的答复，以及标记为待处理的事项。同时说明其他主题仍保留在 MVP.md 中。生成 spec 即表示导入已完成；实现、最终验证和 Gate 提升留待后续获准的阶段进行。

限制

• 不得编造答复、目标、退出条件、范围外事项或 milestone 关联。
• 不得覆盖 milestone 1.0 或现有 backlog。
• 不得跳过导入器生成的任何 backlog 访谈。
• 导入期间不得实现代码，也不得将任何 Gate 标记为 Passed。
• 不得将 Inbox 视为规范性来源。
• 未经确认，不得使用 roadmap 访谈员扩展 MVP。