Metis Analysis: [Topic]

Metis Analysis: [Topic]

Missing Questions

1. [Question] — [Why it matters]

Undefined Guardrails

1. [Unbounded behavior] — [Suggested measurable bound]

Scope Risks

1. [Creep risk] — [Prevention rule]

Unvalidated Assumptions

1. [Assumption] — [Validation method]

Missing Acceptance Criteria

1. [Observable pass/fail criterion]

Edge Cases

1. [Scenario] — [Expected handling to clarify]

Recommendations

• [Prioritized requirement decision or routing]

Open Questions

• [ ] [Question or decision needed] — [Why it matters]

各章节要点：

- **Missing Questions（缺失的问题）**：每个问题必须附带"为什么重要"。这是整个模板中最有价值的部分——它迫使分析器在规划前就把模糊点显式化；
- **Undefined Guardrails（未定义的护栏）**：描述"无界行为"（unbounded behavior），并给出**可度量的边界建议**（suggested measurable bound），呼应证据规则第 2 条的可观测要求；
- **Scope Risks（范围风险）**：列出蔓延风险（creep risk）与预防规则（prevention rule），对应策略第 3 步的 in/out of scope 划定；
- **Unvalidated Assumptions（未验证的假设）**：每条假设配验证方法（validation method），呼应证据规则第 3 条；
- **Missing Acceptance Criteria（缺失的验收标准）**：直接产出可观测的 pass/fail 判定条目，这是下游 planner 与 test-engineer 最需要的输入；
- **Edge Cases（边界场景）**：场景 + 期望处理方式，覆盖失败状态、时序、权限与数据边界；
- **Recommendations（建议）**：给出按优先级排序的需求决策或路由建议（routing），例如"此缺口应转给 architect"或"此假设需产品确认"；
- **Open Questions（开放问题）**：用 checkbox 列出待决问题及其影响，作为交接给后续角色的"未决清单"。

从仓库中的 [docs/recipes/prometheus-inspired-deliberation.md](https://gitcode.com/GitHub_Trending/oh/oh-my-codex/blob/b48df502d566430be768d3c60f2f51fa91630396/docs/recipes/prometheus-inspired-deliberation.md?utm_source=gitcode_repo_files) 可以看出，Metis 对应的正是这种"把需求嚼碎到可执行"的提示词型原生角色，与 Prometheus（planner）、Momus/Oracle 等共同构成提示词驱动的多角色协作体系。

## 在团队阶段管线中的接入点

Analyst 不是孤立存在的提示词文件，它在 OmX 的团队编排（team orchestration）中拥有明确的阶段挂载点。看 [src/team/orchestrator.ts](https://gitcode.com/GitHub_Trending/oh/oh-my-codex/blob/b48df502d566430be768d3c60f2f51fa91630396/src/team/orchestrator.ts?utm_source=gitcode_repo_files#L8) 定义的五个阶段：

```ts
export type TeamPhase = 'team-plan' | 'team-prd' | 'team-exec' | 'team-verify' | 'team-fix';

阶段转换由 TRANSITIONS 定义：team-plan -> team-prd -> team-exec。而 getPhaseAgents 给出每个阶段推荐的角色：

case 'team-plan':
  return ['analyst', 'planner'];
case 'team-prd':
  return ['product-manager', 'analyst'];

也就是说 analyst 同时出现在两个前置阶段：

• team-plan（规划阶段）：与 planner 搭档，Analyst 先做需求分析，Planner 再做任务拆解；
• team-prd（需求阶段）：与 product-manager 搭档，PM 产出 PRD，Analyst 产出验收标准。

阶段指令（getPhaseInstructions）给出了明确的分工提示：

case 'team-plan':
  return 'PHASE: Planning. Use /analyst for requirements, /planner for task breakdown. Output: task list with dependencies.';
case 'team-prd':
  return 'PHASE: Requirements. Use /product-manager for PRD, /analyst for acceptance criteria. Output: explicit scope and success metrics.';