ce-pov

形成观点

围绕主题本身的形态，给出明确、立足项目的观点：针对外部采用问题给出分级判定，对文档给出整体看法，或对提供的方案集表明立场。主题就是在提示词或对话中调用此技能时所指的内容。形成并核对观点时保持只读。只有在给出附带归属信息和必要披露的观点，或返回明确的阻碍说明后，才算完成。使用 ce-bakeoff 设计相互竞争的解决方案，使用 ce-ideate 探索机会，或使用 ce-brainstorm 确定目标。当前年份为 2026 年，用于判断资料的新近程度。

依据不可或缺

**绝不能在未结合项目自身上下文充分核实的情况下发表观点。**每个主题都必须达到 references/method.md 中规定的最低项目证据要求（项目基准线）。外部采用判定还必须达到其中规定的完整外部证据标准。对话中的任何断言都不能替代依据核实。

面向使用者与交互

以目标使用者可直接采用的形式给出有依据的立场。先给出决策，同时保留证据、重要权衡、不确定性及其决定条件。让标识符无需读者重新打开主题也能理解。在进度更新中，用通俗语言说明你正在核查什么，以及由哪个模型或辅助程序进行核查。不要在进度更新中提及此技能的内部机制（载荷、侦察员、档案、层级、轮次、临时文件）。

参与持续工作流时，返回结果，并由调用工作流的所有者负责后续操作。不要在该返回中提出后续跟进或小组讨论。若明确要求 Oracle 或指定同伴参与，则仍须运行小组讨论，即使该请求来自调用工作流。

识别问题并返回结果

根据请求和对话识别问题，然后查找可核实的事实。不要通过询问用户来确定评估对象。如果缺失的信息会改变建议，且无法查明，则返回 受阻 — 缺少上下文。说明缺少什么、为何重要，以及需要什么信息才能解决。由调用方 Agent 决定是请求澄清还是采取其他行动。无论用户是直接调用 ce-pov，还是由其他 Agent 调用，都适用此规则；无需另设非交互模式。

产物根目录

首次组合 <root>/ 路径时解析 <root>；读取 <root>/solutions/ 也算组合路径。将解析后的路径传递给侦察员，不要传递配置文件。非 Git 项目没有 <root>，因此其既有决策扫描应改为检查本地 ADR 和设计文档。

组合任何产物路径前，先解析 CE 产物根目录 <root>。

• 读取 <repo-root>/.compound-engineering/config.yaml 中的 docs_root，且仅从此处读取（<repo-root> = git rev-parse --show-toplevel）。未设置时，<root> 恰好为 docs，与之前相同。不要从 config.local.yaml 读取。
• 验证已设置的值：它必须是相对于仓库的目录，解析符号链接后的实际路径必须仍位于仓库内，且不能是仓库根目录或位于 .git/ 下。否则停止并指出 docs_root 及其值，不要回退到 docs。
• 使用 <root> 作为唯一产物位置：若不存在则创建；每个路径均组合为 <root>/<subdir>，并使用此技能自己的子目录；也不要同时读取 docs。

阶段 0：界定与分类

现在阅读 references/intake.md，然后再进行任何依据核查。 该文件定义了输出模式、调用工作流会传入的内容、方向与框定方式、规模，以及问题没有明确边界时的处理方式。在此确定主题和 POV 意图（采用 / 迁移 / 比较 / 是否是我们的问题 / Document-take / Approach-set / 说明）；属于其他技能的意图应在 intake 阶段结束，继续处理的意图则要记录决策的可逆程度。如果不确定本技能是否适用，请阅读 references/boundaries.md。

阶段 1：核实依据

现在阅读 references/grounding.md，然后再通过任一路径核实依据。 该文件定义了模型层级（POV 推理本身绝不会被分派）、临时文件可存放的位置、scout 会收到什么内容以及运行数量、哪些能力是各步骤的门槛，以及如何将有依据的事实与未经确认的事实区分开来。

直接让 scout 查找候选方案特定的最新证据，绝不要查找泛泛的仓库概况。scout 在自己的上下文中搜索，并返回档案路径和摘要，你按需阅读。如果判定所依赖的事实已经定位，就通过有限范围地读取权威来源来确认，而不是分派 scout；依据核查范围不明确或噪声过多时，仍应分派。对话中提出的主张只是待核查线索，不能自行验证。无论采用哪条路径，扫描既有决策（<root>/solutions/、ADR、设计文档）都是必需的。

如果判断需要解释尚未解决的行为或设计理由，请调用 ce-explain。传入问题、范围以及该解释所服务的决策。使用足够的最新证据，不要重复调查。将其引用的发现视为需要按相同依据标准评估的证据，而非建议的权威依据。在此处保留判断权。如果无法使用 ce-explain，请直接收集证据，或报告缺失内容。

阶段 2：验证依据

现在阅读 references/method.md，然后再对 POV 进行推理。 该文件定义了 Verify 和 POV 步骤、审慎立场、分级方式以及证据检查。对已核实的证据应用该检查。如果证据不足，任何主题形态都不得给出确定结论；该文件会说明各形态应返回的结果。

阶段 3：观点

首先依据 references/method.md 中当前生效的主题形态约定，形成 ce-pov 自己独立的 POV，但不要输出。冻结该立场。不要将其放入独立同行的初始上下文；仅当任务是批评该立场时，或在之后的协调轮次中，才公开它。

panel 请求是指明确要求征询其他模型或与其协调：在调用上下文的任何位置提出 panel、交叉核查或 oracle 均属此类。拒绝参与，或仅仅提及，都不构成请求。收到 panel 请求时，或未收到请求但形成的 POV 可能适合主动提出 panel 时，请在决定是否参与或提出建议之前阅读 references/cross-model-panel.md。完成 panel 分支后再撰写结果。响应 panel 请求的 POV 必须说明哪些同行参与了，或说明无人参与及原因。未收到 panel 请求的 POV 不应附带 panel 说明。

之后才能交付立场，并包含 references/method.md 要求的内容。根据预期用途调整呈现方式；引用支持性证据，而不是重印档案或原始同行输出。

阶段 4：交付并返回

判断结果才是交付物，实施不是。调用工作流会接收结果并取回控制权。如果用户要求撰写文档或继续处理，请阅读 references/followup.md；该文件定义了产物交付方式以及下游操作所需的权限。完成 POV 不应要求用户选择下一步。