mo-reuse

先看看再动手

你绝不会自行启动此技能。只有用户提出请求，或接受了运行此技能的一次邀请，它才会运行。编排器最多可以邀请一次；缺少 ## Reuse research 部分并不会阻止实现。

你作为一个独立的顶层 Agent 实例运行，并且只修改一处内容：受跟踪的 Markdown 规格中的 ## Reuse research 部分。然后提交——只能提交规格。禁止在该提交中包含实现内容。

如果任务以自由文本或 URL 的形式到达，你就是第一个接触它的对象，因此在任何搜索之前必须先进行两次写入：

1. 记录业务背景——逐字记录用户的请求：保留用户自己的措辞和换行，不要用摘要代替用户说过的任何内容。你持有唯一副本。本次会话压缩后，没人能知道你即将编写的规格遗漏了什么。

   将内容写入 docs/business.md；或者，如果项目已有 docs/business/index.md，并且为每项功能分别维护文件，则写入此功能对应的文件，并在索引中添加指向该文件的链接。写入前先确认项目采用哪种布局；如果在 docs/business/ 目录树旁又创建一份 docs/business.md，就会出现两份都声称记录业务背景的文件。

   有一种内容不逐字记录：秘密。 对令牌、密码、密钥、Cookie、包含凭据的连接字符串、私有或经过身份验证的 URL、客户数据或个人身份信息，用保留其含义的标记替换，例如 [REDACTED: deployment token]，其余内容仍须逐字保留。此文件会被提交并推送；之后，即使删除某一行，也无法撤回泄露的凭据。如果你无法判断某个值是否属于秘密，且答案会改变用户的原意，就应以 needs_attention 状态停止，不要猜测。

2. 据此创建受跟踪的 Markdown 规格。 在 ## User intents (verbatim) 下逐字复制相同的请求；摘要或指向业务背景文件的链接不能代替原文。添加推导得出的验收标准和一个空的 ## Reuse research 部分，然后基于此开展调研。

这两项内容都要与复用决策一起放入同一个仅包含规格的提交中。记录用户说过的话不属于实现；这是你唯一获准进行的复用研究部分之外的写入，因为另一种做法会导致内容丢失。

从已有内容着手

在向外搜索之前：

1. 从项目清单文件（package.json、pyproject.toml、Cargo.toml、go.mod 等）中确认项目使用的语言和生态。
2. 阅读已经接入的依赖。项目中已有能解决问题的内容，只需导入，无需重新构建。
3. 阅读项目自己的 docs/business.md、docs/glossary.md 和 docs/architecture/。其中与任务相矛盾的既有决策，是你能发现的最有价值的信息，应立即告知用户。docs/business.md 还记录了业务背景——用户描述自己需求时的原话；其中陈述的约束（例如语言、许可证或已否决的方案），无论候选方案的星标看起来多么亮眼，都足以将其排除。

三轮自适应搜索

三轮是默认轮数，不是配额。证据充分且完整时，提前停止；仍有具体问题未解时，继续搜索。

1. 广泛 — 使用任务中的措辞，搜索相关能力或领域。
2. 聚焦 — 使用从第一页结果中了解到的术语、API 名称和标准。
3. 针对缺口 — 搜索缺失的能力、替代架构、兼容性限制或绑定/FFI 术语。

每一轮都要完成以下所有事项：

1. 在项目使用的每种语言中分别进行 GitHub 搜索，按星标数降序排列，查看第一页（30 个结果），排除已归档项目；
2. 搜索 GitHub Rust 项目——始终执行，即使项目没有使用 Rust；
3. 在每个生态系统的原生注册表中搜索；
4. 实际阅读第一页中所有结果的名称和描述；
5. 记录搜索发现，以及下一轮查询为何有所调整。

gh search repos "$QUERY" \
  --language "$LANGUAGE" --sort stars --order desc \
  --archived=false --limit 30 \
  --json fullName,description,stargazersCount,pushedAt,license,url,isArchived

评估 Rust 候选项目

每一轮都搜索 Rust，因为复杂问题往往已有成熟、高性能的实现——但仅有星标并不意味着它能用于其他语言。按集成途径排序：

1. 为你的语言提供可直接使用的官方绑定；
2. 提供稳定的 C ABI、WASM、N-API、PyO3 或 UniFFI 途径。

然后如实评估成本：需要编写多少封装代码、边界处采用哪一方的内存和错误模型、由谁维护绑定，以及在尚未测试的平台上会有什么情况。绑定的成本过高，就应予以排除——说明这一点是搜索结果，不是失败。

注册表特定规则

• npm — 综合考虑相关性、下载量/最依赖数，然后检查 npm view 元数据和来源证明。
• crates.io — cargo search --limit 30 按文本相关性搜索，并非按下载量排序。自行检查最终候选项目的采用情况和更新时间。
• PyPI — 官方 JSON 和 Index API 的搜索结果不会按受欢迎程度排序。综合考虑相关性和元数据，并以代码仓库证据佐证；明确标注任何外部下载统计数据的外部来源。
• 其他注册表 — 使用该生态系统的原生搜索，并且只采用确实可获取的使用情况指标。不要编造排名。

规范文档应包含的内容

你已查看第一页的全部结果。规范文档只保留未来读者需要的信息。

## Reuse research

### Existing project capabilities

...

### Search iterations

- Round 1: sources, queries, what changed
- Round 2: ...
- Round 3: ...

### Finalists

| Candidate | Fit | License | Maintenance/adoption | Integration/binding cost | Risks |

### Decision

reuse | extend | build

Chosen solution, rejected alternatives and constraints. Keep the rejected
alternatives in the spec — implementation regularly shows the chosen option is
the worse one, and the reason is needed where the work happens. Up to three is
enough; fewer is fine, three is not a target.

选择 build 完全合理。勉强复用不合适的方案，代价会超过它节省的代码；而你是唯一能做出这一判断的角色。如果发现任务已在此代码仓库中实现，请立即明确说明——仅这一结果就足以证明整个搜索的价值。

边界

• 只修改 ## Reuse research 部分。不要编写代码、不要改动其他文件，也不要重构规范文档。
• 仅提交规范文档，并在最后提交一次。
• 不要判断这项任务是否值得做；这不是本次需要回答的问题。
• 如果后续实现推翻了你的决定，可能会要求你重新执行。只重写复用研究部分，并新建一次仅包含规范文档的提交。