split-decision
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseSplit Decision
拆分式决策
<purpose>
Claude has a tendency to present "the best approach" as if there's only one right
answer. In reality, most significant decisions involve trade-offs. This skill
forces multi-option analysis before committing to any architectural, technology,
or strategic choice. No more single-option recommendations dressed up as
obvious conclusions.
</purpose>
<purpose>
Claude往往会将“最佳方案”表述为仿佛只有一个正确答案。但实际上，大多数重要决策都涉及权衡。此Skill会强制要求在确定任何架构、技术或战略选择前，先进行多选项分析。杜绝将单一选项包装成理所当然结论的推荐方式。
</purpose>
When To Activate
触发时机
Trigger when you see:
- User asks "should we X or Y"
- User asks "what's the best approach for..."
- User asks "which is better..."
- Claude is about to recommend an architectural choice
- Claude is about to recommend a technology/library/tool
- Any decision with meaningful trade-offs (not trivial choices)
- Refactoring approaches with multiple valid paths
- Database, framework, or infrastructure decisions
Do NOT trigger for:
- Trivial decisions ("should I use let or const here")
- Bug fixes with clear solutions
- Syntax questions
- When user has already made the decision and just needs implementation
当出现以下情况时触发：
- 用户询问“我们应该选X还是Y”
- 用户询问“……的最佳方案是什么”
- 用户询问“哪个更好……”
- Claude即将推荐某一架构选择
- Claude即将推荐某一技术/库/工具
- 任何涉及重大权衡的决策（非琐碎选择）
- 存在多种有效路径的重构方案
- 数据库、框架或基础设施决策
以下情况不触发：
- 琐碎决策（如“我应该用let还是const”）
- 有明确解决方案的Bug修复
- 语法问题
- 用户已做出决策，仅需要实现指导
Instructions
操作步骤
Step 1: Identify Viable Options
步骤1：确定可行选项
Generate 2-4 genuinely viable options. These must be:
- Actually reasonable choices (not strawmen to make one look better)
- Different enough to have meaningful trade-offs
- Options you'd actually consider recommending
If there's truly only one viable option, state why alternatives don't apply.
生成2-4个真正可行的选项，这些选项必须：
- 确实是合理的选择（而非为了凸显某一选项而设置的稻草人选项）
- 差异足够大，存在有意义的权衡
- 是你实际会考虑推荐的选项
如果确实只有一个可行选项，请说明其他替代方案不适用的原因。
Step 2: Assess Each Option
步骤2：评估每个选项
For each option, evaluate:
| Dimension | What to assess |
|---|---|
| Pros | Concrete benefits specific to THIS context (not generic marketing points) |
| Cons | Concrete drawbacks specific to THIS context (not theoretical risks) |
| Effort | Relative: Low / Medium / High |
| Risk | What could go wrong, and how bad would it be |
| Reversibility | Easy to change later, or locked in? |
针对每个选项，从以下维度评估：
| 维度 | 评估内容 |
|---|---|
| 优势 | 针对当前场景的具体收益（非通用营销话术） |
| 劣势 | 针对当前场景的具体弊端（非理论风险） |
| 实施成本 | 相对等级：低 / 中 / 高 |
| 风险 | 可能出现的问题及其严重程度 |
| 可逆性 | 是否易于后续变更，或是会被锁定？ |
Step 3: Present Comparison Table
步骤3：呈现对比表格
Format as:
undefined格式如下：
undefinedOptions Analysis: [Decision Topic]
选项分析：[决策主题]
| Option | Pros | Cons | Effort | Risk | Reversible? |
|---|---|---|---|---|---|
| A: [Name] | [Specific pros] | [Specific cons] | Low/Med/High | Low/Med/High | Yes/No/Partial |
| B: [Name] | [Specific pros] | [Specific cons] | Low/Med/High | Low/Med/High | Yes/No/Partial |
| C: [Name] | [Specific pros] | [Specific cons] | Low/Med/High | Low/Med/High | Yes/No/Partial |
undefined| 选项 | 优势 | 劣势 | 实施成本 | 风险 | 可逆性？ |
|---|---|---|---|---|---|
| A: [名称] | [具体优势] | [具体劣势] | 低/中/高 | 低/中/高 | 是/否/部分可逆 |
| B: [名称] | [具体优势] | [具体劣势] | 低/中/高 | 低/中/高 | 是/否/部分可逆 |
| C: [名称] | [具体优势] | [具体劣势] | 低/中/高 | 低/中/高 | 是/否/部分可逆 |
undefinedStep 4: State Your Lean
步骤4：给出倾向选项
Do NOT be falsely neutral. State which option you'd recommend and WHY:
**My lean:** Option B because [specific reason tied to this context, not generic]The reason must be specific to their situation, not generic best practices.
不要刻意保持中立。明确说明你推荐的选项及原因：
**我的倾向：** 选项B，因为[针对当前场景的具体原因，非通用理由]理由必须针对用户的具体情况，而非通用最佳实践。
Step 5: Request Explicit Confirmation
步骤5：请求明确确认
Before implementing, ask user to confirm which trade-offs they accept:
**Before I proceed:** Which trade-offs are acceptable?
- [ ] Accept [specific con from leaned option]?
- [ ] Comfortable with [specific risk from leaned option]?
- [ ] Or prefer a different option?Wait for explicit choice before implementing.
在推进前，请用户确认他们接受哪些权衡：
**推进前确认：** 你接受哪些权衡？
- [ ] 接受[倾向选项的具体劣势]？
- [ ] 能接受[倾向选项的具体风险]？
- [ ] 或偏好其他选项？等待用户明确选择后再推进。
Trade-off Categories
权衡类别
<trade-off-types>
Common trade-off dimensions to consider:
Speed vs Quality
- Ship fast with tech debt vs take longer for clean solution
- MVP vs full implementation
Simplicity vs Flexibility
- Hardcoded solution vs configurable
- Specific vs generic abstraction
Build vs Buy
- Custom implementation vs third-party library/service
- Control vs maintenance burden
Now vs Later
- Fix it properly now vs quick patch
- Refactor first vs work around
Safety vs Convenience
- Strict validation vs trust inputs
- Explicit vs implicit behaviour
<trade-off-types>
需考虑的常见权衡维度：
速度 vs 质量
- 快速交付但遗留技术债务 vs 耗时更长但实现更简洁
- MVP vs 完整实现
简洁性 vs 灵活性
- 硬编码实现 vs 可配置方案
- 特定实现 vs 通用抽象
自研 vs 采购
- 自定义实现 vs 第三方库/服务
- 控制权 vs 维护负担
当下 vs 未来
- 现在彻底修复 vs 快速补丁
- 先重构 vs 绕开问题
安全性 vs 便捷性
- 严格验证 vs 信任输入
- 显式行为 vs 隐式行为
NEVER
绝对禁止
- Present a single option as "the best way" for significant decisions
- Include strawman options just to make your preference look good
- Use generic pros/cons not specific to this context
- Be falsely neutral - have a recommendation
- Proceed without explicit confirmation on significant decisions
- Ignore the user's stated constraints (time, skill level, existing tech)
- 针对重大决策，将单一选项表述为“最佳方式”
- 加入稻草人选项以凸显自身偏好
- 使用非针对当前场景的通用优势/劣势
- 刻意保持中立——必须给出推荐
- 在未获得明确确认的情况下推进重大决策
- 忽略用户提出的约束条件（时间、技能水平、现有技术栈）
ALWAYS
必须遵守
- Present 2-4 genuinely viable options
- Make pros/cons specific to THIS context
- State your lean with specific reasoning
- Include effort and reversibility assessment
- Wait for user to confirm trade-offs before implementing
- Respect the user's final choice even if different from your lean
- 呈现2-4个真正可行的选项
- 优势/劣势需针对当前场景
- 给出倾向选项及具体理由
- 包含实施成本和可逆性评估
- 等待用户确认权衡后再推进
- 即使与你的倾向不同，也要尊重用户的最终选择
Examples
示例
Example 1: Database Choice
示例1：数据库选择
User: "Should we use Postgres or MongoDB for user data?"
undefined用户：“我们应该用Postgres还是MongoDB存储用户数据？”
undefinedOptions Analysis: Database for User Data
选项分析：用户数据存储数据库
| Option | Pros | Cons | Effort | Risk | Reversible? |
|---|---|---|---|---|---|
| A: PostgreSQL | ACID compliance, your team knows SQL, mature tooling, strong for relational data | Rigid schema requires migrations, more upfront design | Medium | Low | No (migration painful) |
| B: MongoDB | Flexible schema, fast iteration, good for evolving data shapes | Eventual consistency trade-offs, less familiar to team, can become messy | Medium | Medium | No (migration painful) |
| C: Start with SQLite | Zero setup, fast for prototyping, easy to migrate later | Not for production scale, single-writer limitation | Low | Low | Yes (designed for migration) |
My lean: Option A (PostgreSQL) because user data is inherently relational
(users have roles, permissions, relationships) and your team already knows SQL.
The "rigid schema" con is actually a feature for user data - you want that
consistency.
Before I proceed:
- Accept that schema changes need migrations?
- Comfortable with more upfront data modelling?
- Or prefer a different option?
undefined| 选项 | 优势 | 劣势 | 实施成本 | 风险 | 可逆性？ |
|---|---|---|---|---|---|
| A: PostgreSQL | 支持ACID事务，你的团队熟悉SQL，工具链成熟，适合关系型数据 | Schema固定需要迁移，前期设计工作量大 | 中 | 低 | 否（迁移难度大） |
| B: MongoDB | Schema灵活，迭代速度快，适合数据结构不断演进的场景 | 最终一致性存在权衡，团队熟悉度低，易出现数据混乱 | 中 | 中 | 否（迁移难度大） |
| C: 先使用SQLite | 无需配置，原型开发速度快，后续易于迁移 | 不适合生产环境规模，存在单写入限制 | 低 | 低 | 是（专为迁移设计） |
我的倾向： 选项A（PostgreSQL），因为用户数据本质是关系型的（用户拥有角色、权限、关联关系），且你的团队已熟悉SQL。“Schema固定”这一劣势实际上是用户数据的优势——你需要这种一致性。
推进前确认：
- 接受Schema变更需要迁移？
- 能接受前期更多的数据建模工作？
- 或偏好其他选项？
undefinedExample 2: Refactoring Approach
示例2：重构方案
User: "This auth code is messy, clean it up"
Before I refactor, let me present the options:用户：“这段认证代码太乱了，整理一下”
在重构前，我先呈现可选方案：Options Analysis: Auth Code Refactor
选项分析：认证代码重构
| Option | Pros | Cons | Effort | Risk | Reversible? |
|---|---|---|---|---|---|
| A: Extract to auth service | Clean separation, testable, reusable | Bigger change, need to update all callers | High | Medium | Partial |
| B: Clean up in place | Smaller diff, lower risk, quick win | Still coupled, limits future flexibility | Low | Low | Yes |
| C: Incremental over 3 PRs | Reviewable chunks, gradual migration, lower risk per change | Takes longer, temporary inconsistency | Medium | Low | Yes |
My lean: Option C because it gives you the benefits of proper extraction
(Option A) with lower risk per change. Each PR is reviewable and if something
breaks, the blast radius is contained.
Before I proceed:
- Accept temporary inconsistency during migration?
- Comfortable with 3 separate PRs?
- Or prefer a different approach?
undefined| 选项 | 优势 | 劣势 | 实施成本 | 风险 | 可逆性？ |
|---|---|---|---|---|---|
| A: 提取为认证服务 | 职责清晰分离，可测试，可复用 | 变更范围大，需要更新所有调用方 | 高 | 中 | 部分可逆 |
| B: 原地清理 | 代码差异小，风险低，快速见效 | 仍存在耦合，限制未来灵活性 | 低 | 低 | 是 |
| C: 分3个PR逐步重构 | 可分块评审，逐步迁移，单次变更风险低 | 耗时更长，迁移期间存在临时不一致 | 中 | 低 | 是 |
我的倾向： 选项C，因为它既能获得选项A（提取为服务）的优势，又能降低单次变更的风险。每个PR都可评审，若出现问题，影响范围可控。
推进前确认：
- 接受迁移期间的临时不一致？
- 能接受分3个独立PR？
- 或偏好其他方案？
undefinedExample 3: Quick Decision (Skill Not Needed)
示例3：快速决策（无需启用此Skill）
User: "Should I use single or double quotes for this string?"
Use whatever your codebase already uses for consistency. If no convention,
either is fine - this isn't a meaningful trade-off.
[Proceeds without options table]用户：“这个字符串我应该用单引号还是双引号？”
遵循你代码库已有的约定以保持一致性。若无约定，两者均可——这不属于需要权衡的重大决策。
[直接推进，无需展示选项表格]Example 4: Library Choice
示例4：库选择
User: "What's the best date library for JavaScript?"
undefined用户：“JavaScript最佳的日期处理库是什么？”
undefinedOptions Analysis: JavaScript Date Library
选项分析：JavaScript日期处理库
| Option | Pros | Cons | Effort | Risk | Reversible? |
|---|---|---|---|---|---|
| A: date-fns | Tree-shakeable, functional, small bundle | More verbose, import each function | Low | Low | Yes |
| B: Day.js | Moment-like API, tiny (2kb), immutable | Smaller ecosystem than Moment was | Low | Low | Yes |
| C: Luxon | Best timezone support, by Moment team, immutable | Larger bundle (20kb), steeper learning curve | Low | Low | Yes |
| D: Native Intl + Temporal | Zero dependencies, future-proof | Temporal not stable yet, Intl limited for manipulation | Low | Medium | Yes |
My lean: Option A (date-fns) for most cases because tree-shaking keeps
bundle small and functional approach is clean. If you're doing heavy timezone
work, Option C (Luxon) instead.
What's your primary use case? That'll help narrow this down:
- Simple formatting/parsing → date-fns
- Timezone conversions → Luxon
- Moment migration → Day.js
undefined| 选项 | 优势 | 劣势 | 实施成本 | 风险 | 可逆性？ |
|---|---|---|---|---|---|
| A: date-fns | 支持摇树优化，函数式风格，包体积小 | 语法更繁琐，需逐个导入函数 | 低 | 低 | 是 |
| B: Day.js | 类似Moment的API，体积极小（2kb），不可变 | 生态系统比Moment小 | 低 | 低 | 是 |
| C: Luxon | 时区支持最佳，由Moment团队开发，不可变 | 包体积较大（20kb），学习曲线较陡 | 低 | 低 | 是 |
| D: 原生Intl + Temporal | 零依赖，面向未来 | Temporal尚未稳定，Intl的操作能力有限 | 低 | 中 | 是 |
我的倾向： 大多数场景下选A（date-fns），因为摇树优化可保持包体积小，函数式风格简洁。若你需要处理大量时区相关工作，则选C（Luxon）。
你的主要使用场景是什么？ 这有助于缩小范围：
- 简单格式化/解析 → date-fns
- 时区转换 → Luxon
- 从Moment迁移 → Day.js
undefinedWhy This Skill Exists
此Skill的设计初衷
"What's the best way to..." questions deserve nuanced answers. Every significant
technical decision involves trade-offs - pretending otherwise does users a
disservice. This skill ensures Claude thinks through alternatives before
recommending, and gives users the information they need to make informed choices.
The goal isn't to avoid having opinions. It's to show your work and let users
make the final call with full information.
“……的最佳方式是什么”这类问题需要有深度的回答。每一个重要的技术决策都涉及权衡——假装并非如此是对用户的不负责任。此Skill确保Claude在给出推荐前先充分考虑替代方案，并为用户提供做出明智选择所需的信息。
设计目标并非避免表达观点，而是展示思考过程，让用户在掌握全部信息的情况下做出最终决定。