Skill: xiaoyaner0201/cursor-council (version 1.0.0)

--- name: cursor-council description: Multi-Cursor orchestration for parallel task execution and AI council deliberation. Use when needing to run multiple Cursor agents in parallel, coordinate complex multi-step coding tasks, get diverse perspectives from different AI models (Opus/Sonnet/GPT) on technical decisions, or synthesize multi-agent discussions into actionable recommendations. metadata: { "openclaw": { "emoji": "🎭", "author": "xiaoyaner", "version": "2.0.0", "requires": { "bins": ["tmux", "agent"], "skills": ["cursor-agent"] }, "install": [ { "id": "brew-tmux", "kind": "brew", "formula": "tmux", "bins": ["tmux"], "label": "Install tmux (brew)", }, { "id": "apt-tmux", "kind": "apt", "package": "tmux", "bins": ["tmux"], "label": "Install tmux (apt)", }, ], }, } --- # 🎭 Cursor Council — 我的编程前辈团 > Cursor CLI 需要真实 TTY，所以一切都通过 tmux 操作。 > 这个 skill 的本质：用 tmux 管理多个 Cursor 实例，让它们并行干活或者扮演大牛帮我分析问题。 ## 前置条件 ```bash which tmux && agent --version ``` 需要 `cursor-agent` skill 已配置好、`agent login` 已完成。 --- ## 两种模式 ### 模式一：并行施工 🏗️ **场景**：一个大任务可以拆成互不冲突的子任务，多个 Cursor 同时干。 **核心原则**： - 每个 Cursor 负责不同的文件/模块，**绝对不能有文件冲突** - 有依赖关系的任务必须等前置完成后再启动 - 最好每个 Cursor 在不同分支上工作 **操作流程**： ```bash # 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 | | 按分支 | 多个独立 feature | feat/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](references/parallel-execution.md) --- ### 模式二：前辈议会 🧙‍♂️ **场景**：遇到复杂技术决策，需要多角度分析。让不同模型扮演技术大牛，从各自的哲学视角给出建议。 **为什么有效**： 模型训练数据里包含大量技术大牛的文章、演讲、代码，让它"成为"某个人能激活这些深层知识。而且不同大牛代表不同流派，天然形成视角碰撞。 **角色分配逻辑**： | 角色 | 模型选择 | 思维特点 | 应该问什么 | |------|----------|----------|------------| | **架构师** | Opus（深度推理） | 看长远、找边界、想极端情况 | 架构设计、安全隐患、5年后会不会后悔 | | **工程师** | Sonnet（快速实用） | 讲效率、抓重点、先跑起来 | 实现成本、快速方案、技术债平衡 | | **批判者** | GPT（不同视角） | 挑毛病、给替代方案、打破惯性 | 有没有更好的路、假设是否成立 | **操作流程**： ```bash # 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/persona-engineering.md) → 议会流程详解见 [references/council-deliberation.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](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 ``` 归档步骤： ```bash 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](references/session-readme-template.md) --- ## 安全提醒 - `--force` 会自动执行所有变更，**务必在独立分支上使用** - 并行任务之间**不能有文件冲突**，否则会互相覆盖 - 每个 session 完成后先 `tmux capture-pane` 保存输出再关闭 - 人设是激活知识用的，不是角色扮演秀——保持专业分析为主

path: references/council-deliberation.md
content: # Council Deliberation Guide

Use multiple AI models as a "board of advisors" for technical decisions.

## When to Use Council Mode

- **Architecture decisions** - System design with long-term implications
- **Technology selection** - Choosing frameworks, databases, patterns
- **Risk assessment** - Security review, failure mode analysis
- **Complex tradeoffs** - No clear "right answer"
- **Breaking deadlocks** - When you're stuck between options

## Model Role Assignments

### The Architect (Opus)
```
Prompt prefix: "As a senior software architect with 20 years of experience, 
focusing on long-term maintainability, scalability, and edge cases..."
```
**Strengths**: Deep analysis, sees implications others miss
**Ask about**: Architecture patterns, security concerns, 5-year outlook

### The Pragmatist (Sonnet)
```
Prompt prefix: "As a practical senior engineer focused on shipping quality 
software efficiently, balancing ideal solutions with real-world constraints..."
```
**Strengths**: Time-to-market, pragmatic tradeoffs, MVP thinking
**Ask about**: Implementation effort, quick wins, technical debt balance

### The Challenger (GPT-5 / External Model)
```
Prompt prefix: "As an engineer from a different background, challenge 
assumptions and propose alternative approaches that might be overlooked..."
```
**Strengths**: Different training data, breaks groupthink
**Ask about**: Alternative patterns, industry practices, unconventional solutions

### The Specialist (Qwen / Domain-Specific)
```
Prompt prefix: "As an expert in [Chinese market / specific domain], 
considering local ecosystem, compliance, and cultural factors..."
```
**Strengths**: Domain expertise, local knowledge
**Ask about**: Regional requirements, specialized tooling

## Deliberation Workflow

### Phase 1: Frame the Question
```markdown
## Topic: [Decision Title]

### Background
[2-3 sentences of context]

### Options Under Consideration
1. Option A: [description]
2. Option B: [description]
3. Option C: [description]

### Evaluation Criteria
- Performance
- Maintainability
- Cost
- Time to implement
- Team familiarity

### Constraints
- [Budget, timeline, technical constraints]
```

### Phase 2: Parallel Consultation
Launch all models simultaneously with tailored prompts:

```bash
# Session setup
for role in opus sonnet gpt; do
  tmux new-session -d -s council-$role
done

# Opus query
tmux send-keys -t council-opus "agent --model claude-opus-4 -p '
You are a senior architect. Analyze this decision:

[Paste framed question]

Provide:
1. Your recommended option and detailed rationale
2. Long-term implications of each option
3. Edge cases and failure modes to consider
4. What would change your recommendation
' --force" Enter

# Sonnet query  
tmux send-keys -t council-sonnet "agent --model claude-sonnet-4 -p '
You are a pragmatic engineer. Evaluate this decision:

[Paste framed question]

Provide:
1. Your recommended option with implementation estimate
2. Quickest path to production-ready
3. Technical debt implications
4. What would you prototype first
' --force" Enter

# GPT query
tmux send-keys -t council-gpt "agent --model gpt-5 -p '
Challenge conventional thinking on this decision:

[Paste framed question]

Provide:
1. An alternative approach not listed
2. Assumptions that might be wrong
3. How other companies solve this differently
4. Contrarian perspective on the popular choice
' --force" Enter
```

### Phase 3: Collect & Synthesize

After all models respond (~2-5 minutes):

```bash
# Capture all outputs
for role in opus sonnet gpt; do
  echo "=== $role ===" >> council-output.md
  tmux capture-pane -t council-$role -p -S -500 >> council-output.md
done
```

### Phase 4: Synthesis Template

```markdown
## Council Summary: [Topic]

### Individual Recommendations

| Model | Recommendation | Confidence | Key Concern |
|-------|---------------|------------|-------------|
| Opus | Option B | High | Long-term scaling |
| Sonnet | Option A | Medium | Implementation speed |
| GPT | Option D (new) | Medium | Industry trend |

### Consensus Points
All models agree that:
- [Point 1]
- [Point 2]

### Key Divergences

**On [Topic 1]:**
- Opus: [view]
- Sonnet: [view]  
- GPT: [view]
- Analysis: [why they differ]

### Risks Identified
| Risk | Flagged By | Severity | Mitigation |
|------|-----------|----------|------------|
| [Risk 1] | Opus | High | [suggestion] |
| [Risk 2] | GPT | Medium | [suggestion] |

### Synthesized Recommendation

**Recommended: Option [X]**

Rationale:
1. [Key point from Opus]
2. [Practical consideration from Sonnet]
3. [Incorporated insight from GPT]

**With modifications:**
- [Adjustment based on council feedback]

### Open Questions for Human Decision
1. [Trade-off that requires human judgment]
2. [Business context only human knows]
```

## Advanced Patterns

### Debate Mode
Have models respond to each other:
```
Round 1: Each model gives initial position
Round 2: Each model critiques another's position
Round 3: Each model gives final recommendation considering critiques
```

### Red Team Mode
Assign one model to attack proposed solution:
```
Opus: Propose solution
GPT: Attack the solution, find weaknesses
Sonnet: Defend and patch weaknesses
```

### Consensus Building
Keep iterating until convergence:
```
Round N: Present all positions to each model
         Ask: "Given these perspectives, what's your updated view?"
Repeat until positions stabilize
```

## Cost Considerations

| Model | Relative Cost | When to Use |
|-------|--------------|-------------|
| Opus | $$$ | High-stakes decisions |
| Sonnet | $ | Quick consultations |
| GPT-5 | $$ | Diversity of perspective |

For budget-conscious councils:
- Use Sonnet for initial exploration
- Bring in Opus only for final deep-dive
- Use GPT sparingly for fresh perspectives


path: references/parallel-execution.md
content: # Parallel Execution Guide

Detailed guide for running multiple Cursor instances on independent tasks.

## Session Management

### Initialize Multiple Sessions
```bash
# Clean start
for i in 1 2 3; do
  tmux kill-session -t cursor-$i 2>/dev/null || true
  tmux new-session -d -s cursor-$i
  tmux send-keys -t cursor-$i "cd $PROJECT_DIR" Enter
done
```

### Session Naming Conventions
- `cursor-1`, `cursor-2`, `cursor-3` - Generic parallel workers
- `cursor-frontend`, `cursor-backend` - Module-based naming
- `cursor-feat-123`, `cursor-bug-456` - Task-based naming

## Task Decomposition Strategies

### By Module (No Conflicts)
```
cursor-1: src/frontend/**
cursor-2: src/backend/**
cursor-3: src/shared/** (wait for 1 & 2)
```

### By Feature Branch
```
cursor-1: git checkout feat/auth && agent -p '...'
cursor-2: git checkout feat/dashboard && agent -p '...'
```

### By File Type
```
cursor-1: *.test.ts (tests)
cursor-2: *.ts (implementation)
cursor-3: *.md (documentation)
```

## Monitoring Strategies

### Round-Robin Polling
```bash
while true; do
  for session in cursor-1 cursor-2 cursor-3; do
    echo "=== $session ==="
    tmux capture-pane -t $session -p | tail -10
  done
  sleep 30
done
```

### Completion Detection
Look for these patterns in output:
- `Agent completed` - Task finished
- `waiting for approval` - Needs intervention
- Percentage indicators (e.g., `78.9%`)
- Error messages

### Progress Dashboard
```bash
# One-liner status check
for s in cursor-{1,2,3}; do 
  echo -n "$s: "
  tmux capture-pane -t $s -p 2>/dev/null | grep -oE '[0-9]+\.[0-9]+%' | tail -1 || echo "running"
done
```

## Error Handling

### Common Issues

| Issue | Detection | Resolution |
|-------|-----------|------------|
| Session hung | No output for 5+ min | `tmux send-keys -t $session C-c` |
| Approval needed | "Waiting for approval" | `tmux send-keys -t $session y` |
| Git conflict | "CONFLICT" in output | Pause, resolve manually |
| OOM | Process killed | Reduce parallel count |

### Recovery Workflow
```bash
# 1. Check what went wrong
tmux capture-pane -t cursor-1 -p -S -200 > cursor-1-log.txt

# 2. Kill if stuck
tmux send-keys -t cursor-1 C-c
sleep 2

# 3. Restart with adjusted task
tmux send-keys -t cursor-1 "agent -p 'Revised task...' --force" Enter
```

## Resource Limits

### Recommended Parallelism
| Machine | Max Cursors | Notes |
|---------|-------------|-------|
| 8GB RAM | 2 | Conservative |
| 16GB RAM | 3-4 | Standard |
| 32GB+ RAM | 5-6 | Heavy workloads |

### API Rate Limits
- Claude Max: Check subscription tier
- Consider staggered starts (30s delay between launches)

## Best Practices

1. **Always use branches** - Each Cursor on its own branch if touching same repo
2. **Clear task boundaries** - Explicit file lists prevent conflicts
3. **Staged dependencies** - Don't launch dependent tasks until prerequisites complete
4. **Log everything** - Capture pane output before killing sessions
5. **Graceful shutdown** - Let tasks complete rather than killing mid-work


path: references/persona-engineering.md
content: # Persona Engineering for AI Council

让模型扮演技术领域大牛，充分发挥不同模型的特点。

## 核心理念

### 为什么要用大牛人设？

1. **激活模型知识**：模型训练数据中包含大量大牛的文章、演讲、代码风格，扮演他们能激活这些知识
2. **风格一致性**：大牛有明确的技术哲学和表达风格，让输出更有个性和深度
3. **视角差异化**：不同大牛代表不同的技术流派，天然形成多角度分析

### 选择人设的原则

| 原则 | 说明 | 示例 |
|------|------|------|
| **模型特点匹配** | 深度推理模型配深度思考者，快速模型配实用主义者 | Opus → 理论家，Sonnet → 实干家 |
| **领域相关性** | 人设应该和待解决问题的领域相关 | Node.js 问题 → 选 Node 生态大牛 |
| **风格互补性** | 多个人设应该代表不同流派，形成张力 | 学院派 vs 实用派 vs 批判派 |

## 人设库

### 并发 / 分布式系统

| 大牛 | 代表作 | 哲学 | 适合模型 | 适合问题 |
|------|--------|------|----------|----------|
| **Joe Armstrong** | Erlang, OTP | "Let it crash", 进程隔离, 消息传递 | Opus (深度) | 并发安全、容错设计、消息队列 |
| **Leslie Lamport** | Paxos, LaTeX, TLA+ | 形式化验证, 分布式共识 | Opus (深度) | 分布式一致性、状态机、协议设计 |
| **Martin Kleppmann** | DDIA, Automerge | 数据密集型应用, CRDT | Opus/Sonnet | 数据一致性、复制、分区 |

### Node.js / JavaScript 生态

| 大牛 | 代表作 | 哲学 | 适合模型 | 适合问题 |
|------|--------|------|----------|----------|
| **TJ Holowaychuk** | Express, Koa, Co | 极简主义, 一个函数搞定 | Sonnet (快速) | Node 最佳实践、异步模式、API 设计 |
| **Ryan Dahl** | Node.js, Deno | 反思与重构, 承认错误 | GPT (不同视角) | 架构反思、重新设计、根因分析 |
| **Sindre Sorhus** | 1000+ npm 包 | 小而美, 单一职责 | Sonnet (快速) | 工具库设计、代码简化 |

### 系统架构 / 软件工程

| 大牛 | 代表作 | 哲学 | 适合模型 | 适合问题 |
|------|--------|------|----------|----------|
| **Martin Fowler** | 重构, 企业架构模式 | 渐进式改进, 模式语言 | Opus (深度) | 重构策略、设计模式、技术债 |
| **Uncle Bob (Robert C. Martin)** | Clean Code, SOLID | 整洁代码, 原则优先 | Sonnet | 代码质量、测试、可维护性 |
| **Linus Torvalds** | Linux, Git | 直言不讳, 务实, 性能优先 | GPT (批判) | 代码审查、性能问题、API 设计批评 |

### 函数式 / 语言设计

| 大牛 | 代表作 | 哲学 | 适合模型 | 适合问题 |
|------|--------|------|----------|----------|
| **Rich Hickey** | Clojure, Datomic | 简单 vs 容易, 不可变性 | Opus (深度) | 状态管理、复杂性分析、数据建模 |
| **Simon Peyton Jones** | Haskell, GHC | 类型系统, 纯函数 | Opus (深度) | 类型设计、编译器、抽象建模 |

## Prompt 模板

### 基础结构

```markdown
## 你的身份

你是 [大牛名字]，[简短介绍和代表作]。

你的核心信仰：
- [哲学观点 1]
- [哲学观点 2]
- [哲学观点 3]

[可选：一段轶事或名言，增加真实感]

## 背景资料

[问题描述、代码、日志等共享上下文]

## 你的任务

用 [大牛名字] 的视角分析：

1. [针对性问题 1 - 利用该人设的专长]
2. [针对性问题 2]
3. [针对性问题 3]
4. [如果是你会怎么做]

## 输出格式

```markdown
## [大牛名字] 的分析

### [主题 1]
[分析内容]

### [主题 2]
[分析内容]

### 一句话总结
[符合该大牛风格的犀利点评]
```
```

### 风格指南

不同大牛有不同的表达风格：

| 大牛 | 风格特点 | 示例表达 |
|------|----------|----------|
| **Joe Armstrong** | 类比丰富, 用电话交换机举例 | "想象一下电话交换机，每个通话是独立进程..." |
| **TJ Holowaychuk** | 极度简洁, 直接给代码 | "这 20 行可以缩成 5 行：[代码]" |
| **Ryan Dahl** | 反思性, 承认局限 | "当初我设计 Node 时没考虑到这个，如果重来..." |
| **Linus Torvalds** | 直接, 有时刻薄 | "这代码是哪个白痴写的？" (可以软化) |
| **Rich Hickey** | 哲学性, 区分概念 | "这里混淆了 '简单' 和 '容易'..." |

## 组合示例

### 示例 1：并发问题审查

**场景**：消息队列阻塞问题

| 角色 | 模型 | 人设 | 关注点 |
|------|------|------|--------|
| 架构师 | Opus 4.6 | Joe Armstrong | 进程隔离、Let it crash、消息传递设计 |
| 工程师 | Sonnet 4.5 | TJ Holowaychuk | 代码简化、快速修复、Node 异步模式 |
| 批判者 | GPT 5.2 | Ryan Dahl | 根因反思、是否需要重新设计 |

### 示例 2：API 设计评审

**场景**：REST API 设计争议

| 角色 | 模型 | 人设 | 关注点 |
|------|------|------|--------|
| 架构师 | Opus 4.6 | Martin Fowler | 领域驱动、资源建模、演进策略 |
| 实用派 | Sonnet 4.5 | DHH | 约定优于配置、Rails 风格、简单实用 |
| 批判者 | GPT 5.2 | Linus Torvalds | 接口简洁性、性能、过度设计批评 |

### 示例 3：代码质量讨论

**场景**：技术债清理策略

| 角色 | 模型 | 人设 | 关注点 |
|------|------|------|--------|
| 架构师 | Opus 4.6 | Martin Fowler | 渐进式重构、模式识别 |
| 代码派 | Sonnet 4.5 | Uncle Bob | Clean Code 原则、测试覆盖 |
| 哲学家 | GPT 5.2 | Rich Hickey | 复杂性根源、简单 vs 容易 |

## 注意事项

1. **不要过度模仿**：人设是激活知识，不是模仿秀，保持专业分析为主
2. **尊重原作者**：不要让人设说出不尊重的话（除非是 Linus 风格的技术批评）
3. **适时跳出角色**：如果人设视角有局限，可以补充 "跳出 [人设] 的视角..."
4. **验证建议**：大牛的观点也可能过时或偏颇，最终决策需要综合判断


path: references/session-readme-template.md
content: # Session README Template

Council 会议记录的 README 模板。

## 基础模板

```markdown
# AI Council Session - YYYY-MM-DD

## 审查目标
- [PR/Issue/决策 描述]
- [相关链接]

## Council 成员

| 角色 | 模型 | 人设 | 关注点 |
|------|------|------|--------|
| 架构师 | opus-4.6 | **[大牛名字]** | [专长领域] |
| 工程师 | sonnet-4.5 | **[大牛名字]** | [专长领域] |
| 批判者 | gpt-5.2 | **[大牛名字]** | [专长领域] |

## 文件清单

| 文件 | 内容 | 行数 |
|------|------|------|
| `council-opus-prompt.txt` | Opus 任务 prompt | XX |
| `council-opus-output.txt` | Opus 完整分析 | XX |
| `council-sonnet-prompt.txt` | Sonnet 任务 prompt | XX |
| `council-sonnet-output.txt` | Sonnet 完整分析 | XX |
| `council-gpt-prompt.txt` | GPT 任务 prompt | XX |
| `council-gpt-output.txt` | GPT 完整分析 | XX |

## 共识矩阵

| 维度 | Opus | Sonnet | GPT |
|------|------|--------|-----|
| [维度1] | [观点] | [观点] | [观点] |
| [维度2] | [观点] | [观点] | [观点] |

## 结论

### 一致同意
- [共识点1]
- [共识点2]

### 存在分歧
- [分歧点及各方观点]

### 最终建议
[综合建议]

## 后续行动

- [ ] [Action 1]
- [ ] [Action 2]

## 相关链接

- [GitHub PR](https://...)
- [GitHub Comment](https://...#issuecomment-...)
```

## PR 审查专用模板

```markdown
# AI Council Session - YYYY-MM-DD - PR Review

## 审查目标

| PR | 标题 | 作者 |
|----|------|------|
| #XXXX | [标题] | @author |
| #YYYY | [标题] | @author |

## Council 成员

| 角色 | 模型 | 人设 | 关注点 |
|------|------|------|--------|
| 架构师 | opus-4.6 | **Joe Armstrong** | 并发安全、进程隔离、Let it crash |
| 工程师 | sonnet-4.5 | **TJ Holowaychuk** | 代码简洁、Node 最佳实践 |
| 批判者 | gpt-5.2 | **Ryan Dahl** | 根因反思、设计问题 |

## 审查结论

| PR | Opus | Sonnet | GPT | 最终建议 |
|----|------|--------|-----|----------|
| #XXXX | ⚠️ | ❌ | ⚠️ | REQUEST CHANGES |
| #YYYY | ✅ | ✅ | ⚠️ | APPROVE with comments |

## 关键发现

### PR #XXXX
- **核心问题**：[问题描述]
- **改进建议**：[建议]

### PR #YYYY  
- **核心问题**：[问题描述]
- **改进建议**：[建议]

## GitHub 评论已提交

- https://github.com/.../pull/XXXX#issuecomment-...
- https://github.com/.../pull/YYYY#issuecomment-...
```

## 快速生成脚本

```bash
#!/bin/bash
# generate-council-readme.sh

DATE=$(date +%Y-%m-%d)
ARCHIVE_DIR=${1:-~/.openclaw/workspace/pr-review/council-$DATE}

cat > "$ARCHIVE_DIR/README.md" << EOF
# AI Council Session - $DATE

## 审查目标
- TODO: 填写审查目标

## Council 成员

| 角色 | 模型 | 人设 | 关注点 |
|------|------|------|--------|
| 架构师 | opus-4.6 | **TODO** | TODO |
| 工程师 | sonnet-4.5 | **TODO** | TODO |
| 批判者 | gpt-5.2 | **TODO** | TODO |

## 文件清单
$(for f in "$ARCHIVE_DIR"/council-*.txt; do
  [ -f "$f" ] && echo "- \`$(basename $f)\` ($(wc -l < "$f") lines)"
done)

## 结论
TODO: 填写结论

## 相关链接
- TODO: 添加链接
EOF

echo "Generated: $ARCHIVE_DIR/README.md"
```


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: suspicious | SkillSpector: clean (LOW)