analyze

分析

调查任务、想法、工单、PR 或评审修复待办，并在聊天中返回一份有证据支持的备忘录。绝不写入 Linear 或 GitHub。

阅读时机

• 正在调查已触及的用户流程、可见操作或 UX 投诉？打开 user-experience.md，检查当前入口、上下文、后续操作和现有设计，然后再推荐控件。仅涉及后端的工作可跳过此项。
• 即将开展调研，即使需求看起来只涉及单个文件？打开 code-quality.md、code-structure.md、doctrine.md 和执行上下文。跳过它们，备忘录就可能推荐规则不允许的修复。
• 即将进行广泛搜索或阅读大型文件？打开 main-context.md。跳过它，原始搜索结果就会淹没分析。
• 即将向用户提问？打开询问用户。跳过它，你可能会问仓库中已有答案的问题。

约定

• 从实时来源重新核实仓库、工单、PR 和差异事实。
• 在执行上下文中明确记录用户决策、规则、范围和晋级状态（即用户是否批准将此分析转为构建任务或工单，参见 Apply），并以用户提供的信息为准，而非代码。
• 只在聊天中返回分析备忘录，并在执行上下文中维护状态。
• 仅当用户明确要求保存备忘录并批准保存位置时，才保存备忘录。

仅询问机制或原因

如果用户只想了解某项功能如何工作（例如演练操作流程、了解哪一层由谁负责、了解各层如何协作），请停止并遵循 /how。如果他们只想了解这样设计的原因，请停止并遵循 /why。Bug、想法、影响或构建起点仍由此处处理。

流程

1. 建立或刷新相关执行上下文，并规范化需求。 如果上级已明确锁定完成条件和必须遵守的规则， 就沿用这些内容，无需反复追问产品意图。
2. 根据规范中的调研规则调查受影响的流程。提出设计建议前，区分事实、已确定的决策、实现者通常可自行决定的事项，以及尚未解决的权衡。
   • 涉及有意义的功能或边界变更，或发现架构摩擦：应用公共边界调查。不改变契约的小改动可跳过此项。
   • 对独立边界存在不确定性：使用有界侦察。
   • 现有机制或历史可能影响分析：针对该有界问题使用 /how 或 /why，并在备忘录中保留其结论、来源和不确定性。两者都不会选择新设计，也不会开启另一轮访谈。
   • 在上级任务下：按照嵌套能力返回事实、结论、来源指引和不确定性，不提供标准备忘录。
3. 独立处理时，在聊天中发布规范要求的备忘录。以 Mermaid 图开篇。 如果工作已可构建，则附上内联执行起点。

评审修复

仅当当前协调者要求分析修复流程中指定的“立即修复”条目时，才使用此模式。针对每个稳定的问题 ID，返回根本原因、最小修复方案、涉及范围、不确定性和验证方式。不要添加问题、新产品探索或后续事项。 协调者负责裁定并一次性分派；分析不会提升任务状态，也不会启动实现生命周期。

如果上级已负责下一步

遵循嵌套能力。返回有界证据和建议。准备、晋级以及任何后续步骤均由上级负责，即使上级已经获得实现授权，也不例外。

如果这是用户的一次性请求

针对真正未知的事项，一次性提出一批问题，然后提供 doctrine.md 中明确列出的交接选项（Done / Sharpen / Promote / Write ticket / Promote + start）。除非用户已经说明下一步，否则请提出这些问题，并在没有上级简报的情况下开展工作。

反模式

• 返回原始搜索结果列表，而不是备忘录
• 用这份备忘录回答纯粹的如何做或为什么的问题
• 创建工单、实现代码或编写测试