away

Away

这个技能会利用你离开的时间，让一个项目变得更好。它会收集证据、广泛构思点子，在本地分支上实现其中最好的几个，并留下一份两分钟即可读完的报告。

这里重质量胜过重速度。你会离开好几个小时，因此，第一批点子实现并验证后，应从列表中继续挑选下一个点子，而不是停下来。

评审界面用 better-interface，评审差异用 interface-review，探索某个组件的替代方案用 variant，对其进行压力测试用 break。

让使用者受益

每个点子都要回答一个问题：使用这个产品的人是否真的会觉得它变得更好了？指出这个人是谁，以及点子在哪个时刻能帮到他们，例如读者点开失效链接，或访客寻找某篇文章。只让代码更整洁或让 Agent 显得很忙的点子不符合要求。

根据需求证据对符合要求的点子排序。真实流量落到 404 页面算证据，生产环境中的错误也算。产品文案没有兑现的承诺，或当事人已经在同类项目中发布的修复，也算证据。没有证据的点子仍然可以实现，但平局时它会落败，而且差异应保持较小。

偶尔跳出框架

大多数夜晚，最好的点子都是修复和润色。有些夜晚，其中一个点子应该出人意料。它可以是产品自身内容促成的功能、浏览内容的新方式，或能改变当事人工作方式的工具。只要它符合上述要求且差异较小，就可以实现。否则，应将其连同值得一试的理由写进报告。

如果列表里只有稳妥的修复，说明构思步骤还没做完。

遵循仓库惯例

改动应当读起来像是当事人亲自写的。开始实现之前，先找到仓库已经如何解决最相近的问题，并照着做：

• 重用现有组件、hooks 和工具函数。只有现有方案无法满足需求时，才有理由新增基础组件。
• 使用现有设计令牌来设置颜色、间距、圆角、字体和动效。参考最相近的现有界面，不要自行创造取值。
• 遵循现有的文件布局、命名方式、导入风格和 Agent 文档中的规则，包括何时编写注释。
• 界面文案应沿用产品现有的语气、篇幅和标点。
• 保持现有架构。新增状态库、样式方案或数据层只能作为点子写进报告，绝不能在无人监督时实现。

如果同类项目已经解决了相同问题，就移植那个方案，并使用本仓库的设计令牌调整样式。

保持可撤销

当事人回来时应面对各种选择，而不是清理工作：

• 从默认分支创建名为 away/<date> 的新分支。当工作树里有未提交的工作时，应在单独的 git worktree 中进行开发，并保持原有工作一字不动。
• 在本地提交，每项改动单独提交，并遵循仓库自身的提交风格。只有当事人在请求中明确要求时，才推送、开拉取请求、合并、部署、发布内容或发送消息。
• 将已连接的服务视为只读。可以读取分析数据、错误追踪记录和部署日志，但不得更改设置、数据或集成。
• 保留当事人自己的文风。新文案、更新日志条目或帖子应写进报告草稿中，而不是直接编辑已发布的内容。
• 只有同类项目已将某个依赖用于相同用途时，才添加该依赖，并在报告中说明。
• 对测试运行会写入的任何文件创建快照，之后从快照恢复。

1. 了解项目

阅读 AGENTS.md 或 CLAUDE.md、README、近期 git 日志、开放的分支和拉取请求，以及关于当事人的任何已保存记忆。记录他们要求遵循的惯例，例如提交格式、注释规则和组件模式。当你能够说明项目的用途、技术栈，以及评审者会因违反哪些惯例而拒绝改动时，这一步就完成了。

2. 收集证据

阅读所有相关来源。这包括热门页面、404 和引荐来源的网页分析数据、错误跟踪器和运行时日志、CI 结果、未解决的问题和 TODO 注释。还包括产品文案和文档，并对照产品的实际行为进行核查，以及产品最繁忙页面上的控制台。

然后查看这个人的同类项目，看看那里是否已经解决了某个问题，例如搜索对话框、组件或工作流。当每个来源都已阅读，或已说明理由并决定暂不查看时，便算完成。

3. 广泛构思

在做出选择前，至少写出十五个想法。涵盖修复、设计润色、功能、内容、性能、无障碍，以及这个人自己的工具，例如技能或脚本。至少包含三个会改变产品行为，而不只是改变外观的想法。为每个想法写明它帮助的人、相关证据、大致工作量和风险。无法说清能帮助谁的想法，一律删掉。当每个领域都有一个想法，且至少有一个想法会让这个人感到意外时，便算完成。

4. 实现最有力的几个想法

选择证据最充分、且每个都能作为一个小型提交落地的想法。先解决真实的用户痛点，再构建功能，最后进行润色。按照 匹配代码库 中的要求实现每个想法，并在提交前运行项目的检查命令。当每个选中的想法都已提交，或已说明放弃理由时，便算完成。

5. 查看每项改动的实际效果

在用户会接触到每项改动的地方进行测试。界面改动使用浏览器，路由和重定向使用 curl，任何由 AI 支持的功能都使用真实端点。对于视觉改动，要查看浅色和深色主题，以及手机宽度下的显示效果。当每项改动都已确认正常，或标记为尚未验证时，便算完成。

6. 提交报告

最后用一条消息汇报，按以下顺序呈现，让这个人首先看到最重要的信息：

1. 当前情况。 分支、提交数量、任何开发服务器 URL，以及仍在运行的内容。
2. 实现内容。 每项改动各列一条，说明用户现在能看到什么，以及促成这项改动的证据。
3. 验证情况。 区分已确认正常、仅通过类型检查，以及完全未经检查的内容。
4. 由你做出的决定。 代替这个人做出的、他们可能想要撤销的选择。
5. 未实现的想法。 列出其余想法，包括大胆的想法，并分别说明证据和工作量。

保持可逆 中的草稿应和想法一起列出，方便直接粘贴。

完成前检查

模式	修正
提交标题中需要出现“和”	拆成两个提交
某项改动只通过类型检查验证	在运行中的应用里测试，或标记为尚未验证
报告列出提交标题	说明用户现在能看到什么，以及为什么要实现
差异包含这个人尚未提交的文件	将工作移到单独的 worktree，并恢复他们的文件
注释只是在解释代码的作用	删除注释，除非没有它代码会显得不合理
想法列表里只有修复项	回到 3. 广泛构思，补充大胆的想法
某项已实现的想法无法说清能帮助谁	撤销该改动，并将其移入报告
差异中出现了新的颜色、间距值或组件	替换为代码库中最接近的现有选项
还有时间时工作已停止，但仍有想法未实现	实现下一个有证据支持的想法