ce-pov

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Form a Point of View

形成观点

Produce a decisive, project-grounded point of view in the subject's own shape: a graded verdict on an external-adoption question, a holistic take on a document, or a position on a supplied approach set. The subject is whatever this skill was invoked with, in the prompt or the conversation. Stay read-only while forming and reconciling the POV. You are done when the POV is delivered with its attribution and required disclosure, or when an explicit blocker is returned. The year is 2026, for source recency.
针对当前主题,输出一个基于项目的决定性观点,形式与主题匹配:针对外部技术采纳问题给出分级结论、对文档给出全面评价,或针对提供的方案集表明立场。主题即为调用该技能时提示词或对话中的内容。在形成和调和观点过程中保持只读状态。当观点附带来源说明和必要披露信息交付完成,或返回明确的阻塞项时,任务结束。当前年份为2026年,以此确保资料时效性。

The moat

核心准则

Never issue a POV you did not earn against the project's own context. Every subject must clear the project floor in
references/method.md
. An external-adoption verdict must also clear the full external floor. A document or approach-set POV must externally verify any external claim that is load-bearing to its bottom line. Nothing the conversation asserts substitutes for grounding.
绝不能输出未结合项目自身背景的观点。 所有主题必须满足
references/method.md
中的项目基础要求。外部技术采纳结论还需完全满足外部相关要求。针对文档或方案集的观点,必须对支撑其核心结论的所有外部主张进行外部验证。对话中的任何断言都不能替代背景验证。

User-facing communication

用户沟通规范

Write for the person deciding what to do. Lead with the decision, question, or recommendation. Keep internal workflow vocabulary and mechanics out of chat unless asked, and put any consequence they need into ordinary language. Call the codebase "this project" or "the repository" unless the user supplied a recognizable name. Never promote a directory, worktree, checkout, branch, or path into the project name.
面向需要决策的人员撰写内容。开篇即给出决策、问题或建议。除非被询问,否则不要在对话中提及内部工作流术语和机制,并用通俗易懂的语言阐述相关影响。除非用户提供了可识别的名称,否则将代码库称为“本项目”或“代码仓库”。绝不能将目录、工作树、检出分支或路径当作项目名称。

Interaction Method

交互方法

Ask through the host's blocking question tool, one question at a time:
AskUserQuestion
(Claude Code; run
ToolSearch
with
select:AskUserQuestion
if its schema is not loaded),
request_user_input
(Codex),
ask_question
(
agy
),
ask_user
(Pi). Fall back to numbered chat options only when none exists or the call errors. Never skip the question.
通过宿主的阻塞式提问工具逐一提问:
AskUserQuestion
(Claude Code;若未加载其 schema,运行
ToolSearch
并指定
select:AskUserQuestion
)、
request_user_input
(Codex)、
ask_question
agy
)、
ask_user
(Pi)。仅当上述工具均不存在或调用出错时,才退化为带编号的对话选项。绝不能跳过提问步骤。

Artifact Root

工件根目录

Resolve
<root>
the first time you compose a
<root>/
path; a read of
<root>/solutions/
counts as composing one. Pass the resolved path to scouts, never the config. A non-git project has no
<root>
, so its prior-decision scan uses local ADRs and design docs instead.
<!-- ce-docs-root:start -->
Resolve the CE artifact root
<root>
before composing any artifact path.
  • Read
    docs_root
    from
    <repo-root>/.compound-engineering/config.yaml
    only (
    <repo-root>
    =
    git rev-parse --show-toplevel
    ). Do not read it from
    config.local.yaml
    . Unset ->
    <root>
    is
    docs
    , exactly as before.
  • Validate a set value: a repo-relative directory whose real, symlink-resolved path stays inside the repo and is neither the repo root nor under
    .git/
    . Otherwise stop with an error naming
    docs_root
    and the value -- never fall back to
    docs
    .
  • Use
    <root>
    as the sole artifact location: create it if absent, compose each path as
    <root>/<subdir>
    with this skill's own subdirectory, and never also read
    docs
    .
<!-- ce-docs-root:end -->
首次编写
<root>/
路径时需解析
<root>
;读取
<root>/solutions/
即视为完成一次路径编写。将解析后的路径传递给scouts,绝不要传递配置信息。非Git项目没有
<root>
,因此需使用本地ADR(架构决策记录)和设计文档进行历史决策扫描。
<!-- ce-docs-root:start -->
在编写任何工件路径之前,先解析CE工件根目录
<root>
  • 读取:仅从
    <repo-root>/.compound-engineering/config.yaml
    中读取
    docs_root
    <repo-root>
    =
    git rev-parse --show-toplevel
    )。不要从
    config.local.yaml
    中读取。若未设置,则
    <root>
    默认为
    docs
    ,与之前保持一致。
  • 验证:对设置的值进行验证:必须是仓库相对目录,其真实、解析符号链接后的路径需位于仓库内部,且既不是仓库根目录也不在
    .git/
    目录下。否则终止操作并报错,指明
    docs_root
    及其错误值——绝不能回退到
    docs
  • 使用:将
    <root>
    作为唯一的工件存储位置:若不存在则创建,按
    <root>/<subdir>
    格式编写每个路径(包含本技能自身的子目录),且绝不要再读取
    docs
    目录。
<!-- ce-docs-root:end -->

Phase 0: Frame and Classify

阶段0:框架与分类

Read
references/intake.md
now, before any grounding.
It owns the output mode, the warm-invocation contract, orientation and framing, sizing, and the unbounded-field escape hatch. Settle the subject and the POV intent there (adopt / migrate / compare / is-this-our-problem / Document-take / Approach-set / explainer); an intent that routes out finishes at intake, and one that continues settles a reversibility tier. Read
references/boundaries.md
when this skill's fit is in doubt.
在进行任何背景验证之前,先阅读
references/intake.md
该文档定义了输出模式、热调用协议、定位与框架、范围以及无界字段的逃生舱口。在此确定主题和观点意图(采纳/迁移/比较/是否属于本项目问题/文档评价/方案集立场/解释);若意图指向其他技能,则在该阶段结束任务;若继续执行,则确定可逆性层级。当对本技能的适用性存疑时,阅读
references/boundaries.md

Phase 1: Ground

阶段1:背景验证

Read
references/grounding.md
now, before grounding by either path.
It owns the model tiers (the POV reasoning itself is never dispatched), the scratch fence, the scout payload and fleet, capability gating, and the provenance buckets that keep grounded facts apart from unconfirmed ones.
Send scouts directly to candidate-specific current evidence, never a generic repo profile. They search in their own context and return a dossier path plus a gist, which you read on demand. Where the load-bearing facts are already located, confirm them with bounded reads of the authoritative source instead of dispatching scouts; unscoped or noisy grounding still dispatches. A claim made in the conversation is a pointer to check, never self-verifying. The prior-decision scan (
<root>/solutions/
, ADRs, design docs) stays mandatory on either path.
在通过任意路径进行背景验证之前,先阅读
references/grounding.md
该文档定义了模型层级(观点推理过程绝不会被分派)、临时存储限制、scouts的负载和集群、能力门控以及区分已验证事实与未确认事实的来源分类。
直接向候选对象的当前证据发送scouts,不要发送到通用仓库概览。scouts在自身上下文内搜索并返回档案路径及要点,你可按需读取。对于已明确位置的支撑性事实,通过对权威来源的限定读取来确认,而非分派scouts;无范围或噪声较大的背景验证仍需分派scouts。对话中的主张仅作为检查指针,绝不能自行验证。无论采用哪种路径,历史决策扫描(
<root>/solutions/
、ADR、设计文档)都是必须执行的步骤。

Phase 2: Verify Grounding

阶段2:验证背景

Read
references/method.md
now
, before reasoning about the POV. It owns the Verify and POV steps, the skeptic stance, tiering, and the gate. Apply that gate over the grounded evidence. A failed floor forbids a confident result in any subject shape; that reference names the failure result each shape returns instead.
在对观点进行推理之前,先阅读
references/method.md
该文档定义了验证和观点步骤、质疑立场、层级划分以及准入门槛。将该门槛应用于已验证的背景证据。若未满足基础要求,则任何形式的主题都无法得出可信结论;该文档会针对每种形式的主题指明失败时应返回的结果。

Phase 3: Point of View

阶段3:输出观点

First form ce-pov's own independent POV under the active subject-shape contract in
references/method.md
, but do not emit it. Freeze that position. Keep it out of an independent peer's initial context; expose it only when the task is to critique that position, or in a later reconciliation round.
A summons is an affirmative request to consult or reconcile peers — a panel, a cross-check,
oracle
— anywhere in the invocation context. Declining one, or merely recounting one, is not a summons. On a summons, or when a cold POV may qualify for a proactive offer, read
references/cross-model-panel.md
before resolving participation or deciding whether to offer. Finish the panel branch before composing the result. A POV that follows a summons states which peers ran, or that none did and why. A POV with no summons carries no panel note.
Only then emit the subject shape's contract, as a compact chat block, not a research report. Lead with the grade, bottom line, or position, and never reprint dossiers or raw output.
首先根据
references/method.md
中当前主题形式的约定,形成ce-pov自身的独立观点,但不要输出。冻结该立场。不要将其暴露给独立同行的初始上下文;仅当任务是批判该立场,或在后续调和阶段才予以披露。
召唤指的是明确要求咨询或调和同行观点的请求——包括专家组、交叉检查、
oracle
——无论该请求出现在调用上下文的哪个位置。拒绝召唤或仅复述召唤内容不属于召唤请求。当收到召唤,或冷启动观点可能符合主动提供的条件时,在决定是否参与或提供之前,先阅读
references/cross-model-panel.md
。在完成专家组分支流程后再撰写结果。若观点是在召唤后形成的,需说明运行了哪些同行模型,或说明未运行的原因。若未收到召唤,则无需提及专家组相关内容。
之后,按照主题形式的约定输出内容,采用简洁的对话块形式,而非研究报告。开篇即给出评级、核心结论或立场,绝不要重印档案或原始输出内容。

Phase 4: Follow-up

阶段4:后续跟进

The chat POV is the deliverable; implementation is not. Read
references/followup.md
for the four-part handoff gate, the routing, and the continuations. Hand the POV on without another question only when that gate passes. Otherwise offer one continuation and wait. Reason that offer from the active subject shape's result — external adoption, Document take, or Approach-set position — never from a fixed menu, and never assume everything routes to a plan. Block only where that reference says the user must choose.
Warm invocations stay a guest: output the POV block, hand control back, and offer none of this unless asked.
对话中的观点即为交付成果;无需负责实施。阅读
references/followup.md
了解四步交接门槛、路由规则以及后续流程。仅当满足该门槛时,才可直接移交观点而无需进一步提问。否则需提供一个后续选项并等待。后续选项需基于当前主题形式的结果——外部技术采纳、文档评价或方案集立场——生成,绝不要使用固定菜单,也不要假设所有内容都会路由到计划环节。仅当该文档明确说明用户必须选择时才进行阻塞。
热调用场景下需保持访客身份:输出观点块,交还控制权,除非被询问否则不要提供任何后续内容。