Council 是一个协作式头脑风暴技能，定位为 /debate 的“no, but…”和 /arena 的“只有一个能存活”的生成式对应物：让不同视角相遇、相互构建，再由你收获任何单一视角都无法产生的成果。你担任主持者，不添加自己的想法——刺激语来自牌库，因此你的品味不会进入创意池。
【两种模式】 Live 模式：2-4 名具名队友通过消息实时交流；需要主会话与支持实时团队的运行环境（Claude Code agent teams），需要可读本技能文件夹及相邻的 heavy-think、允许运行 python3、对工作目录 .council/ 有写权限；不支持压缩后恢复。 Full 模式：5-12 个子代理（默认 8），通过彼此的文件夹跨轮次交流；由你在综合阶段挑选短名单；评审依据书面评分标准盲评；状态保存在磁盘上，可跨压缩恢复；成本约为单次运行的 3-5 倍，council.py plan 会打印调用数。若 Live 模式前置条件不满足，应说明并提供 Full 模式，而非默默模拟。
【视角牌库】 牌库位于 heavy-think 技能的 references/perspectives.json，由 deck.py 发放。每张成员卡包含一个视角镜头（谁在看，来自六大类：challenger 挑战者、stakeholder 利益相关者、temporal 时间、systems 系统、craft 手艺、wildcard 野牌，以及该镜头使用的工具）和一种技法（如何生成：SCAMPER、逆向头脑风暴、强制混搭、TRIZ 原理等）。随机发牌始终会安排挑战者、利益相关者和时间镜头（4 人以上加一张野牌），分散类别，并偏好与已入座镜头冲突的视角。预设或 --lenses 是刻意选择并会保留。也可混入针对本问题的自定义镜头，格式为 Name: 它追问的问题。
【评分标准】 creative 用于创意构思；decision 用于任何要交付并运行的东西（会权衡运行成本）。预设会设定标准，--rubric 可覆盖。对于决策型问题，可考虑 --no-technique，因为强制技法可能让技术性答案显得花哨。
【Full 模式流程】
- 确定规模、命名所用模型并事先说明；判断类工作（发散、交叉、聚类、打分及你的综合）使用本会话模型，developer 与 stress 任务使用快速档模型；记录 init --model。
- 写简报 .council/brief.md，需自包含：开放式问题、目标对象、约束、已有事物、理想结果、用户已有或已否定的想法；不添加用户未给的约束，不写入自己的偏好想法。
- 运行 COUNCIL init 完成发牌、适配简报、安排成员圆环座位并写入 council.json。
- 用 COUNCIL next 驱动循环：diverge（各自独立）→ cross1..crossC（读取圆环上相隔 k 座的成员并构建，最后一轮加入正对面成员及各自刺激语）→ cluster（策展人合并为带谱系的概念池，加最多 3 个孤例）→ score（独立盲评）→ develop（每个短名单概念一名开发者）→ stress（红队与事前验尸）→ DONE。每个阶段用 COUNCIL prompts 生成任务、以滚动并行池启动子代理，阶段排空后运行 COUNCIL next（必要时 collect）。
- 收获与综合由你完成：运行 COUNCIL harvest，只读 develop 与 stress 文件，将评审总分视为排序而非裁决，亲自读developed 概念。回复应是关于用户问题的一份专家答案，而非会话报告，开头先给答案；不要出现流程叙述（成员、轮次、评分、概念编号、预算等）；说明每个想法对用户既定目标的贡献（用用户自己的单位与诚实的区间）；每个想法都要给出本周可启动的玩法（做什么、在哪、多久、继续或停止的信号）；短名单每条包含概念两行、对目标的贡献、本周玩法、最强压力测试发现及是否幸存、其非显而易见之处；列出值得保留的张力、长线押注和其余概念一句话简述。
【限制与规则】 主持者只引导不生成；先发散后收敛，评分阶段之前不评判；仅 developer 与 stress 可联网，成员、策展人和评审离线工作；每个子代理通过 prompts 获得逐字节相同的简报，不得给某个成员添加提示；运行期间不读想法、构建或评分文件；压缩后先 COUNCIL status 再 COUNCIL next；在 init 所在目录运行所有命令；若概念会改动用户项目文件，先询问不得直接应用。代理声称的具体事实（统计、法律、存在的项目）需核实、删除或标注。
【分类】该技能用于协作式头脑风暴与多视角创意扩展，属于写作与研究中的构思支持，归入 writing。