ce-prototype

原型

先以足以回答问题的保真度构建一个一次性原型，再确定后续工作将据此采用的方案。然后落实决策或交接。

不要伪造正在测试的维度。 模态、保真度和媒介都遵循这一条规则。关于流程或状态模型如何运行的问题，应通过实际操作来确定，因此，仅仅看起来像产品的屏幕无法回答这类问题。关于布局或标记呈现效果的问题，应通过查看真实成品来确定，因此，粗略草图也无法回答这类问题。问题应由用户自己的感知来决定，而不是由你对产物的判断来决定。

结果： 用户通过一个没有伪造其决策内容的原型，决定了产品应如何运作或呈现何种感受。 下一位使用者： 现有的 Markdown 产品契约，或以本次会话为起点的 ce-brainstorm / ce-plan。 完成标准： 用户已通过产物解决了需要解决的问题，或他们应用该产物并继续进入头脑风暴或计划阶段。由用户的选择来解决问题，而不是由你推断方向。 不包括： 可以通过廉价草图解决的决策、润色，或将原型作为最终产品发布。

如果没有人能体验原型——例如 mode:pipeline、无头运行，或调用技能报告没有人在场——请停止。不要启动预览，也不要臆测应呈现何种感受。请回复说明此技能需要有人参与。若调用技能时有人在场（例如交互式 lfg 运行），则按正常的有人参与流程处理。

面向用户的调用语法。 在拒绝后重新运行的建议，以及用户应用后给出的下一技能建议中，应使用调用语法。默认使用 /ce-prototype、/ce-brainstorm 和 /ce-plan；仅在 Codex 或明确记录了带美元符号前缀的技能调用方式的宿主上，才使用 $ce-prototype、$ce-brainstorm 和 $ce-plan。仅将调用本身设为行内代码；只输出一种形式。

界定问题

在询问用户任何问题或接触代码库之前，先阅读 references/scoping.md。此步骤不可省略。该文档规定了问题如何提出，以及如何有针对性地读取与问题相关的代码库内容——不要扫描整个目录树。文档还定义了范围的宽窄、规模评估、授权消息，以及每项决策后剩余问题如何变化。未获授权前不要构建。若请求本身已明确要求为某个命名对象制作原型，则在完成范围界定后即视为已获授权。

构建

开始编写前，先阅读 references/build.md 和 references/preview.md。独立的 Web 预览启动后，再加载 references/annotation-loop.md。覆盖层运行和非 Web 运行都留在聊天中。

进展后，只有在用户可以对新内容采取行动时才发言，用一行简短的话说明发生了什么：界面已启动、辅助 URL 已上线，或只有用户才能解除的阻碍。该注释循环定义了应用修订后的发言方式，以及等待暂停时保持沉默的规则。

如果判断取决于渲染结果——例如布局的观感、配色的效果或界面的密集程度——就通过观察来得出结论。如果判断取决于用户操作时发生的情况——例如流程、状态模型或控件的响应——就通过操作来得出结论。对于需要观察的问题，加载 references/craft-floor.md。其中包含质量底线和路径差异规则；这两者都不在此处定义。通过操作得出结论的问题无需加载它，也不会因此得到任何润色。

默认载体是 Web，无论产品使用什么技术编写——原生应用的导航体验要用 Web 近似呈现，而不是 SwiftUI。references/build.md 定义了交付内容和产物。

在 .context/compound-engineering/ce-prototype/<date>-<slug>/ 下构建，确保原型能保留到后续实施阶段。如果不行，则使用 /tmp/compound-engineering-<uid>/ce-prototype/<date>-<slug>/，但能否保留无法保证。references/build.md 列出了必须使用备用根目录的所有情况。

必须先将 .context 路径加入 gitignore。从仓库根目录运行 git -C <repo root> check-ignore -q .context/compound-engineering/ 进行检查；末尾的斜杠不可省略。如果该路径尚未被忽略，必须先提出添加该行，再确定根目录，否则即使用户接受，也无法帮助本次运行。

references/preview.md 定义了如何提出该请求以及之后如何确定路径。不要自行创建运行目录；第二次声明会导致界面与胶囊分离。

当用户提出要求，或问题涉及现有页面的密集程度或界面框架（独立页面会掩盖这些问题）时，可将覆盖层作为一次性改动集成到现有应用中。这是唯一会触及产品目录的路径。绝不要提交这些改动。试用结束时，只还原你更改过的文件。如果无法干净地撤销，就指出仍处于修改状态的文件，而不是交付一个不干净的工作树。绝不要删除保留的原型：一次性描述的是代码，而不是要求将其移除。

保留决策

在本次运行的目录中将决策胶囊保存在 decisions.md，这样下一个技能无需依赖本次会话。references/build.md 列出了胶囊应包含的内容。只需指向原型，不要复述它。只纳入会改变后续规划的内容。不要把 decisions.md 当作计划：应用会写入 Product Contract 或回顾记录，而胶囊只用于保持上下文连续。

当你确信某个选择已经确定时，更新胶囊——也就是用户评估了产物并作出选择，包括他们附带的任何调整。如果你不确定，就不要写。无需停下来逐次确认是否写入。将最终方案及其调整保留在原型中。

为下一个相关问题开始构建前，先阅读 decisions.md，并判断哪些问题仍值得构建。references/scoping.md 定义了如何调整这份问题清单。如果用户的决定改变了他们想构建的内容，而非回答你提出的问题，就停下来交还你获得的信息，不要继续针对他们已不再关心的问题构建。否则，就继续留在此技能中处理。只要相关问题仍需要产物，就不要转去头脑风暴或规划；不要另起无关的探索，也不要在用户应用后继续制作原型。

应用或继续

当用户应用时：

• 如果本次运行有直接相关的头脑风暴或计划——在调用时传入、由调用技能传入，或在本次会话中指定为此原型对应的文件——则加载 references/write-back.md 并遵循其中的说明。Markdown 和 HTML 均适用。存在 decisions.md 时使用它。不要仅仅因为仓库中存在某个计划就选用它。
• 如果没有这样的文件，或无法确定其相关性：不要新建计划或第三份笔记。存在 decisions.md 时，从中整理摘要，保留各项决策；如果本次运行留下了原型路径，也一并附上——覆盖运行不会留下原型路径，因此应如实说明，而不是指向已撤销的内容。这样的摘要就是完整结果，并非降级结果。

然后继续。如果这是由调用技能触发的，则返回 decisions.md 中的选项并让其继续。否则，推荐下一个技能，并将本次会话作为种子传入。写回后，推荐 ce-plan，为变更后的需求重新生成实施计划。没有文件的运行结束后，如果仍有产品层面的问题待解决，则推荐 ce-brainstorm；如果本次会话的信息已足以制定计划，则推荐 ce-plan。按照上述呈现规则输出该推荐。