用途 本技能把一个只有一句话描述的软件解决方案创意，推进到有依据的“构建 / 转向 / 不构建”决策。它先做精简访谈以界定研究范围，再围绕市场、竞争、技术和变现等维度开展真实调研（网络 + GitHub），最后交回结构化报告，其中包括现有开源项目中许可足够宽松、可以作为起点直接fork而非从零构建的候选。该技能只负责评估与研究，不编写产品代码，也不替代法律或财务建议。
主要能力
- 分步范围访谈：逐个询问目标用户/ICP、问题与紧迫性、团队与约束、时间预算、技术熟悉度、商业模式意向、研究深度和优先领域；每项都有默认值，回复“skip”或留空即接受默认。
- 平台适配：开始访谈前加载当前智能体环境的参考文件并遵循其工具指引（与repo-init共享），提供Copilot CLI、Codex、Gemini CLI的映射；若平台有原生结构化提问/输入工具，优先使用。
- 研究执行：按references/research-playbook.md执行，覆盖市场与需求信号、商业竞品格局、GitHub/开源竞品研究（寻找候选仓库、提取star数、活跃度、许可证并分类为fork候选）、技术可行性信号、变现可比案例、法律/监管/商标风险提示、以及适合所述团队规模的真实上市渠道。
- 许可证分类：使用references/license-guide.md，不得根据仓库名称或描述猜测许可证，只依据仓库实际报告的许可证（GitHub检测到的许可证元数据或抓取的LICENSE文件）分类。
- 时间盒：Quick gut-check为前3-5个竞品和前3-5个GitHub仓库；Deep dive为各前5-8个，另加变现/法律/上市细节。
- 证据纪律：每个事实性主张（竞品定价、仓库star数、市场信号）都必须追溯到本次会话实际抓取的内容并在旁边附来源链接；查询失败或页面无法抓取时写“unverified”并继续，绝不编造数字、star数、许可证名称或活动日期；优先使用一手来源。
- 综合评分：对市场需求的活跃度与付费/主动寻求证据、差异化、技术可行性、变现潜力、竞争强度（空间未饱和/商品化时高分）、监管/法律风险（障碍少时高分）等维度打1-5分并各附一行理由，汇总为Strong Go / Conditional Go / Pivot Suggested / No-Go一个总体结论，说明最驱动该结论的一两个因素，并保持平衡，不吹捧。
- 报告产出：按references/report-template.md填入访谈答案与研究发现，写入当前工作目录的feasibility-study-<idea-slug>.md（若目录不是明显的临时/笔记位置，先与用户确认文件名和位置），然后在对话中呈现精简版：创意摘要、总体建议、前3个竞品、首选fork候选（如有）和下一步。
- Fork候选展示：若发现标记为Forkable的仓库（宽松许可，见许可证指南），在报告和对话摘要中都单独醒目标出，包含仓库、star数、最近活动、许可证和契合理由的表格，并给出建议下一步如gh repo fork org/name --clone（或git clone + 脱离上游）；同时说明契合点（功能重叠、维护健康）和缺失点（用户仍需自行构建的差距），将fork定位为抢先起步而非成品。若用户想在承诺前深入查看某个fork候选的实现层面，建议使用codebase-deep-dive。
使用方式 在支持该技能的智能体环境中调用。若用户已粘贴创意描述，则用1-2句话确认后直接进入访谈；否则先问“创意是什么？几句话即可——它做什么、面向谁？”。访谈阶段一次只问一个问题，不要一次性抛出全部问题；对推断出的默认值（如目标用户或技术栈）要明确说明是推断所得，再继续。完成后按上述流程执行研究、评分和报告。
交接建议 若总体结论为Strong Go或Conditional Go，建议以audience-behavior-study作为自然下一步（深入研究目标用户在网络上的行为、痛点、语言和渠道，可在构建或撰写文案前进行），可复用本报告中的创意摘要和目标用户；若用户想直接进入构建选项，solution-candidate-design可复用本报告的fork候选和技术可行性发现；若用户已明确方向，可直接建议repo-init。
适用场景 适用于SaaS副业项目、内部工具、创业构想等软件解决方案创意的早期可行性评估，尤其适合个人开发者或小团队在投入构建前判断市场、竞争、技术、变现和合规风险，并寻找可fork的开源起点。
限制
- 只产出决策支持报告，不写产品代码、不是完整商业计划、不是法律意见。
- 许可证声明不构成法律建议：报告中Fork Candidates部分须始终包含免责声明，说明许可证分类只是起点，用户应核实实际LICENSE文件，并在商业化使用fork衍生品前检查商标/品牌限制、双许可或CLA要求。
- 不得编造研究：不虚构star数、定价、许可证名称或日期，无法验证的内容应标注。
- 应尊重用户所述约束：技术可行性和上市渠道建议须匹配第一步中的团队规模与时间预算，例如用户说是“个人、周末”时，不应推荐假设有资金团队的运动或架构。