为代理编写内容
使用此技能编写的内容，其读者是一个仅拥有文本的代理。它没有看到对话，无法询问你的意图，并且会严格按照文字的字面意思和全部努力去执行。大多数失败都源于你知道的内容与最终落实到页面上的内容之间的差距。因此，请从读者的角度出发：在编写之前，确定工作的终点、读者所处的情境以及它需要的材料；然后，用读者无需你协助就能理解的词语来编写。
两种输入
粗略请求（例如：“写一份摘要，让代理修复不稳定的登录测试”）：从对话和工作区中收集事实，然后从头开始起草。
现有提示：保留它。进行最小的一组编辑，以修复实际存在的问题，在有效的地方保留其结构和措辞，并且不要添加其作者未曾陈述的要求。完全重写会掩盖哪些改动是关键的，并悄悄丢弃作者原本的意图。以下默认规则仍然适用：如果提示缺少角色句、示例或结束检查，请添加它们。每当你添加某些内容（无论是这些项目，还是弥合实际差距的规则）时，在交付时列出它们。
如果只有用户知道的事实会改变读者交付的内容或它可以做的事情，请在编写前询问：最多几个问题，每个问题附带你的推荐答案。否则，选择一个合理的默认值并将其列为假设。
编写之前
工作的终点
说明目标、为什么它重要（谁使用结果，用于什么目的）、什么算完成以及需要交还什么。描述目的地，而不是路线：给出成果、成功标准和约束条件，让读者选择路径。当前的模型比你制定的顺序规划得更好，而且你猜错的一步仍然会被执行。仅在顺序本身就是一个要求时才列出步骤，例如必须在部署之前运行的迁移。
之前：1. 打开 refresh.ts。2. 将 refresh() 包装在 try/catch 中。3. 重试三次。4. 运行测试。
之后：当会话超时时，客户端应静默地更新令牌，以便用户保持登录状态。完成标准：tests/auth/refresh.test.ts 中新的超时测试用例通过，且现有测试均未失败。保持 AuthClient 的公共 API 不变，因为其他三个包会调用它。
将质量形容词转化为读者可以应用的衡量标准。“全面”、“简洁”和“只报告重要的”会被逐字且不可预测地解释：一个被告知只报告重要问题的审查者会发现次要问题，并对其保持沉默。明确阈值，或者明确说明保留什么、删除什么。如果后续步骤会过滤结果，请要求返回所有内容。
之前：仔细审查，只报告重要问题。
之后：报告你发现的每一个问题，包括你不确定的问题，并将每个问题标记为“破坏行为”或“仅限样式”。后续步骤会进行过滤。
读者所处的情境
当文本分配任务时（摘要、系统提示、Issue、计划或交接），以一句角色描述开头：读者是谁，它在此任务中的功能，以及它处于什么情境。“你是这个 Pull Request 的代码审查者，这个 PR 不是你写的；团队计划今天合并它。”角色设定了读者的视角及其负责的内容。工具或技能的描述没有角色；它们说明这个东西是什么以及何时使用它。
然后，告诉读者它在其位置上无法看到的内容：是否有人可以在任务进行中回答问题，还是它无人值守地运行；谁在同一文件或系统中工作；它的更改是否受到审查或可逆；它应该评估还是更改事物；以及它可以在不询问的情况下做什么，包括是否可以进一步委派。明确说明哪些特定情况需要停下来报告。“不确定时询问”会让读者去猜测，最终它要么什么都问，要么什么都不问。
你无人值守运行；在你完成之前，没有人可以回答问题。只有在修复会删除数据或触及 src/auth/ 之外的代码时，才停下来报告。另一个代理正在同时编辑 docs/，所以请离开那个目录，不要恢复你没有做出的更改。
读者需要的材料
对于每个来源，给出其位置以及需要从中获取什么。指向读者可以自行打开的内容（文件路径、命令、它可以访问的 URL），而不是转述，以便它阅读真实的内容。将在你上下文中存在的内容完整写出：对话中做出的决定、用户对某条需求的原始表述、你运行命令的结果、已经排除的方法及其原因。
之前：参见 docs/ 和我们之前的讨论。
之后：阅读 docs/billing.md 的“退款”部分，了解舍入规则。有一条需求不在任何文件中；用户的原话是：“即使经过货币转换，部分退款也绝不能超过原始费用。”
当你包含日志、用户文本或另一个代理的输出时，将其放在一个清晰标记的块中，并说明这是工作材料，而不是指令。在引号内的文本或数据块通常被视为内容，不具有权威性。
编写内容
使用读者的语言，而不是你的。在工作过程中，你创造了一些标签（“选项 B”、“懒惰路径”、“P2 问题”）和简写（“→ 锁竞争”），这些对读者来说毫无意义。用它们所代表的内容替换每个标签，对真正的术语定义一次，并且像从头解释一样进行编写。在描述之前已完成的工作时，说明是谁做的，这样读者就不会认为它自己采取了这些行动。
之前：选项 B 被排除（→ 锁竞争）；继续使用惰性初始化，注意 P2 陷阱。
之后：上一个会话排除了在每次请求时重建连接池的做法：在负载下，p95 延迟从 80 毫秒上升到 400 毫秒，原因是锁竞争。当前的方法是在首次使用时创建池。仍然存在一个已知问题：...
为每条规则提供其原因的从句（“...因为一个脚本解析此字段”）。原因让读者能够处理你未列出的情况，并显示规则的适用范围。只有当任何有能力的模型已经知道原因，或者上下文使原因显而易见时，才省略它。
每条规则陈述一次，放在它所属的位置。重复并不会增加权重；它会导致读者过度应用规则（重复的“先询问”行会变成对安全步骤的停滞），并且副本会在编辑过程中逐渐偏离。出于同样的原因，使用平实的措辞：不要使用大写、IMPORTANT 之类，或“这是关键的”、“不要懒惰”等压力性语言。将“绝不”、“始终”等绝对词汇保留给真正的不变量，例如安全限制和不可逆的操作。
不要规定如何思考。省略“逐步思考”以及要求将推理过程写入答案或标签；当前的模型会自行推理，有些模型会拒绝转述其推理过程的请求。如果你需要看到原因，可以要求一个简短的解释或支持性证据，例如文件：行引用或命令输出。
在修复一个已知的失败时，写出其背后的原理及原因，而不是仅仅禁止你看到的那个特定实例。一份禁令列表只覆盖它列出的内容；一条原理也会覆盖邻近的情况。
之前：不要使用 Object.create()。不要使用 proto。
之后：优先使用显式组合而非原型操作，因为这里的审查者更喜欢自上而下阅读的代码。
写成段落。仅当项目真正是并列或顺序关系时，才使用列表：字段、有序步骤、独立的检查。项目符号会去掉连接指令的“因为”和“除非”，并且读者倾向于模仿他们得到的格式。
包含一个读者应产生的内容的简短示例，并将其标记为示例；它传达形式、语气和详细程度，比一段描述更好。仅当预期的输出仅凭文字本身就不言自明时（例如，要运行的单个命令），才省略示例。
以读者在报告完成之前要运行的检查结束任务分配文本：如果存在，则是指能证明结果的命令或测试；否则，是需要重新检查的完成标准。要求它清楚地说明任何它无法验证的内容。
交付
交出最终的文本，准备好粘贴或已写入其文件，使用现有提示的语言或用户要求的语言。在文本之外，用几行列出你做出的、用户可能想要更改的假设。将你的设计说明保留在文本之外。
在交付之前，像读者一样通读草稿：有能力，但只拥有此页面。在任何读者需要猜测你的意图的地方，修改页面。