Feasibility

---
name: feasibility
description: 当用户要求「先做可行性研究 / 先评估 / 先调研方案」「XX 能不能做到」「XX 这样改可行吗」，或提出复杂改造、新能力扩展、技术选型、架构调整等需要前期论证的任务时使用。产出结构化可行性报告（现状 → 问题 → 开源参考 → 候选方案对比 → 推荐 + 改动量 → 可行性结论），先对齐方案，等用户确认后再动手。不要用于简单 bug 修复、小功能、样式/文案/配置等低风险改动，或用户已明确要求直接实现的任务
---

## 何时 **不** 需要这个 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 个方案，说明**为什么是它**（不是"更好"，而是"更契合当前 X、Y、Z 约束"）
- 列涉及文件（**绝对路径 + 行号范围**）
- 估算改动行数（新增 / 修改 / 删除，范围即可 `~30 行`）
- 声明 API 兼容性：完全兼容 / 有破坏性变更 / 需迁移

### 可行性结论
- 明确标注：**✅ 可行** / **⚠️ 部分可行**（需妥协，写明） / **❌ 不可行**（给替代建议）
- 列 1~3 个关键风险点
- 收尾一句话征询动手：`"是否开工？确认后我会 ..."`

---

## 输出格式模板

```markdown
## 现状
- [相关文件]：可选的 <绝对路径:行号>
- 现有实现：<一句话>
- [隐性约束]：可选的 <未文档化的前提条件>

## 问题 / 目标
<当前能力 vs 期望能力的 gap>

## 开源参考
- 来源
- 思路
- 关键片段

## 候选方案
| 方案 | 思路 | 契合度 | 改动量 | 风险 |
|------|------|--------|--------|------|
| A | ... | 高 | ~30 行 | ... |
| B | ... | 中 | 全量重写 | ... |

## 推荐：方案 <X>
**理由**：<基于具体约束，不是"更好">

[涉及文件] 可选的，如果有
- `path/a.ts:10-50`（修改 ~30 行）
- `path/b.ts`（新增 ~80 行）

**API 兼容性**：完全兼容 / 破坏性 / 需迁移

## 结论
**✅ 可行** / **⚠️ 部分可行** / **❌ 不可行**

**风险**：
- ...

是否开工？确认后我会 <具体下一步>
```

---

## 反例（禁止）

- ❌ **直接给代码实现** — 用户没让你动手，可行性阶段就写代码是越权
- ❌ **引用不存在的库 / API** — 必须附可验证来源
- ❌ **「应该可以」「大概没问题」** — 结论必须明确 ✅/⚠️/❌
- ❌ **跳过开源调研** — 除非用户明说"凭经验快速估一下"
- ❌ **模糊改动量** — 必须给行数范围或文件数
- ❌ **自动进入实现** — 即使结论是 ✅，也要等用户回复"开工"再动