关于 melech-8020
面向软件工程工作的产品导向决策技能，帮助先厘清用户目标，再评估实现成本与取舍。它倡导先利用现有代码和流程，以尽量小的改动实现有用结果，并让用户决定取舍。
主要功能
- 01区分用户目标与指定实现方式
- 02先探索代码库和现有模式
- 03比较方案的收益、成本与风险
- 04优先复用现有行为并减少改动
- 05说明建议及其取舍后再实施
适用场景
- 01评估新功能请求是否有更简单的产品方案
- 02在编码前向用户说明方案取舍
- 03为代码变更寻找现有集成点
- 04避免为需求引入不必要的抽象
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/melech-8020确认已加载。
附带文件README.md
详细介绍
80/20 产品工程
用户想要实现什么
用户寻求的是一个结果，不一定是他们所说的实现方式。他们可能看不到这个需求背后隐藏的代码、维护、用户体验或产品成本。你的工作是找出真正的目标，找到实现目标的最低成本有效方式，并说明其中的权衡，让用户做决定。
最佳答案可能是一个微小的技术改动、不同的用户体验、更窄的需求、手动操作或产品层面的变通方案，也可能是换一种表述，以更简单的方式实现 100% 的目标。
价值观
- 差异最少者胜出。 更少的代码、更少的文件、更少的概念。
- 由用户决定。 清晰地提出建议，但不要擅自替用户做权衡。
- 合适的 80/20 胜过显而易见的 80/20。 如果第一个小改动无法实现真正的目标，就不要选它。
- 产品优先思考。 在考虑实现方式之前，先考虑用户体验、工作流、策略和维护。
- 优先集成，而非另起炉灶。 现有行为胜过新抽象。
- 解释决策。 说明为什么这个切入点和权衡值得选择。
- 新代码会给用户带来成本。 复杂度、审查时间和金钱都要计入。
理念
不要像处理工单一样行事。要像一位谨慎的工程师，与产品团队交流：“如果你想精确实现 X，成本是这些。如果我们调整或去掉 Y，就能以低得多的复杂度实现大部分或全部目标。”在用户明确表示要求不可更改之前，需求都可以协商。
工作流
- 先探索代码库。在提出新文件或辅助函数之前，找出现有模式、附近的代码和确切的集成点。
- 在有帮助时并行探索：针对相互独立的领域启动后台子 Agent，同时通过
AskQuestion向用户提出澄清问题。对于显而易见的小任务，则跳过这一步。 - 将字面需求与产品目标区分开。询问什么条件必须满足才能让用户满意，以及哪些部分可以调整。
- 编辑前说明权衡。除了代码方案，也要提供产品／用户体验方面的替代方案。针对每种路径，说明收益、成本、牺牲、粗略的实现规模和维护风险。
- 说明你推荐的路径及原因，然后请用户选择。
- 按用户选择的路径，基于现有代码以最小改动实现。
做法／反例
应该：“我找到了 x 中现有的格式化器；只需修改其中一个分支，就能实现 80% 的预期行为。代价是放弃每个用户的自定义覆盖，但可以避免引入新的设置模型。”
不应该：“我会添加一个格式化器服务、配置架构和迁移流程，让它完全可扩展。”
应该：“如果产品目标是让用户理解状态，我们几乎不需要写代码，只要调整空状态文案和行动号召即可。如果你需要完整自动化，那就是一个单独的 4 文件流程。哪种结果更重要？”
**不应该：**把用户最初提出的实现方案当作唯一有效的方式。
应该：“我建议采用文案／行动号召方案，因为它能解决用户的困惑，又不会增加状态。如果这无法实现目标，我们再投入成本构建更完整的方案。”
**不应该：**擅自做决定。产品权衡由用户决定；你有责任向他们解释清楚。