用途
check-existing 是一个面向开发流程的技能，用于在实现某个功能之前，先弄清楚需求，然后彻底调研是否已经有现成的库、工具，或者项目内部的本地包（monorepo 组件）能够解决该问题。其目的是避免重复造轮子，把需要自行实现的范围降到最低。
何时使用
- 在开始新功能之前（作为进入 Plan Mode 之前的调研环节）
- 当需要判断「自己写还是用现成的」时
- 当需求比较模糊（例如「跟图像处理有关的某个东西」），希望找到准确的现有方案时
即使需求还没有完全确定也可以启动，技能会通过提问来逐步具体化。
工作流程
Phase 1：确认既有知识
在着手之前，先确认既有的判断与经验教训，避免重复劳动：
- docs/decisions/ 中的 ADR 索引（docs/decisions/README.md）
- docs/lessons-learned.md 中相关领域的内容
Phase 2：需求澄清提问（每次一个问题）
避免假设，具体提问，优先使用多选题形式。
- 意图：这个功能想解决的具体问题是什么？现状有什么不满？
- 技术细节：要处理的数据量有多大？批处理还是实时？要嵌入项目的哪个工作流？操作方式是 GUI、自动还是配置？
- 约束与优先级：Must-have / Nice-to-have 分别是哪些？性能要求（速度、内存、精度）如何？是否优先考虑简单性？
- 搜索词：用英语怎么表达？行业术语是什么？有没有知道的类似工具？在 PyPI / GitHub 上用什么关键词搜索？
Phase 3：整理需求定义
整理出如下结构：
## 明确化后的需求
### 核心功能
- 主处理 / 输入格式 / 输出格式
### 技术要求
- 集成位置（项目中的哪个位置） / 性能 / 与既有依赖的关系
### 功能要求
- Must-have / Nice-to-have / 约束与排除项
### 搜索关键词候选
- 主要 / 技术 / 领域
Phase 4：调研现有方案
先在项目内部查找，再分层次检索外部开源方案。
确认项目内部的替代方案（最优先）
- 使用 investigation agent 调研既有实现与类似功能
- 如果项目有本地包或 monorepo 结构，确认其中是否存在可替代的方案
- 用 Bash 的 uv tree / Grep 确认既有依赖与集成位置
分层次检索外部开源方案
- 第一层：PyPI / GitHub Topics / 标准库（WebSearch）
- 第二层：实现示例、对比文章、Stack Overflow（WebSearch / WebFetch）
- 第三层：最新动态与趋势（WebSearch，并明确当前年份）
库的一手文档通过 Context7 MCP（如可用）或官方文档的 WebFetch 获取。
候选方案评估
- 使用 solutions agent 生成并比较多个候选方案（适配度、实现成本、风险）
Phase 5：评估、记录与推荐
输出结构如下：
# 现有方案调研结果
## 需求（Phase 3 的整理结果）
## 调研过程
- 搜索关键词 / 调研来源 / 发现的候选数量
## 发现的现有方案
### 🎯 可完全替代（适配度 90%+）
- 库名 / 集成方式 / 推荐度
### 🔧 组合使用（60-89%）
- 主库 / 补充方式 / 实现工时
### 📚 参考实现（30-59%）
- 参考价值 / 需要自行实现的范围
## 最终推荐
### ✅ 建议采用
- 选择理由 / 集成步骤 / 注意事项
### ⚠️ 需要自行实现的情况
- 现有方案的局限 / 最小实现范围 / 可部分使用的既有功能
调研结论中具有复用价值的部分（库评估、build-vs-reuse 的判断依据），建议记录到 ADR（docs/decisions/）等项目既定的记录位置。
下一步
当需求确定、现有方案也已梳理完毕后，移交给原生 Plan Mode（/plan），或者 superpowers 的 brainstorming → writing-plans。本技能只负责调研，不进行设计与实现。
适用场景
- 新功能立项前的技术选型调研
- 需要判断「自研还是复用」的决策场景
- 从模糊需求出发，寻找精准的现成解决方案
限制
- 本技能只负责调研，不涉及设计与实现，完成后需交接给后续规划流程
- 关于支持的平台、收费方式、价格等信息，资料中暂未提供。