find-tool

查找工具

根据用户的实际约束，推荐当前最合适的选项，并提供最新的一手证据作为依据。

工作流

1. 从请求和代码库中推断生态系统、现有技术栈、必要条件、切换成本和决策标准。只有当未知信息会实质性改变推荐结果时才提问。
2. 在添加依赖项之前，先确认标准库、平台或已安装的工具是否足够。
3. 搜索当前权威来源。仅在需要了解相关生态系统的来源检索路径、回退标准、安装惯例和警示信号时，阅读 references/find-tool.md。
4. 根据用户的标准比较可行选项。只有在影响当前决策时，才考虑采用情况、维护情况、安全性、文档、性能、运营成本和生态系统契合度；不要强行套用固定权重或固定数量的候选项。
5. 在证据充分时推荐一个选项。说明决定性权衡、重要风险信号和最接近的替代选项。如果证据难分高下，或没有必要使用外部工具，也要明确说明。

默认设置

• 如果没有代码库证据，默认使用 JavaScript/TypeScript 和 Node.js 工具。
• 条件允许时，优先使用标准库或平台原语。
• 安装 JavaScript 依赖时，优先使用代码库的包管理器，否则使用 ni；对于 macOS CLI，优先选择官方或维护良好的 Homebrew formula。
• 优先查阅注册表、官方文档、代码库、更新日志和安全公告，而非二手比较资料。对于 Agent 技能，请搜索注册表和 GitHub，因为没有任何一个索引是完整的。

完成标准

当推荐有当前来源作为依据、决定标准明确、安装指南符合用户的环境，并且不确定因素或不适用风险清晰可见时，回答即为完整。只有在重复字段有助于快速浏览时，才使用表格。

以 ### 🏆 Pick: <tool> 和决定性理由开篇。接着使用 ### 📦 Install 并提供准确命令；仅在字段重复时，使用简洁的标准/证据表；仅在存在可信且有实质竞争力的备选项时，使用 ### 🥈 Closest alternative；仅在存在重要注意事项时，使用 ### ⚠️ Caveats。比较单元格中使用符号时，必须附带文字说明；不得捏造评分。URL 目标必须保持准确，面向读者的 Markdown 链接须使用描述性文本。安装命令、版本、安全公告和安装程序风险措辞必须保持原样，不得添加修饰。