Cursor Council

🎭 Cursor Council — 我的编程前辈团

Cursor CLI 需要真实 TTY，所以一切都通过 tmux 操作。 这个 skill 的本质：用 tmux 管理多个 Cursor 实例，让它们并行干活或者扮演大牛帮我分析问题。

前置条件

which tmux && agent --version 需要 cursor-agent skill 已配置好、agent login 已完成。

模式一：并行施工 🏗️

场景：一个大任务可以拆成互不冲突的子任务，多个 Cursor 同时干。 核心原则： 每个 Cursor 负责不同的文件/模块，绝对不能有文件冲突 有依赖关系的任务必须等前置完成后再启动 最好每个 Cursor 在不同分支上工作 操作流程： # 1. 拆任务——先想清楚再动手 # 问自己：这些子任务之间有没有文件交叉？有没有先后依赖？ # 2. 创建 tmux sessions PROJECT_DIR=~/Codes/my-project for name in frontend backend tests; do tmux kill-session -t cursor-$name 2>/dev/null || true tmux new-session -d -s cursor-$name tmux send-keys -t cursor-$name "cd $PROJECT_DIR" Enter done # 3. 派活 tmux send-keys -t cursor-frontend "agent -p '重构 src/components/ 下的表单组件，统一用 composables 模式' --force" Enter tmux send-keys -t cursor-backend "agent -p '给 src/api/ 下所有接口加上错误处理和重试逻辑' --force" Enter tmux send-keys -t cursor-tests "agent -p '补全 tests/ 下缺失的单元测试，覆盖率要到 80%' --force" Enter # 4. 巡查进度 for s in cursor-frontend cursor-backend cursor-tests; do echo "=== $s ===" tmux capture-pane -t $s -p | tail -10 done # 5. 全部完成后合并验证 任务拆分策略： 策略适用场景示例按模块Monorepo、前后端分离frontend / backend / shared按分支多个独立 featurefeat/auth / feat/dashboard按类型实现+测试+文档*.ts / *.test.ts / *.md 注意事项： 16GB 内存建议最多 3-4 个并行 Cursor 如果某个 session 5 分钟没输出，可能卡住了，tmux send-keys -t $session C-c 中断 看到 "waiting for approval" 就 tmux send-keys -t $session y 用 --force 要谨慎——确保在独立分支上、文件有 git 追踪 → 更多细节见 references/parallel-execution.md

模式二：前辈议会 🧙‍♂️

• 场景：遇到复杂技术决策，需要多角度分析。让不同模型扮演技术大牛，从各自的哲学视角给出建议。
• 为什么有效：
• 模型训练数据里包含大量技术大牛的文章、演讲、代码，让它"成为"某个人能激活这些深层知识。而且不同大牛代表不同流派，天然形成视角碰撞。
• 角色分配逻辑：
• 角色模型选择思维特点应该问什么架构师Opus（深度推理）看长远、找边界、想极端情况架构设计、安全隐患、5年后会不会后悔工程师Sonnet（快速实用）讲效率、抓重点、先跑起来实现成本、快速方案、技术债平衡批判者GPT（不同视角）挑毛病、给替代方案、打破惯性有没有更好的路、假设是否成立
• 操作流程：
• # 1. 准备问题（写清楚背景、选项、约束）
• cat > /tmp/council-question.md << 'EOF'
• ## 问题：消息队列选型
• ### 背景
• 项目需要一个消息队列处理异步任务，日均消息量 ~50 万条。
• ### 选项
• A. Redis Streams — 团队熟悉，但持久化能力有限
• B. RabbitMQ — 成熟稳定，但运维成本高
• C. NATS — 轻量高性能，但生态较小
• ### 约束
• 团队 3 人，运维能力有限
• 需要 at-least-once 语义
• 预算有限，优先用已有基础设施
• EOF
• # 2. 准备各角色的 prompt
• cat > /tmp/council-opus-prompt.txt << 'EOF'
• 你是 Joe Armstrong，Erlang 和 OTP 的创造者。
• 你的核心信仰：进程隔离、Let it crash、消息传递是并发的正确抽象。
• 你用电话交换机的经验看待所有分布式系统问题。
• 请从你的视角分析这个消息队列选型问题：
• [粘贴问题]
• 分析要点：
• 1. 哪个选项最符合你的并发哲学？
• 2. 容错和故障恢复方面各有什么隐患？
• 3. 如果是你来设计，你会怎么做？
• 4. 一句话犀利点评
• EOF
• cat > /tmp/council-sonnet-prompt.txt << 'EOF'
• 你是 TJ Holowaychuk，Express/Koa 的作者，写过 1000+ npm 包的极简主义者。
• 你的风格：用最少的代码解决问题，讨厌过度工程化。
• 请从你的视角评估这个消息队列选型：
• [粘贴问题]
• 评估要点：
• 1. 哪个方案能最快跑起来？
• 2. 哪个方案最不容易让 3 人团队踩坑？
• 3. 有没有更简单的替代方案？
• 4. 用代码示例说明你推荐的最简方案
• EOF
• cat > /tmp/council-gpt-prompt.txt << 'EOF'
• 你是 Ryan Dahl，Node.js 和 Deno 的创造者。
• 你最大的特点是敢于反思自己过去的设计错误，你曾公开说 Node.js 有 10 个设计遗憾。
• 请用你反思和重新设计的眼光审视这个问题：
• [粘贴问题]
• 思考方向：
• 1. 这三个选项是否都在错误的层面解决问题？
• 2. 有没有根本不需要消息队列的设计？
• 3. 选了之后最可能后悔的点是什么？
• 4. 如果让你重新设计，你会怎么做？
• EOF
• # 3. 开会
• for role in opus sonnet gpt; do
• tmux kill-session -t council-$role 2>/dev/null || true
• tmux new-session -d -s council-$role
• tmux send-keys -t council-$role "cd $PROJECT_DIR" Enter
• done
• tmux send-keys -t council-opus "agent --model claude-opus-4-6 -p \"\$(cat /tmp/council-opus-prompt.txt)\" --force --output-format text 2>&1 | tee /tmp/council-opus-output.txt" Enter
• tmux send-keys -t council-sonnet "agent --model claude-sonnet-4-5 -p \"\$(cat /tmp/council-sonnet-prompt.txt)\" --force --output-format text 2>&1 | tee /tmp/council-sonnet-output.txt" Enter
• tmux send-keys -t council-gpt "agent --model gpt-5.2 -p \"\$(cat /tmp/council-gpt-prompt.txt)\" --force --output-format text 2>&1 | tee /tmp/council-gpt-output.txt" Enter
• # 4. 等待完成后收集输出（通常 2-5 分钟）
• # 5. 综合分析，形成结论
• → 人设库和 prompt 模板见 references/persona-engineering.md
• → 议会流程详解见 references/council-deliberation.md

前辈人设速查

根据问题领域选择合适的"前辈"：

并发 / 分布式

前辈哲学适合问Joe Armstrong (Erlang)Let it crash、进程隔离并发安全、容错设计Leslie Lamport (Paxos)形式化验证、分布式共识一致性、状态机Martin Kleppmann (DDIA)数据密集型应用、CRDT数据一致性、分区

Node.js / JavaScript

前辈哲学适合问TJ Holowaychuk (Express)极简主义、一个函数搞定最佳实践、API 设计Ryan Dahl (Node/Deno)反思与重构、承认错误架构反思、根因分析Sindre Sorhus (1000+ npm)小而美、单一职责工具库设计、代码简化

架构 / 工程

前辈哲学适合问Martin Fowler渐进式改进、模式语言重构策略、设计模式Uncle Bob整洁代码、SOLID 原则代码质量、可维护性Linus Torvalds务实、性能优先、直言不讳代码审查、性能问题

函数式 / 哲学派

前辈哲学适合问Rich Hickey (Clojure)简单≠容易、不可变性复杂性分析、状态管理Simon Peyton Jones (Haskell)类型系统、纯函数类型设计、抽象建模 → 完整人设库和 prompt 示例见 references/persona-engineering.md

推荐人设组合

常见场景的"前辈团"速配： 架构设计评审：Fowler（架构模式）+ DHH（约定优于配置）+ Torvalds（过度设计批评） 并发问题诊断：Armstrong（Let it crash）+ TJ（异步模式）+ Dahl（反思根因） 代码质量整治：Fowler（渐进重构）+ Uncle Bob（Clean Code）+ Hickey（复杂性根源） 技术选型决策：Lamport（理论分析）+ Sorhus（简单实用）+ Dahl（长期后悔点）

辩论模式

Round 1：各自给出立场 Round 2：互相批评对方的方案 Round 3：考虑批评后给出最终建议

红队模式

Opus：提出方案 GPT：全力攻击方案，找弱点 Sonnet：防守和修补弱点

共识收敛

把所有人的观点展示给每个模型，问"考虑了这些视角后，你的新观点是什么？" 重复直到观点趋于稳定

会议归档

会议记录必须持久化保存，不要放 /tmp（重启会清空）。 ~/.openclaw/workspace/pr-review/ └── council-YYYY-MM-DD[-topic]/ ├── README.md # 会议概览（用模板） ├── council-opus-prompt.txt # Opus 的 prompt ├── council-opus-output.txt # Opus 的完整输出 ├── council-sonnet-prompt.txt ├── council-sonnet-output.txt ├── council-gpt-prompt.txt └── council-gpt-output.txt 归档步骤： ARCHIVE=~/.openclaw/workspace/pr-review/council-$(date +%Y-%m-%d)-topic mkdir -p "$ARCHIVE" cp /tmp/council-*.txt "$ARCHIVE/" # 然后写 README.md（模板见 references/session-readme-template.md） → README 模板见 references/session-readme-template.md

安全提醒

--force 会自动执行所有变更，务必在独立分支上使用 并行任务之间不能有文件冲突，否则会互相覆盖 每个 session 完成后先 tmux capture-pane 保存输出再关闭 人设是激活知识用的，不是角色扮演秀——保持专业分析为主