mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-06-15 12:41:26 +08:00
Affaan Mustafa
217 lines
5.7 KiB
Markdown
217 lines
5.7 KiB
Markdown
---
|
|
name: council
|
|
description: 召集四方会议处理模糊决策、权衡取舍及继续/停止决策。当存在多个有效路径且需要在选择前进行结构化异议时使用。
|
|
origin: ECC
|
|
---
|
|
|
|
# 顾问团
|
|
|
|
在模糊决策时召集四位顾问：
|
|
|
|
* 上下文中的Claude声音
|
|
* 怀疑论者子代理
|
|
* 实用主义者子代理
|
|
* 批评者子代理
|
|
|
|
这适用于**模糊性下的决策制定**，而非代码审查、实施规划或架构设计。
|
|
|
|
## 何时使用
|
|
|
|
在以下情况使用顾问团：
|
|
|
|
* 决策存在多个可行路径且无明显优胜者
|
|
* 需要明确权衡利弊
|
|
* 用户要求第二意见、异议或多角度分析
|
|
* 存在对话锚定效应的真实风险
|
|
* 通过对抗性挑战能优化"执行/放弃"决策
|
|
|
|
示例：
|
|
|
|
* 单一仓库 vs 多仓库
|
|
* 立即发布 vs 打磨后发布
|
|
* 功能开关 vs 全面上线
|
|
* 简化范围 vs 保持战略广度
|
|
|
|
## 何时不使用
|
|
|
|
| 不应使用顾问团的情况 | 应使用 |
|
|
| --- | --- |
|
|
| 验证输出是否正确 | `santa-method` |
|
|
| 将功能拆解为实施步骤 | `planner` |
|
|
| 设计系统架构 | `architect` |
|
|
| 审查代码中的错误或安全漏洞 | `code-reviewer` 或 `santa-method` |
|
|
| 直接的事实性问题 | 直接回答 |
|
|
| 明确的执行任务 | 直接执行 |
|
|
|
|
## 角色
|
|
|
|
| 声音 | 视角 |
|
|
| --- | --- |
|
|
| 架构师 | 正确性、可维护性、长期影响 |
|
|
| 怀疑论者 | 质疑前提、简化、打破假设 |
|
|
| 实用主义者 | 交付速度、用户影响、运营现实 |
|
|
| 批评者 | 边缘情况、下行风险、失败模式 |
|
|
|
|
三个外部声音应作为全新子代理启动，**仅提供问题和相关上下文**，而非完整对话历史。这是反锚定机制。
|
|
|
|
## 工作流程
|
|
|
|
### 1. 提取真实问题
|
|
|
|
将决策简化为一个明确提示：
|
|
|
|
* 我们在决定什么？
|
|
* 哪些约束条件重要？
|
|
* 什么算成功？
|
|
|
|
如果问题模糊，在召集顾问团前先提出一个澄清性问题。
|
|
|
|
### 2. 仅收集必要上下文
|
|
|
|
如果决策与代码库相关：
|
|
|
|
* 收集相关文件、代码片段、问题描述或指标
|
|
* 保持简洁
|
|
* 仅包含决策所需的上下文
|
|
|
|
如果决策是战略/通用性的：
|
|
|
|
* 除非能实质性改变答案，否则跳过仓库代码片段
|
|
|
|
### 3. 首先形成架构师立场
|
|
|
|
在阅读其他声音之前，写下：
|
|
|
|
* 你的初始立场
|
|
* 支持该立场的三个最强理由
|
|
* 首选路径的主要风险
|
|
|
|
先完成此步骤，以确保综合意见不会简单镜像外部声音。
|
|
|
|
### 4. 并行启动三个独立声音
|
|
|
|
每个子代理获得：
|
|
|
|
* 决策问题
|
|
* 必要的简洁上下文
|
|
* 严格角色定义
|
|
* 无多余对话历史
|
|
|
|
提示模板：
|
|
|
|
```text
|
|
你是四声部决策委员会中的[角色]。
|
|
|
|
问题：
|
|
[决策问题]
|
|
|
|
背景：
|
|
[仅包含相关片段或约束条件]
|
|
|
|
回复格式：
|
|
1. 立场 — 1-2句话
|
|
2. 理由 — 3个简洁要点
|
|
3. 风险 — 你建议中最大的风险
|
|
4. 意外点 — 其他声部可能忽略的一个方面
|
|
|
|
直接明了，不要含糊。控制在300字以内。
|
|
```
|
|
|
|
角色重点：
|
|
|
|
* 怀疑论者：挑战框架、质疑假设、提出最简单的可信替代方案
|
|
* 实用主义者：优化速度、简单性和实际执行
|
|
* 批评者：揭示下行风险、边缘情况以及计划可能失败的原因
|
|
|
|
### 5. 通过偏见护栏进行综合
|
|
|
|
你既是参与者也是综合者，因此需遵循以下规则：
|
|
|
|
* 不得无故驳回外部观点，需说明理由
|
|
* 若外部声音改变了你的建议，需明确说明
|
|
* 始终包含最强烈的异议，即使你最终拒绝它
|
|
* 若两个声音一致反对你的初始立场，将其视为真实信号
|
|
* 在最终裁决前保持原始立场可见
|
|
|
|
### 6. 呈现简洁裁决
|
|
|
|
使用以下输出格式：
|
|
|
|
```markdown
|
|
## 委员会：[简短决策标题]
|
|
|
|
**架构师：** [1-2句立场陈述]
|
|
[1行理由说明]
|
|
|
|
**怀疑论者：** [1-2句立场陈述]
|
|
[1行理由说明]
|
|
|
|
**实用主义者：** [1-2句立场陈述]
|
|
[1行理由说明]
|
|
|
|
**批评者：** [1-2句立场陈述]
|
|
[1行理由说明]
|
|
|
|
### 裁决
|
|
- **共识点：** [各方达成一致之处]
|
|
- **最大分歧：** [最重要的争议点]
|
|
- **前提检验：** [怀疑论者是否质疑了问题本身？]
|
|
- **建议方案：** [综合后的行动路径]
|
|
```
|
|
|
|
确保在手机屏幕上可快速浏览。
|
|
|
|
## 持久化规则
|
|
|
|
**不要**从此技能向 `~/.claude/notes` 或其他隐藏路径写入临时笔记。
|
|
|
|
若顾问团实质性改变了建议：
|
|
|
|
* 使用 `knowledge-ops` 将经验教训存储在正确的持久化位置
|
|
* 或使用 `/save-session`（若结果属于会话记忆）
|
|
* 或直接更新相关的GitHub/Linear问题（若决策改变了当前执行事实）
|
|
|
|
仅在决策改变实际内容时进行持久化。
|
|
|
|
## 多轮跟进
|
|
|
|
默认为一轮。
|
|
|
|
若用户要求另一轮：
|
|
|
|
* 保持新问题聚焦
|
|
* 仅在必要时包含上一轮裁决
|
|
* 尽可能保持怀疑论者的"干净"状态以保留反锚定价值
|
|
|
|
## 反模式
|
|
|
|
* 将顾问团用于代码审查
|
|
* 在任务仅为实施工作时使用顾问团
|
|
* 向子代理提供完整对话记录
|
|
* 在最终裁决中隐藏分歧
|
|
* 无论重要性如何都持久化每个决策
|
|
|
|
## 相关技能
|
|
|
|
* `santa-method` — 对抗性验证
|
|
* `knowledge-ops` — 正确持久化重要决策变更
|
|
* `search-first` — 在顾问团前收集外部参考资料（如需要）
|
|
* `architecture-decision-records` — 当决策成为长期系统策略时正式化结果
|
|
|
|
## 示例
|
|
|
|
问题：
|
|
|
|
```text
|
|
我们现在应该以 alpha 版本发布 ECC 2.0，还是等到控制平面 UI 更完善后再发布？
|
|
```
|
|
|
|
可能的顾问团形态：
|
|
|
|
* 架构师推动结构完整性并避免混乱的界面
|
|
* 怀疑论者质疑UI是否真的是瓶颈因素
|
|
* 实用主义者询问在不损害信任的前提下现在可以交付什么
|
|
* 批评者关注支持负担、期望债务和上线混乱
|
|
|
|
价值不在于达成一致。价值在于在选择前让分歧清晰可见。
|