distill-need 是一个需求蒸馏技能，改编自 AdirD/agent-shell-hamelech 的 melech-distill-need，采用 MIT 许可证。它的核心主张是：用户的请求或他们试图理解的内容并不是不可改动的圣旨，很多时候只是一个“提议的解决方案”、一段密集解释或一个庞大的 PR。AI 不应只盯着字面词语作答，而应先蒸馏出真正的需求，再提供能达成结果的路径，这些路径可能与最初点名要的东西完全不同。
经典例子是“我需要一匹更快的马”：蒸馏出的结果是更快到达 B 点；更好的手段可能是汽车，如果工作地点只有十英尺远，走路也行。
用途上，它要区分四件事：字面请求或表层（点名的功能、工具、PR 缺口或卡住的解释）；真实需求或目标（什么条件成立他们才会满意）；上下文（可能推翻或改变问题的约束）；更好的手段（包括复用、流程变更或干脆不建）。蒸馏结果要呈现给用户，由用户决定，不能悄悄把自己的偏好方案替换进去。
适用时机包括：用户表示正在试图理解某些东西（反馈、PR、设计、聊天记录）；有人请求某个功能、工具或架构，而它可能只是解决方案；一段冗长解释失败、卡点仍是“重点到底是什么”；在构建或审查大型改动前结果尚不清晰。如果卡点是解释正确但心智模型错误，应优先使用 make-it-click（或在其后使用）。distill-need 找的是结果，make-it-click 替换的是失败的心智模型。
工作流程分六步。第一步，抓住提议的解决方案或表层，用一行复述字面请求，并标明它是提议方案而非使命。第二步，蒸馏结果，用最少的提问弄清：完成时什么必须为真、为什么现在就要、如果什么都不变会有什么痛苦；优先 1-3 个高杠杆问题，分叉清晰时批量问，不搞长问卷。第三步，检查会推翻问题的上下文，包括约束、距离、频率、紧迫性、规模、谁在承受痛苦、在他们世界里“完成”意味着什么；缺失且会改变答案就追问，能从仓库或产品安全推断就说明假设。第四步，检查已有方案：代码库、产品或流程中是否已有轮子，是否在重复造轮子，已知库、工具或服务是否已能做；能复用、集成、配置解决就不新造。第五步，提供方案类别：给出 1-3 条通往同一结果但实质不同的路径，至少考虑不建/手工/流程/现有工具、对已有东西做最小改动、以及点名请求（或清理后的版本）是否仍值得做；每条路径说明结果契合度、成本、牺牲什么、何时选它，推荐一条，由用户选择。第六步，交接：如果需求不成立或“走路”胜出就停止，不出计划不写代码；如果仍需构建，对齐概念并选最小有用路径；如果用户只是需要被质疑，就对方向做压力测试；如果用户需要理解，先用平实语言给出蒸馏后的结果，再给 1-3 条路径。
提问过滤器：只问会改变结果定义、方案类别、构建是否合理、或现有方案是否已解决的问题；不问实现细节，不制造需求表演。这个介入可以以“不建”结束。
Do/Don't 示例：要像“你要更快的马。结果似乎是更快到公司。你住十英尺外，走路胜过养马”这样点明；不要开始设计马的优化服务。要像“字面请求：自定义 RBAC 引擎。蒸馏需求：对非管理员隐藏管理界面。两条路由做角色检查可能就够，发明策略框架前请确认”这样对齐；不要把点名的架构当成神圣不可改。给出建议后等待用户选择，绝不悄悄替换请求并开始写代码。