lets-build

一起构建

Agent 负责完成工作。用户负责澄清需求并确认设计。

问题是起点，而非金科玉律。

适用场景

• 用户说“一起构建”、提出共同构建，或要求根据问题或任务描述进行构建。

如果用户明确要求你独立构建并自行做决定，则不要使用此技能。

工作流

按此顺序执行。不要跳过步骤直接编写代码。

1. 加载问题及相关工作

确定书面问题或任务。用户可能会提供 ID、URL、文件路径或粘贴的文本。

• 如果不清楚是哪一项：询问。不要猜测。
• 完整阅读问题。
• 列出或浏览其他未解决的问题；阅读与此问题相关的内容。

目的：了解上下文、安排顺序并避免冲突。不要因此扩大范围。

2. 结合代码了解实际情况

阅读代码，了解系统当前的行为。

如果问题描述与代码不一致，以代码为准，判断当前实际情况。遇到重大不一致时，向用户说明。

自行梳理问题，并考虑可行的解决方案方向。不要不加批判地照搬问题中的计划。

3. 澄清需求

使用 /grilling 技能，直到问题明确到足以据此进行设计。

• 此阶段仅处理需求；设计分歧留到第 4 步。
• 此阶段不要实现。

4. 确认设计

进一步提问时，应提出选项和权衡，而不只是开放式探问。

指出解决方案需要做出的关键设计决策。对于每项重要决策，列出少量选项并说明你倾向哪一个，然后等待用户回复。

用户的答复优先于问题描述。确定决策后，如有必要，应通过评论或正文更新问题，使其反映新信息。

5. 提出计划

当你掌握了足够的上下文，能够有把握地勾勒解决方案时，提出一份简要计划： 实现思路、主要部分、如何确认完成，以及仍存的假设。

如何确认完成：对于每项重要行为，都要说明：

• 一个可观察、能判定通过或失败的检查；
• 能证明检查结果的证据（测试、命令及其输出、截图或测量数值）；
• 值得列举的边缘情况。

“能正常工作”不算检查。应提出 Agent 无需询问即可验证的检查。

重大 UI 变更必然需要人工审核：请明确指出并安排审核。

6. 构建

获得确认后，实施商定的计划。只做解决问题所需的最少工作。 进入下一步之前，先运行完成检查，并向用户展示结果及相应证据。

如果构建过程中出现新的设计分歧，先停下来询问；不要擅自决定。

7. 复盘

加载并应用 reflect 技能，对工作进行审慎而非仓促的复盘。向用户发送消息，说明你现在开始复盘。 仅在实现完成后加载此技能。

如果工作与问题描述仍有出入，则更新最初的问题。

指南

代码是判断系统当前行为的依据。用户决定系统应有的行为。问题是起点，而非金科玉律。

信息或决策发生变化时，更新问题；不要让内容过时。