feasibilitylisted

## 何时 **不** 需要这个 skill - 简单 bug 修复 / 小功能（直接排查实现，需运行时埋点采集再用 `debug`） - 用户已明确说"直接改"「按你说的做」（跳过论证） - 调整样式、文案、配置这类零风险改动 ## 核心原则 1. **不动手先对齐** — 可行性结论 + 方案选择必须等用户明确确认，未经确认禁止 Write/Edit 业务代码 2. **不凭记忆** — 涉及第三方库 / 开源实现 / 陌生 API 时，**必须**调用 `search` / `github` skill 查证；库/API 文档由 `search` 优先路由到 Context7 MCP，不得编造 3. **证据为准** — 关键结论附可验证来源（仓库 URL、文件路径:行号、文档段落） 4. **量化影响** — 改动量、风险、API 兼容性要写具体范围，不用"很小 / 较大"这类模糊词 --- ## 执行步骤（严格按顺序） ### 识别现状 - 定位相关代码，**不猜路径** - 一句话概括现有实现：**做了什么** + **怎么做到的** - **重点**：指出隐性约束 / 隐藏前提（如「必须 A ≥ B 才能工作」这类未文档化的约束）——这常常就是用户困惑的根源 ### 明确问题 / 目标 - 用户想要的能力 vs 当前差距，一句话说清 - 需求模糊时先提 2~3 个具体问题澄清，**禁止编造需求** ### 调研参考实现（不可跳过） - **必须**调用至少一个检索 skill（`github` / `search`） - 最少覆盖：1 个成熟开源库的核心源码 or 1 份官方文档段落 - 摘录核心 20~50 行代码 + 来源链接（仓库 owner/repo + 路径） - 已在脑子里"知道怎么做"也要查证——你的记忆可能是旧版 API #### 调研工具选择 | 场景 | 推荐方式 | |------|---------| | 读 1~2 个文件 / 知道确切路径 | `gh api ... \| base64 -d`（走 `github` skill） | | 看某个库的文档 / API | `search` skill 优先路由到 Context7 MCP（权威来源，带版本） | | 需读 5+ 个文件 / 跨目录交叉看 / 要搜索仓库内代码 | **浅克隆 + 稀疏检出到 `/tmp`** 本地阅读（见下方） | | 概念性问题 / 找对比方案 | `search` skill（web/exa 检索） | #### 浅克隆 + 稀疏检出（读大量源码时的标准流程） 避免一条条走 `gh api`——历史深度和无关文件都是浪费 ```bash git clone --depth=1 --single-branch --no-tags https://github.com/<owner>/<repo>.git /tmp/fsb-<repo> ``` - 如果已存在则检查是否是同一个 Github 项目 - 临时目录命名：`/tmp/fsb-<repo>` 便于识别 - 用完询问是否清理 `/tmp/fsb-<repo>` ### [列候选方案] > [!NOTE] > **可选的，如果没有多个可选方案则跳过** - 用表格对比：思路 / 契合现有代码风格 / 改动量 / 风险 - **禁止**「各有优劣」「看情况」这种模糊描述 ### 给出推荐 + 改动清单 - 选 1 个方案，说明**为什么是它**（