需求到技能解码器

它解决什么问题

很多需求在一开始就被错误地包装成方案：「我要做一个 skill」「我必须上 LLM」「得实时响应」——这些假设往往未经检验。结果是团队照着一个伪需求去找轮子，或在错误的抽象层上开工，返工成本极高。这个技能把「一句话需求」当作输入，强制先做需求解构，再去找实现样本，避免"用户说要造汽车，其实他只想从 A 到 B"的经典错配。

它如何工作：六阶段流水线

• 阶段 0 · 需求捕获：最多问 1–2 个澄清问题（使用场景 / 目标用户 / 成功标准），把口语化需求整理成一句原始需求陈述。
• 阶段 1 · 第一性原理拆解（核心）：先浮现假设——列出需求中被当作理所当然的前提；再对每个假设连问"为什么"直到触及不可再分的基本事实；最后重建最简解，输出需求本质（一句话）+ 1–3 条最小可行解假设。
• 阶段 2 · GitHub 寻源：基于需求本质生成关键词，优先运行 scripts/find_repos.py 调用 GitHub Search API，对候选项目按 5 维加权打分——热度（stars）、活跃度（pushed_at）、文档度、相关度、许可证——再用 WebSearch、Trending、awesome-* 列表人工补遗，取 Top-N。
• 阶段 3 · 项目拆解：每个项目按 4 个研究维度分析——系统上下文、领域模块、工作流、关键模块——产出拆解卡。
• 阶段 4 · 对比矩阵：3 个项目横向对比实现方法 / 复杂度 / 外部依赖 / 适用边界 / 最值得借鉴的点 / 最大坑。
• 阶段 5 · 演化分析：拉取 release / commit / changelog，区分被验证保留的做法与被废弃的反模式；同时按发育阶段（幼年 0–10 次、成年 10–100 次、稳定 100+ 次）给出 skill 自身的演化建议，并用 VFM 视角标注优先级。
• 阶段 6 · 生成选项：输出 3–5 个实现路径选项（直接复用 / 融合 X+Y / 从原子重建 / 机械转 skill 等），各带复杂度、依赖、风险与推荐度，不替用户拍板。

输出物与质量门槛

最终必须产出一份 《目标 Skill 规格文档》 作为与 skill-builder 的交接契约，包含：需求本质、候选实现路径、可借鉴项目清单（名称+链接+借鉴点）、对比结论、约束与许可证边界、建议触发词。质量标准是硬性的：阶段 1 未产出需求本质则流程无效；候选项目必须 ≥3 个且带评分依据；选项必须 ≥3 个，禁止只给一个"我觉得最合适"的答案。

适用边界与注意点

这个技能只负责产出选项与证据，最终选型权交还用户，落地构建属于下游 skill-builder 的职责，不要期待它直接给出成品。自动寻源脚本使用未认证的 GitHub Search API，限速 10 次/分钟，高频调用需要自行加 token 或降低频率。它的核心价值在需求侧的严格解构，而非"帮我抄一个开源项目"——机械地把现成项目转成 skill 只是选项之一，且需先确认需求本质是否匹配。