Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →曖昧な決定、トレードオフ、ゴー/ノーゴーの判断のために4つの声のカウンシルを召集します。複数の有効なパスが存在し、選択前に構造化された異議が必要な場合に使用します。
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | -3% | 0% |
| case-02 | ✗→✓ | ▲ Improved | -7% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 33% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 22% | 0% |
| case-10 | ✗→✓ | ▲ Improved | 19% | 0% |
在模糊决策时召集四位顾问：
这适用于模糊性下的决策制定，而非代码审查、实施规划或架构设计。
在以下情况使用顾问团：
示例：
| 不应使用顾问团的情况 | 应使用 | | --- | --- | | 验证输出是否正确 | santa-method | | 将功能拆解为实施步骤 | planner | | 设计系统架构 | architect | | 审查代码中的错误或安全漏洞 | code-reviewer 或 santa-method | | 直接的事实性问题 | 直接回答 | | 明确的执行任务 | 直接执行 |
| 声音 | 视角 | | --- | --- | | 架构师 | 正确性、可维护性、长期影响 | | 怀疑论者 | 质疑前提、简化、打破假设 | | 实用主义者 | 交付速度、用户影响、运营现实 | | 批评者 | 边缘情况、下行风险、失败模式 |
三个外部声音应作为全新子代理启动，仅提供问题和相关上下文，而非完整对话历史。这是反锚定机制。
将决策简化为一个明确提示：
如果问题模糊，在召集顾问团前先提出一个澄清性问题。
如果决策与代码库相关：
如果决策是战略/通用性的：
在阅读其他声音之前，写下：
先完成此步骤，以确保综合意见不会简单镜像外部声音。
每个子代理获得：
提示模板：
text你是四声部决策委员会中的[角色]。 问题： [决策问题] 背景： [仅包含相关片段或约束条件] 回复格式： 1. 立场 — 1-2句话 2. 理由 — 3个简洁要点 3. 风险 — 你建议中最大的风险 4. 意外点 — 其他声部可能忽略的一个方面 直接明了，不要含糊。控制在300字以内。
角色重点：
你既是参与者也是综合者，因此需遵循以下规则：
使用以下输出格式：
markdown## 委员会：[简短决策标题] **架构师：** [1-2句立场陈述] [1行理由说明] **怀疑论者：** [1-2句立场陈述] [1行理由说明] **实用主义者：** [1-2句立场陈述] [1行理由说明] **批评者：** [1-2句立场陈述] [1行理由说明] ### 裁决 - **共识点：** [各方达成一致之处] - **最大分歧：** [最重要的争议点] - **前提检验：** [怀疑论者是否质疑了问题本身？] - **建议方案：** [综合后的行动路径]
确保在手机屏幕上可快速浏览。
不要从此技能向 ~/.claude/notes 或其他隐藏路径写入临时笔记。
若顾问团实质性改变了建议：
knowledge-ops 将经验教训存储在正确的持久化位置/save-session（若结果属于会话记忆）仅在决策改变实际内容时进行持久化。
默认为一轮。
若用户要求另一轮：
santa-method — 对抗性验证knowledge-ops — 正确持久化重要决策变更search-first — 在顾问团前收集外部参考资料（如需要）architecture-decision-records — 当决策成为长期系统策略时正式化结果问题：
text我们现在应该以 alpha 版本发布 ECC 2.0，还是等到控制平面 UI 更完善后再发布？
可能的顾问团形态：
价值不在于达成一致。价值在于在选择前让分歧清晰可见。
Other measured skills in the registry, with their headline benchmark lift.