ce-prototype

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Prototype

原型

Build a throwaway prototype at the fidelity that can answer this question, before committing an approach later work will treat as given. Then apply the decisions or hand off.

Do not fake the dimension being tested. Modality, fidelity, and medium all follow from that one rule. A question about how a flow or state model behaves is settled by driving it, so a screen that only looks like the product does not answer it. A question about how a layout or a mark reads is settled by seeing it at real finish, so a thin sketch does not answer it either. The user's own perception settles the question, never your judgment of the artifact.

Result: the user decided how the product should work or feel against a prototype that did not fake what they were deciding. Next consumer: an existing markdown Product Contract, or

ce-brainstorm

ce-plan

with this session as the seed. Done: the questions that needed an artifact are decided, or the user applies and continues into brainstorm or plan. Not: a decision a cheap sketch settles, polish, or shipping the prototype as a final product.

If there is no person to experience the prototype — LFG,

mode:pipeline

, or any unattended run — stop. Do not start a preview, and do not invent how it should feel. Return that this skill needs a human.

User-runnable invocation rendering. Two outputs print invocation syntax: the attended re-run in that refusal, and the next-skill recommendation when the user applies. Default to

/ce-prototype

/ce-brainstorm

, and

/ce-plan

; use

$ce-prototype

$ce-brainstorm

, and

$ce-plan

only on Codex or a host that documents dollar-prefixed skill invocation. Render only each invocation as inline code and output one form only.

在确定后续工作将采用的方案之前，构建一个能够解答相关问题的一次性原型，保真度需匹配问题需求。之后应用所得决策或移交工作。

切勿伪造待测试的维度。 Modality、fidelity和medium均遵循这一规则。若问题关乎流程或状态模型的运作方式，需通过实际操作原型来验证，仅外观相似的界面无法解答此类问题。若问题关乎布局或标识的呈现效果，需查看高保真的成品效果，简单草图也无法满足需求。问题的最终判定取决于用户的实际感知，而非你对原型的主观判断。

结果： 用户基于未伪造待验证维度的原型，确定了产品应有的运作方式或使用感受。 下一承接环节： 现有Markdown格式的Product Contract，或以此会话为基础的

ce-brainstorm

ce-plan

。 完成标志： 需要借助原型解答的问题已得到决策，或用户应用决策并进入头脑风暴或规划环节。 禁忌： 用简单草图即可解决的决策、优化工作、将原型作为最终产品发布。

若无人体验原型——例如LFG、

mode:pipeline

或任何无人值守运行场景——请停止操作。不要启动预览，也不要主观臆断产品的使用感受。返回提示：此skill需要人工参与。

用户可执行的调用渲染。 输出两种调用语法：拒绝无人值守运行时的人工重运行调用，以及用户应用决策后的下一skill推荐。默认使用

/ce-prototype

、

/ce-brainstorm

和

/ce-plan

；仅在Codex或支持美元前缀skill调用的宿主环境中使用

$ce-prototype

、

$ce-brainstorm

和

$ce-plan

。仅以内联代码形式渲染每种调用，且仅输出一种格式。

Scope the question

明确问题范围

Read

references/scoping.md

before you ask the user anything or touch the repo. That load is not optional. It owns how the question arrives and the scoped repo read of what the question touches — do not scan the tree. It also owns narrow vs wide, sizing, the go-ahead message, and how the remaining questions change after each decision. Do not build until the user proceeds.

在向用户提问或操作代码库之前，请阅读

references/scoping.md

。这一步必不可少。该文档定义了问题的提出方式、问题涉及的代码库范围——请勿扫描整个目录树。同时还定义了范围的宽窄、规模、启动消息，以及每次决策后剩余问题的变化方式。得到用户确认后再开始构建。

Build it

构建原型

Read

references/build.md

and

references/preview.md

before writing anything.

A question is settled by seeing when the judgment lands on the rendered result: how a layout reads, what a palette does, how dense a screen feels. It is settled by driving when the judgment lands on what happens as the user moves through it: a flow, a state model, how a control answers. Load

references/craft-floor.md

for a seeing question. It carries the quality floor the render has to clear and the rule for how avenues differ, and neither of those lives here. A question settled by driving does not load it and gains no finish from it.

Default substrate: the web, whatever the product is written in — a native app's navigation feel gets a web approximation, not SwiftUI. It yields in exactly two cases: the user names a technology, or the dimension cannot be rendered in a browser without faking it. In that second case, build in the medium the dimension requires, and name that choice before you build. If a named technology also cannot render the dimension, say so rather than yielding silently.

references/build.md

owns what the artifact may be on either path.

Build under

.context/compound-engineering/ce-prototype/<date>-<slug>/

, so the prototype survives for the implementation that follows. Fall back to

/tmp/compound-engineering-<uid>/ce-prototype/<date>-<slug>/

, where survival is best-effort.

references/build.md

names every case that forces the fallback root.

The

.context

path has to be gitignored first. Probe it from the repo root with

git -C <repo root> check-ignore -q .context/compound-engineering/

; the trailing slash is load-bearing. When it is not covered, the offer to add that line comes before the root is resolved, or accepting it cannot help this run.

references/preview.md

owns that offer and the resolution that follows it. Do not create the run directory yourself; a second claim splits the screens from the capsule.

Scale into the existing app as a throwaway overlay when the user asks, or when the question is density or chrome on an existing page — an isolated page hides that. It is the one path that touches the product tree. Never commit it. When the try ends, restore only the files you changed, never work you did not make. If you cannot undo them cleanly, name the files you left modified rather than handing off a dirty tree. Never delete a kept prototype: throwaway describes the code, not a request to remove it.

在编写任何内容之前，请阅读

references/build.md

和

references/preview.md

。

若问题关乎布局呈现、调色效果或界面密度等，需通过视觉观察原型来解决；若问题关乎流程、状态模型或控件响应等，则需通过实际操作原型来解决。对于视觉类问题，请加载

references/craft-floor.md

，其中包含了渲染必须达到的质量标准以及不同方案的区分规则，这些内容不在本文档中。操作类问题无需加载该文档，也不需要达到相应的视觉质量。

默认载体：Web端，无论产品采用何种技术栈——例如原生应用的导航感受需用Web近似实现，而非SwiftUI。仅在两种情况下例外：用户指定了技术栈，或该维度无法在浏览器中真实渲染。第二种情况下，请采用该维度所需的媒介构建原型，并在构建前说明选择理由。若指定的技术栈也无法渲染该维度，请明确告知用户，而非默默妥协。

references/build.md

定义了两种情况下原型的可选形式。

将原型构建在

.context/compound-engineering/ce-prototype/<date>-<slug>/

目录下，以便后续实现环节可以复用该原型。若无法使用该路径， fallback到

/tmp/compound-engineering-<uid>/ce-prototype/<date>-<slug>/

目录，该路径下的原型仅做尽力保留。

references/build.md

列出了所有必须使用fallback根目录的情况。

.context

路径必须先被git忽略。从代码库根目录执行

git -C <repo root> check-ignore -q .context/compound-engineering/

进行检查——末尾的斜杠至关重要。若该路径未被忽略，需先提供添加忽略规则的选项，再确定根目录，否则接受该选项无法对本次运行提供帮助。

references/preview.md

定义了该选项及后续的处理流程。请勿自行创建运行目录；重复创建会导致界面与容器分离。

当用户要求，或问题关乎现有页面的密度或导航栏时，可将原型作为一次性叠加层集成到现有应用中——独立页面无法体现这些特性。这是唯一允许操作产品目录树的路径。请勿提交该叠加层。测试结束后，仅恢复你修改过的文件，切勿改动其他内容。若无法干净地撤销修改，请列出你留下的已修改文件，而非移交一个未清理的目录树。切勿删除保留的原型：“一次性”指的是代码用途，而非要求移除原型。

Keep the decisions

记录决策

Keep a run capsule at

decisions.md

in this run's directory, so the next skill does not need this session.

references/build.md

lists what it carries. Point at the prototype; do not reproduce it. Include only what changes later planning. Do not treat

decisions.md

as a plan: applying writes the Product Contract or the recap, and the capsule is only continuity.

Update the capsule when you are confident a choice has settled — the user judged the artifact and chose, including any adjustments they attached. If you are not confident, do not write. Do not pause to confirm every write. Keep the winner and those adjustments in the prototype.

Read

decisions.md

before building for the next related question, and work out which questions are still worth building for.

references/scoping.md

owns how that list changes. If what they decided changed what they want to build rather than answering the question you asked, stop and hand back what you learned instead of building for a question they have moved past. Otherwise stay in this skill for it. Do not bounce to brainstorm or plan while a related question still needs an artifact, do not start an unrelated campaign, and do not keep prototyping once they apply.

在本次运行的目录下创建

decisions.md

运行容器，以便后续skill无需依赖本次会话。

references/build.md

列出了该容器应包含的内容。只需指向原型，无需复制原型内容。仅记录会影响后续规划的内容。请勿将

decisions.md

视为规划文档：应用决策时需写入Product Contract或总结文档，该容器仅用于保证工作连续性。

当你确认某个选择已确定——即用户评估原型后做出了选择，包括附带的调整——更新该容器。若不确定，请勿写入。无需暂停以确认每次写入。在原型中保留最终方案及相关调整。

为下一个相关问题构建原型前，请阅读

decisions.md

，确定哪些问题仍需通过原型解答。

references/scoping.md

定义了问题列表的变化规则。若用户的决策改变了他们想要构建的内容，而非解答了你提出的问题，请停止操作，移交你所了解的信息，而非为用户已不再关注的问题构建原型。否则继续使用此skill处理相关问题。在相关问题仍需原型解答时，请勿切换到头脑风暴或规划环节；请勿启动无关的任务；用户应用决策后，请勿继续原型构建。

Apply or continue

应用决策或继续推进

When the user applies:

If this run has a directly related brainstorm or plan — passed on invoke, passed by the calling skill, or named in this session as the file this prototype is for — load
```
references/write-back.md
```
and follow it. Markdown and HTML both. Use
```
decisions.md
```
when present. Do not pick a plan because one exists in the repo.
If there is no such file or relatedness is unclear: do not mint a plan or a third note. Recap from
```
decisions.md
```
when present, carrying the decisions and, when the run left one behind, the prototype path — an overlay run has none, so say that rather than pointing at something you undid. That recap is a complete outcome, not a degraded one.

Then continue. If a calling skill invoked this, return the choices in

decisions.md

and let it continue. Otherwise recommend a next skill and pass this session as the seed. After a write-back, recommend

ce-plan

: the plan is now

requirements-only

with its HOW stripped, and

ce-work

refuses it until

ce-plan

re-enriches. After a file-free run, recommend

ce-brainstorm

when product-level questions remain, or

ce-plan

when the session is enough to plan. Print that recommendation per the rendering rule above.

当用户应用决策时：

若本次运行存在直接相关的头脑风暴或规划文档——调用时传入、调用skill传入，或本次会话中指定了原型对应的文档——请加载
```
references/write-back.md
```
并遵循其指引。支持Markdown和HTML格式。若存在
```
decisions.md
```
，请使用其中的内容。请勿因代码库中存在某个规划文档就选择它。
若不存在此类文档或关联性不明确：请勿生成规划文档或第三方笔记。若存在
```
decisions.md
```
，请据此总结，包含决策内容；若本次运行留下了原型路径，也需一并提供——叠加层运行无原型路径，需明确说明，而非指向已撤销的内容。该总结即为完整成果，并非简化版本。

之后继续推进。若由其他skill调用了此skill，请返回

decisions.md

中的选择，由调用skill继续处理。否则推荐下一skill，并将本次会话作为基础。完成回写后，推荐

ce-plan

：此时规划文档仅包含需求，缺少实现方式，

ce-work

会拒绝处理，直到

ce-plan

补充完整信息。若无相关文档的运行，若仍有产品层面的问题待解决，推荐

ce-brainstorm

；若本次会话已足够支撑规划，推荐

ce-plan

。按照上述渲染规则打印该推荐。