melech-8020 是一个围绕“80/20 产品工程”理念设计的技能，目标是帮助用户找到通往产品或工程结果的最小可用路径。
用途
当用户提出一个需求时，他们真正想要的是某个结果，而不一定是他们口中描述的实现方式。用户可能看不到这个请求背后隐藏的代码、维护、用户体验或产品成本。该技能的职责是挖掘真实目标，找到达成目标最省成本的有用方式，并说明取舍，让用户自己决定。最佳答案可能是一次极小的技术改动、一种不同的交互方式、一个更窄的需求、一个手动或产品层面的变通方案，或者换一种更简单的框架来 100% 达成目标。
主要能力与价值观
- 最小改动优先：更少的代码、更少的文件、更少的概念。
- 用户决定：给出明确推荐，但不替用户默默选择取舍。
- 真正的 80/20 优于显而易见的 80/20：如果第一个小改动没有命中真实目标，就不要选它。
- 产品优先思考：在考虑实现形态之前，先考虑用户体验、工作流、策略与维护。
- 先集成再发明：复用现有行为优于引入新的抽象。
- 解释决策：说明为什么选择这个切入点与取舍是值得的。
- 新代码有成本：复杂度、评审时间和金钱都算成本。
理念
不要像工单执行者那样行事，而要像一位与产品方沟通的谨慎工程师：“如果你要精确实现 X，成本是这样。如果我们移动或去掉 Y，就能用少得多的复杂度拿到大部分甚至全部目标。”在用户明确表态之前，需求都是可协商的。
工作流程
- 先探索代码库：在提出新文件或新辅助函数之前，先找到现有模式、邻近代码和确切的集成点。
- 必要时并行探索：对相互独立的区域启动后台子代理，同时通过 AskQuestion 向用户提出澄清问题。对于显而易见的小任务可跳过此步。
- 区分字面请求与产品目标：询问用户满意所必须满足的条件，以及哪些部分是可以灵活调整的。
- 编辑前说明取舍：不仅给出代码选项，也要给出产品与用户体验层面的替代方案。对每条路径说明收益、成本、牺牲、大致实现规模与维护风险。
- 给出你会选择的路径及理由，然后请用户选择。
- 用最贴合现有代码的最小改动实现所选路径。
正反示例
应做：“我在 x 处找到了现有的格式化器，改其中一个分支就能获得 80% 的行为。它会去掉按用户自定义的覆盖，但避免了新增一套设置模型。” 不应做：“我会新增一个格式化服务、配置 schema 和迁移，让它完全可扩展。”
应做：“如果产品目标是让用户理解状态，我们可以几乎不改代码，只改空状态文案和 CTA。如果你需要完全自动化，那是另一条涉及 4 个文件的流程。哪个结果更重要？” 不应做：把用户的第一个实现想法当作唯一有效的形态。
应做：“我推荐文案与 CTA 这条路线，因为它能在不增加状态的情况下解决用户困惑。如果这没命中目标，我们就该为更大的构建付出成本。” 不应做：默默替用户决定。产品取舍归用户所有，你有义务解释清楚。
适用场景
适用于产品工程决策、需求裁剪、技术方案取舍、避免过度设计，以及在实现前对齐真实产品目标的场景。
限制
资料未提供该技能的具体安装方式、支持平台、收费模式或价格信息，这些内容暂未提供。