case-study-builder
作者 BrianRWagnercase-study-builder 可将客户成果转化为可直接用于提案的案例研究、社会证明和销售故事。它专为 Proposal Writing 设计，帮助你用清晰的前后对比、可量化的结果和可复用的证明素材来打包真实成绩。使用 case-study-builder 指南，可以更快产出更可信的营销内容。
该技能得分 78/100，属于 Agent Skills Finder 中相当稳妥的候选条目。目录用户能较明确地理解何时触发它，并获得可直接使用的案例内容；相比泛用提示词，它能减少试错。但由于技能依赖用户提供的项目细节，而且仓库证据中还存在一些截断或未完成的部分，使用时仍需要一定的人工信息收集。
- 使用场景清晰、触发明确：它直接面向将客户成果转写为用于提案、社会证明和销售沟通的案例内容。
- 工作流结构扎实：它定义了 quick、standard、deep 三种模式，并给出默认值和输出结果，便于代理快速选择合适路径。
- 操作指引到位：上下文加载门槛明确要求 8 个必填字段，并且至少要有 1 个数值结果，有助于提升执行稳定性。
- 没有提供配套文件或脚本，因此是否易于采用，几乎完全取决于 SKILL.md 的说明是否足够清楚，而不是可执行的辅助工具或参考资料。
- 摘录中出现了一个被截断的部分（'Timeline | How long to...'），说明文档可能并不完整，或者需要人工补充理解。
case-study-builder 技能概览
case-study-builder 是做什么的
case-study-builder 技能可以把零散的客户成功笔记，整理成可直接发布的证明素材，用于提案、销售沟通和营销内容。它特别适合那些已经有结果、却缺少一种快速、清晰打包方式的人。如果你需要一个用于 Proposal Writing 的 case-study-builder，这项技能能帮你把事实、成果和背景转化成更像可信证据、而不是空泛套话的内容。
适合谁用
如果你要写提案、销售服务、做客户留存，或者维护成功案例库，就适合用这个 case-study-builder skill。当你已经确认项目确实发生过，但故事素材还很原始、不能直接复用时，它最有价值。反过来，如果你只有一些模糊的好评，却拿不出可衡量的结果，那它的帮助就会有限。
它有什么不同
这个 repo 的结构围绕 mode 和 context gate 来设计，也就是说，它会先向你索取合适的输入，再开始起草。这能减少 case study 最常见的翻车方式：文章看起来很精致，但证据很薄。它真正的优势是速度和复用性；同一组输入，可以同时变成提案片段、社会证明，以及更完整的叙述稿。
如何使用 case-study-builder 技能
安装与首次阅读路径
进行 case-study-builder install 时，先使用 GitHub 上的 repo 路径，然后优先打开 SKILL.md。如果你想最快理解这个技能的工作方式，建议按这个顺序阅读：先看 SKILL.md，再看 repo 级文档（如果有），然后重点看定义 modes、gates 和输出格式的部分。这个仓库里只有 SKILL.md 这一份源文件，所以不需要再去浏览额外的支持层。
需要提供什么输入
这个技能最适合在你提供具体项目事实时使用，而不是只给一句笼统的成功描述。建议至少提供：客户名称或匿名化描述、前期状态、你采取的动作、带数字的后期结果、时间线、你的角色，以及目标受众。好的输入示例是：“SaaS 客户，6 周改版，线索质量很低，我们重做了表单收集流程和落地页，演示请求增加 38%，我负责策略和文案，用于提案章节。”不够好的输入是：“我们帮客户提升了营销效果。”
如何更好地提问
一条高质量的 case-study-builder usage 提示词，会明确告诉技能你想要哪种输出，以及手头有哪些证据。比如：“使用 standard mode。基于这个项目生成一篇可直接放进提案的 case study：B2B fintech，3 周完成 onboarding 修复，支持工单减少 22%，我负责调研和落地实施，客户信息匿名化，并且要能放进 sales deck。”这种提法能帮助技能选对篇幅、语气和证据强度。
工作流程与输出检查
先从你真正需要的 mode 开始：quick 适合插入一段短内容，standard 适合正在推进销售时使用，deep 则适合把一个成功案例进一步做成内容资产。生成后，在复用前至少检查三点：数字是否明确、因果关系是否站得住、语言是否匹配发布渠道。如果结果太像营销话术，就补充更多操作细节；如果显得太单薄，就补上更清晰的前后对比和更收敛的范围。
case-study-builder 技能常见问题
case-study-builder 比普通提示词更好吗？
通常是的，前提是你需要可重复的结构。普通提示词也能写 case study，但当你需要稳定的采集流程，以及从同一个项目产出多个成品时，case-study-builder 会更合适。对于要在提案、落地页和社交内容之间复用证明素材的团队，这一点尤其重要。
我需要完美的指标吗？
不需要，但至少要有一个具体结果。这个技能最强的场景，是后期状态能够量化：收入、节省时间、响应率、转化率、减少工单、交付更快，或类似结果。如果完全没有数字，它仍然可以帮你梳理故事，但说服力会弱一些。
适合新手吗？
适合，只要你能把项目说清楚。case-study-builder guide 对新手尤其有用，因为它会逼你回答那些让 case study 可信的问题。真正的阻碍通常不是写作能力，而是项目事实不完整。
什么时候不该用它？
如果项目还太早、过于保密，或者太模糊，撑不起证据，就不要用它。若你只是想要一段没有真实客户背景的泛化营销文案，这也不是好选择。在这些情况下，用更轻量的提示词，或者换一种写作流程会更稳妥。
如何改进 case-study-builder 技能
提供更强的原始素材
质量提升最大的来源，不是更多提示，而是更好的输入。请补充客户类型、问题、你采取的行动、最终结果，以及这个结果为什么对买方重要。对于 case-study-builder for Proposal Writing，还应该补上提案受众，以及你希望这段证明去化解的反对意见，比如成本、速度、风险或专业度。
减少常见失败模式
最常见的失败，是故事读起来像在自夸，却不像证据。避免这一点的方法，是给技能明确的范围边界，以及一个能对应业务结果的真实数字。另一个常见问题是过度泛化；可以通过明确渠道来修正，比如 website、sales deck 或 proposal insert，这样语气才能贴合实际使用场景。
结合渠道做迭代修改
拿到第一版后，按实际投放渠道继续让它改。比如：“把这段缩短成提案段落”，“把语气改得更适合 LinkedIn”，“把它扩写成适合博客发布的 case study，并加强标题”。这是把一次 case-study-builder skill 运行，变成完整证明素材包、又不必从头重做的最好方式。