design-council-orchestration

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Design Council Orchestration

Design Council 编排方案

Skill by ara.so — Design Skills collection.
ara.so 开发的Skill — 属于Design Skills合集。

Overview

概述

Design Council is a Claude Code plugin that spawns 11+ independent Claude agents in parallel, each with a specialized role (principal-engineer, security-engineer, product-manager, etc.), to debate cross-cutting technical decisions. The invoking Claude acts as CEO, orchestrating the debate and writing binding decisions.
Unlike single-context reviews, each seat runs in its own context with no shared history. Disagreement is structural, not simulated. Seats argue via direct peer DMs (
SendMessage
), not sequential turns through the CEO.
Key difference from other patterns: This isn't prompt engineering within one context — it's multi-agent orchestration with genuine parallelism and independent reasoning.
Design Council是一款Claude Code插件,可并行生成11个以上独立的Claude Agent,每个Agent都具备特定专业角色(首席工程师、安全工程师、产品经理等),共同讨论跨领域的技术决策。发起调用的Claude将担任CEO,负责编排讨论流程并撰写具有约束力的决策结果。
与单上下文评审不同,每个角色Agent都运行在独立上下文环境中,无共享历史记录。意见分歧是真实存在的,而非模拟生成。各角色Agent通过直接点对点私信(
SendMessage
)进行争论,而非通过CEO按顺序传递消息。
与其他模式的核心区别:这并非单上下文内的提示词工程,而是具备真正并行能力和独立推理能力的多Agent编排方案。

Installation

安装

bash
undefined
bash
undefined

Add the plugin marketplace

添加插件市场

/plugin marketplace add sjsyrek/claude-plugins
/plugin marketplace add sjsyrek/claude-plugins

Install design-council

安装design-council

/plugin install design-council@sjsyrek

To pin a specific version:

```bash
git clone https://github.com/sjsyrek/design-council.git
cd design-council
git checkout v0.2.0
/plugin marketplace add .
/plugin install design-council@sjsyrek
/plugin install design-council@sjsyrek

如需固定特定版本:

```bash
git clone https://github.com/sjsyrek/design-council.git
cd design-council
git checkout v0.2.0
/plugin marketplace add .
/plugin install design-council@sjsyrek

When to Use

使用场景

Invoke when BOTH conditions hold:
  1. Decision crosses ≥2 specialist domains (e.g., security + performance + UX)
  2. Output must survive handoff (decision log, tracker items, execution plan)
Natural trigger phrases:
  • "Convene the council to review this API design"
  • "Get the design council together for this architecture"
  • "Council debate: pagination strategy for this endpoint"
  • "Run a design review on the caching layer"
Do NOT invoke for:
  • Simple bug fixes (single domain)
  • Library/tool selection (→ use direct research)
  • Pure exploration without deliverable
  • Questions answerable by one specialist
Token economics: Expect 10–20× the cost of single-context review. The council earns its cost on decisions that would otherwise ship with blind spots.
需同时满足以下两个条件时调用
  1. 决策涉及**≥2个专业领域**(例如:安全 + 性能 + 用户体验)
  2. 输出结果需要可移交落地(决策日志、跟踪项、执行计划)
触发短语示例
  • "召集委员会评审这个API设计"
  • "让设计委员会一起讨论这个架构"
  • "委员会讨论:该端点的分页策略"
  • "对缓存层进行设计评审"
请勿在以下场景调用
  • 简单bug修复(单领域)
  • 库/工具选型(→ 直接使用调研模式)
  • 无交付物的纯探索性讨论
  • 单一专家可解答的问题
Token成本考量:预计成本是单上下文评审的10–20倍。当决策存在潜在盲区时,委员会的成本投入是值得的。

Execution Phases

执行阶段

Phase 0: Plan Card (Pre-Flight)

阶段0:计划卡片(预启动)

Before any agents spawn, the CEO shows a confirmation card:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DESIGN COUNCIL PLAN

Mode: DEBATE
Roster (8 seats):
  • principal-engineer     [opus]
  • platform-engineer      [sonnet]
  • security-engineer      [sonnet]
  • test-engineer          [sonnet]
  • performance-engineer   [sonnet]
  • product-manager        [opus]
  • technical-writer       [opus]
  • qa-engineer            [sonnet]

Budget:
  ~180k tokens (cached brief saves ~9k × 8)
  ~4–7 min wall-clock (3 debate rounds)

Opening prompt:
  "Should the /search endpoint paginate with
   cursor tokens or offset/limit?"

Reply: go | swap X for Y | drop X | add X | abort
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
You control the roster here:
bash
undefined
在生成任何Agent之前,CEO会展示确认卡片:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DESIGN COUNCIL 计划

模式:辩论
成员(8个角色):
  • principal-engineer     [opus]
  • platform-engineer      [sonnet]
  • security-engineer      [sonnet]
  • test-engineer          [sonnet]
  • performance-engineer   [sonnet]
  • product-manager        [opus]
  • technical-writer       [opus]
  • qa-engineer            [sonnet]

预算:
  ~180k Token(缓存简报可节省 ~9k × 8)
  ~4–7分钟时长(3轮辩论)

开场问题:
  "/search端点应使用游标令牌还是偏移量/限制进行分页?"

回复选项:go | swap X for Y | drop X | add X | abort
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
你可在此控制成员构成
bash
undefined

Accept as-is

按当前配置执行

go
go

Swap models

替换模型

swap principal-engineer for sonnet
swap principal-engineer for sonnet

Add a seat

添加角色

add domain-expert
add domain-expert

Remove a seat

删除角色

drop ui-ux-designer
drop ui-ux-designer

Cancel

取消执行

abort
undefined
abort
undefined

Phase 1: Brief Assembly

阶段1:简报汇编

The CEO gathers constraints once into
~/.claude/councils/<slug>/brief.md
:
  • CLAUDE.md
    constraints
  • Referenced specs / ADRs
  • Project memory (including beads if detected)
  • Skill self-audit: greps auto-memory for entries about design-council itself — memory wins over skill text (real failures > documentation)
Every seat's spawn prompt points to this path → prompt cache hits across all spawns (~7–12k tokens saved per 8-seat council).
CEO会一次性收集约束条件并保存至
~/.claude/councils/<slug>/brief.md
  • CLAUDE.md
    约束条件
  • 参考的规格文档/架构决策记录(ADR)
  • 项目记忆(包括检测到的beads)
  • Skill自审计:自动检索与design-council相关的记忆项 — 真实故障记录优先于技能文档(实际问题 > 文档描述)
每个角色Agent的生成提示词都会指向该路径 → 所有生成请求共享提示词缓存(每8个角色的委员会可节省约7–12k Token)。

Phase 2: Parallel Spawn

阶段2:并行生成

CEO spawns all seats in one multi-tool-call message:
typescript
// Conceptual — the CEO does this automatically
await Promise.all([
  Agent({
    name: "principal-engineer",
    run_in_background: true,
    team_name: "design-council-2026-05-17-pagination",
    model: "claude-opus-4",
    prompt: `You are the principal-engineer seat.
    
Brief: file://~/.claude/councils/pagination/brief.md

Four delivery rules:
1. Handshake: DM "READY: principal-engineer" within 10s
2. Cross-talk: SendMessage only (never Execute)
3. Final verdict: via SendMessage to CEO
4. Idle summary: <100 chars

Opening question:
Should /search paginate cursor or offset?`
  }),
  Agent({ name: "security-engineer", ... }),
  Agent({ name: "platform-engineer", ... }),
  // ... 5 more
]);
CEO通过单条多工具调用消息生成所有角色Agent:
typescript
// 概念示例 — CEO会自动执行此操作
await Promise.all([
  Agent({
    name: "principal-engineer",
    run_in_background: true,
    team_name: "design-council-2026-05-17-pagination",
    model: "claude-opus-4",
    prompt: `You are the principal-engineer seat.
    
Brief: file://~/.claude/councils/pagination/brief.md

Four delivery rules:
1. Handshake: DM "READY: principal-engineer" within 10s
2. Cross-talk: SendMessage only (never Execute)
3. Final verdict: via SendMessage to CEO
4. Idle summary: <100 chars

Opening question:
Should /search paginate cursor or offset?`
  }),
  Agent({ name: "security-engineer", ... }),
  Agent({ name: "platform-engineer", ... }),
  // ... 另外5个角色
]);

Phase 2.5: Handshake Verify

阶段2.5:握手验证

CEO counts incoming
READY: <seat-name>
DMs, checks for empty
tmuxPaneId
s (silent spawn failures), remediates, and emits:
HANDSHAKE: 8/8 ok | verdict=PROCEED
If any seat fails to spawn:
  • CEO attempts one re-spawn
  • On second failure: drops seat, logs it, proceeds with reduced roster
CEO统计收到的
READY: <seat-name>
私信,检查是否存在空的
tmuxPaneId
(静默生成失败),进行修复后输出:
HANDSHAKE: 8/8 ok | verdict=PROCEED
若任何角色Agent生成失败:
  • CEO尝试重新生成一次
  • 再次失败则:移除该角色,记录日志,使用缩减后的成员继续执行

Phase 3: Opening Verdicts

阶段3:初始结论

Each seat posts its opening verdict via
SendMessage
to CEO:
From: security-engineer
To: CEO

CONCERNS

Offset pagination leaks record counts (DoS vector).
Cursor tokens must be HMAC-signed with rotation.
Need rate-limit strategy regardless of choice.
Verdicts:
  • APPROVE
    — no blocking concerns
  • CONCERNS
    — issues that need resolution
  • BLOCK
    — showstopper (requires CEO arbitration or escalation)
每个角色Agent通过
SendMessage
向CEO发送初始结论:
发件人: security-engineer
收件人: CEO

关注问题

偏移量分页会泄露记录总数(拒绝服务攻击向量)。
游标令牌必须使用HMAC签名并定期轮换。
无论选择哪种方案,都需要限流策略。
结论类型:
  • APPROVE
    — 无阻塞性问题
  • CONCERNS
    — 存在需要解决的问题
  • BLOCK
    — 致命问题(需CEO仲裁或升级处理)

Phase 4: Cross-Talk (Peer DMs)

阶段4:交叉讨论(点对点私信)

Review mode: skips cross-talk by default (seats → CEO only).
Debate mode: CEO routes disagreements to direct seat-to-seat DMs:
typescript
// CEO orchestration (automatic)
if (security.verdict === "CONCERNS" && platform.verdict === "APPROVE") {
  SendMessage({
    from: "CEO",
    to: "security-engineer",
    text: "DM platform-engineer: they approved offset. Argue your HMAC requirement."
  });
  
  SendMessage({
    from: "CEO", 
    to: "platform-engineer",
    text: "security-engineer has concerns about offset. Respond to their HMAC point."
  });
}
Seats then argue directly:
From: security-engineer
To: platform-engineer

Your offset approval ignores enumeration risk.
Without signed cursors, scrapers can walk the
entire dataset. Do you have a mitigation?
From: platform-engineer  
To: security-engineer

Rate limiting is orthogonal to pagination style.
Offset + jittered delays caps enumeration to
same ROC as cursor. Offset is simpler to cache.
Hard cap: 3 rounds. CEO forces convergence or arbitration.
评审模式:默认跳过交叉讨论(仅角色Agent → CEO传递消息)。
辩论模式:CEO将分歧路由至角色Agent之间的直接私信:
typescript
// CEO自动编排
if (security.verdict === "CONCERNS" && platform.verdict === "APPROVE") {
  SendMessage({
    from: "CEO",
    to: "security-engineer",
    text: "私信platform-engineer:他们批准了偏移量方案。请阐述你对HMAC要求的理由。"
  });
  
  SendMessage({
    from: "CEO", 
    to: "platform-engineer",
    text: "security-engineer对偏移量方案存在顾虑。请回应他们关于HMAC的观点。"
  });
}
角色Agent随后直接争论:
发件人: security-engineer
收件人: platform-engineer

你对偏移量的批准忽略了枚举风险。
如果没有签名游标,爬虫可以遍历整个数据集。你有缓解方案吗?
发件人: platform-engineer  
收件人: security-engineer

限流与分页方式无关。
偏移量+随机延迟可以将枚举速率限制到与游标方案相同的水平。偏移量方案更易于缓存。
硬限制:3轮讨论。CEO会强制达成共识或进行仲裁。

Phase 5: Arbitration + Decision Log

阶段5:仲裁 + 决策日志

For unresolved disagreements, CEO writes binding decisions (3–5 sentences engaging both sides):
markdown
undefined
对于未解决的分歧,CEO会撰写具有约束力的决策(3–5句话,兼顾双方观点):
markdown
undefined

Decision: Cursor pagination with signed tokens

决策:采用带签名令牌的游标分页

security-engineer's enumeration concern is valid and not fully mitigated by rate limiting (jitter still allows sequential walks). platform-engineer's caching argument applies to both schemes via
cache_token
param. Adopt cursor pagination with HMAC-SHA256 signed tokens (rotate key daily).
Deferred: Rate limit strategy (filed as BEAD-127).

**Escalations** (to user):
- Strategic tradeoffs (e.g., "ship fast vs. correct")
- Budget / resourcing
- Legal / compliance
- Cross-team dependencies

CEO emits draft log to chat:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ DECISION LOG (DRAFT)
Reply: save | amend "<changes>" | discard ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
undefined
security-engineer提出的枚举风险是合理的,限流策略无法完全缓解该问题(随机延迟仍允许顺序遍历)。platform-engineer提到的缓存优势可通过
cache_token
参数应用于两种方案。采用带HMAC-SHA256签名令牌的游标分页(密钥每日轮换)
延期事项:限流策略(已记录为BEAD-127)。

**需升级至用户处理的场景**:
- 战略权衡(例如:"快速交付 vs. 正确交付")
- 预算/资源分配
- 法律/合规问题
- 跨团队依赖

CEO会将草案日志发送至聊天:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 决策日志(草案)
回复选项:save | amend "<修改内容>" | discard ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
undefined

Phase 6: Persist + Teardown

阶段6:持久化 + 清理

On
save
:
bash
undefined
当回复
save
时:
bash
undefined

Decision log

决策日志

~/.claude/councils/2026-05-17-pagination/log.md
~/.claude/councils/2026-05-17-pagination/log.md

Structure

结构


slug: pagination date: 2026-05-17 mode: DEBATE roster: [principal-engineer, security-engineer, ...] primary-tracker-id: BEAD-126 # if beads detected linked-tracker-ids: [BEAD-127] status: resolved


slug: pagination date: 2026-05-17 mode: DEBATE roster: [principal-engineer, security-engineer, ...] primary-tracker-id: BEAD-126 # 若检测到beads linked-tracker-ids: [BEAD-127] status: resolved

Opening Prompt

开场问题

Should /search paginate cursor or offset?
/search端点应使用游标还是偏移量进行分页?

Resolved Disagreements

已解决的分歧

...
...

Arbitration Decisions

仲裁决策

...
...

Execution Plan

执行计划

File ownership:
  • src/api/search.ts → platform-engineer context
  • src/auth/tokens.ts → security-engineer context
  • tests/api/search.test.ts → test-engineer context

CEO then:
- Broadcasts shutdown via `SendMessage`
- Calls `TeamDelete` (removes shared task list)
- Cleans up Brief artifact
文件负责人:
  • src/api/search.ts → platform-engineer上下文
  • src/auth/tokens.ts → security-engineer上下文
  • tests/api/search.test.ts → test-engineer上下文

随后CEO会:
- 通过`SendMessage`广播关闭指令
- 调用`TeamDelete`(移除共享任务列表)
- 清理简报文件

Roster Configuration

成员配置

Default 11 Seats (Dynamic Sizing)

默认11个角色(动态调整)

yaml
core:
  - principal-engineer    # Architecture synthesis (opus)
  - platform-engineer     # Infra / deployment (sonnet)
  - integration-engineer  # API contracts / compat (sonnet)
  - test-engineer         # Test strategy (sonnet)
  - qa-engineer           # Quality gates (sonnet)
  - security-engineer     # Threat model (sonnet)
  - performance-engineer  # Latency / throughput (sonnet)
  - product-manager       # User impact / scope (opus)
  - ui-ux-designer        # Interface / flows (sonnet)
  - accessibility-specialist  # A11y / WCAG (sonnet)
  - technical-writer      # Docs / clarity (opus)

opt-ins:
  - devops-engineer       # CI/CD / observability
  - finops-engineer       # Cloud cost / budget
  - legal-compliance      # GDPR / SOC2 / licensing
  - domain-expert         # Named SME (you provide context)
  - historian             # Past decisions / ADRs
Automatic pruning (Phase 0):
  • No UI → drop
    ui-ux-designer
    ,
    accessibility-specialist
  • Internal tool → drop
    security-engineer
    ,
    platform-engineer
  • Pure backend → drop
    ui-ux-designer
Adding seats in plan card:
bash
undefined
yaml
core:
  - principal-engineer    # 架构整合(opus)
  - platform-engineer     # 基础设施/部署(sonnet)
  - integration-engineer  # API契约/兼容性(sonnet)
  - test-engineer         # 测试策略(sonnet)
  - qa-engineer           # 质量门控(sonnet)
  - security-engineer     # 威胁建模(sonnet)
  - performance-engineer  # 延迟/吞吐量(sonnet)
  - product-manager       # 用户影响/范围(opus)
  - ui-ux-designer        # 界面/流程(sonnet)
  - accessibility-specialist  # 无障碍/WCAG(sonnet)
  - technical-writer      # 文档/清晰度(opus)

opt-ins:
  - devops-engineer       # CI/CD/可观测性
  - finops-engineer       # 云成本/预算
  - legal-compliance      # GDPR/SOC2/许可证
  - domain-expert         # 指定领域专家(需提供上下文)
  - historian             # 过往决策/ADR
自动裁剪(阶段0)
  • 无UI → 移除
    ui-ux-designer
    accessibility-specialist
  • 内部工具 → 移除
    security-engineer
    platform-engineer
  • 纯后端 → 移除
    ui-ux-designer
在计划卡片中添加角色
bash
undefined

Add domain expert

添加领域专家

add domain-expert
add domain-expert

CEO will prompt you for context:

CEO会提示你提供上下文:

"What domain? Provide 2–3 sentence brief."

"领域是什么?提供2–3句话的简介。"

undefined
undefined

Model Assignment

模型分配

Default strategy:
  • Opus: synthesis-heavy (
    principal-engineer
    ,
    product-manager
    ,
    technical-writer
    ,
    historian
    )
  • Sonnet: analytical (
    test-engineer
    ,
    performance-engineer
    ,
    security-engineer
    )
Override triggers:
  • "High quality bar" → all Opus
  • "Ship to production" → all Opus
  • Plan card manual swap:
    swap security-engineer for opus
默认策略
  • Opus:偏重整合类角色(
    principal-engineer
    product-manager
    technical-writer
    historian
  • Sonnet:偏重分析类角色(
    test-engineer
    performance-engineer
    security-engineer
覆盖触发条件
  • "高质量标准" → 全部使用Opus
  • "上线生产环境" → 全部使用Opus
  • 计划卡片手动替换:
    swap security-engineer for opus

Beads Integration (Tracker System)

Beads集成(跟踪系统)

When beads is detected (
.beads/
exists OR
bd
on
$PATH
):
Phase 1 (Brief):
bash
undefined
当检测到beads(存在
.beads/
目录或
$PATH
中有
bd
命令)时:
阶段1(简报)
bash
undefined

CEO runs automatically

CEO自动执行

bd memories # → brief.md bd ready # → brief.md (active context) bd show <id> # → brief.md (if user referenced a bead)

**Phase 4 (Defer)**:
```bash
bd memories # → 写入brief.md bd ready # → 写入brief.md(活跃上下文) bd show <id> # → 写入brief.md(若用户引用了bead)

**阶段4(延期)**:
```bash

CEO translates DEFER decisions to tracker items

CEO将延期决策转换为跟踪项

bd create
--title "Implement rate limiting for /search"
--type task
--parent BEAD-126
--context "From design-council-2026-05-17-pagination: security-engineer raised enumeration concern"

**Phase 6 (Teardown)**:
```bash
bd create \ --title "为/search端点实现限流" \ --type task \ --parent BEAD-126 \ --context "来自design-council-2026-05-17-pagination:security-engineer提出枚举风险顾虑"

**阶段6(清理)**:
```bash

Close primary bead under debate

关闭讨论中的主bead

bd close BEAD-126 --force # if dependency inversion flagged
bd close BEAD-126 --force # 若标记为依赖反转

Log tracker IDs in frontmatter

在前置元数据中记录跟踪ID

primary-tracker-id: BEAD-126 linked-tracker-ids: [BEAD-127, BEAD-128]

**Without beads**: deferred items remain prose in decision log. Protocol is strictly additive.
primary-tracker-id: BEAD-126 linked-tracker-ids: [BEAD-127, BEAD-128]

**无beads时**:延期事项仅以文字形式保留在决策日志中。协议严格为增量式。

Advanced Patterns

高级模式

Stop Early

提前终止

bash
undefined
bash
undefined

At any phase

任何阶段均可执行

stop the council

CEO broadcasts shutdown, saves partial log with `status: halted`, cleans up.
stop the council

CEO会广播关闭指令,保存状态为`halted`的部分日志,然后清理资源。

Review Mode (No Cross-Talk)

评审模式(无交叉讨论)

bash
undefined
bash
undefined

User invocation

用户调用

"Council review of PR #47 (no debate)"

CEO skips Phase 4 cross-talk. Seats → CEO verdict only. Faster, cheaper, good for conformance checks.
"委员会评审PR #47(无需辩论)"

CEO会跳过阶段4的交叉讨论。仅角色Agent向CEO发送结论。速度更快、成本更低,适合一致性检查。

Implementation Handoff

实现移交

After decision log saves, spawn execution agents with
isolation: "worktree"
:
typescript
// CEO provides this in execution plan
await Agent({
  name: "implement-cursor-pagination",
  isolation: "worktree",
  model: "claude-sonnet-4",
  prompt: `Implement cursor pagination per design-council-2026-05-17-pagination.

Decision log: file://~/.claude/councils/2026-05-17-pagination/log.md

File ownership (avoid conflicts):
- src/api/search.ts (yours)
- tests/api/search.test.ts (yours)

DO NOT TOUCH:
- src/auth/tokens.ts (security-engineer's impl)

Brief: file://~/.claude/councils/pagination/brief.md`
});
Worktree isolation prevents merge conflicts. See
references/implementation-handoff.md
in the plugin source for full playbook.
决策日志保存后,生成执行Agent并启用
isolation: "worktree"
typescript
// CEO会在执行计划中提供此配置
await Agent({
  name: "implement-cursor-pagination",
  isolation: "worktree",
  model: "claude-sonnet-4",
  prompt: `根据design-council-2026-05-17-pagination的决策实现游标分页。

决策日志:file://~/.claude/councils/2026-05-17-pagination/log.md

文件归属(避免冲突):
- src/api/search.ts(由你负责)
- tests/api/search.test.ts(由你负责)

禁止修改:
- src/auth/tokens.ts(由security-engineer实现)

简报:file://~/.claude/councils/pagination/brief.md`
});
工作树隔离可防止合并冲突。完整手册请查看插件源码中的
references/implementation-handoff.md

Memory Self-Audit Pattern

记忆自审计模式

Why it matters: If you've used design-council before and hit a failure (e.g., "security seat always blocks on offset pagination"), that failure lands in auto-memory. Phase 1 greps for
design-council
memories and overrides skill text with ground truth.
Example:
markdown
undefined
重要性:如果你之前使用design-council时遇到过故障(例如:"安全角色总是阻止偏移量分页"),该故障会被记录到自动记忆中。阶段1会检索
design-council
相关记忆,并以真实记录覆盖技能文档
示例:
markdown
undefined

In auto-memory

自动记忆中的记录

2026-05-10: design-council: security-engineer seat over-indexes on HMAC signatures. For internal APIs, skip security seat unless user data is involved.

Phase 1 brief will now include:
MEMORY OVERRIDE (from 2026-05-10): Skip security-engineer for internal APIs unless user data involved. Prior councils over-rotated on HMAC signatures.

This is automatic. Memory always wins.
2026-05-10: design-council: security-engineer角色 过度关注HMAC签名。对于内部API,除非涉及用户数据,否则跳过安全角色。

阶段1的简报将包含:
记忆覆盖(来自2026-05-10): 内部API场景下,除非涉及用户数据,否则跳过security-engineer角色。之前的委员会在HMAC签名上过度投入。

此过程自动执行。记忆记录始终优先。

Observability (Split-Pane Mode)

可观测性(分屏模式)

Tmux / iTerm2: Each seat renders in its own pane. Watch debates live.
json
// settings.json (Claude Code)
{
  "teammateMode": "auto"  // or "tmux" to force
}
Without split-pane terminal: Seats share main pane. Cycle with Shift+Down.
This is a Claude Code harness feature, not plugin-required.
Tmux / iTerm2:每个角色Agent在独立面板中渲染。可实时查看辩论过程。
json
// settings.json(Claude Code)
{
  "teammateMode": "auto"  // 或设置为"tmux"强制启用
}
无分屏终端时:角色Agent共享主面板。按Shift+Down切换。
这是Claude Code的内置功能,非插件必需。

Common Issues

常见问题

Silent Spawn Failures

静默生成失败

Symptom: Phase 2.5 reports
HANDSHAKE: 6/8 ok | verdict=DEGRADED
Cause:
TeamCreate
+
Agent
race on shared task list initialization.
Remediation (automatic):
  1. CEO retries failed seats once
  2. On second failure: drops seat, logs it, proceeds
User action: Check
~/.claude/councils/<slug>/log.md
for
degraded-roster: [security-engineer]
. If critical seat dropped, re-run with
add security-engineer
.
症状:阶段2.5报告
HANDSHAKE: 6/8 ok | verdict=DEGRADED
原因
TeamCreate
+
Agent
在共享任务列表初始化时存在竞争条件。
修复(自动)
  1. CEO重试失败的角色Agent一次
  2. 再次失败则:移除该角色,记录日志,继续执行
用户操作:查看
~/.claude/councils/<slug>/log.md
中的
degraded-roster: [security-engineer]
。若关键角色被移除,可重新运行并执行
add security-engineer

Token Budget Overrun

Token预算超支

Symptom: Debate stalls mid-round, costs spike.
Cause: Deep research by one seat (e.g.,
performance-engineer
running benchmarks).
Fix:
  1. Say "stop the council"
  2. Review partial log
  3. Re-run in review mode (skips cross-talk)
Prevention: Use review mode for conformance checks, debate mode for novel decisions.
症状:辩论中途停滞,成本飙升。
原因:某个角色Agent进行深度调研(例如:
performance-engineer
运行基准测试)。
解决方法
  1. 输入"stop the council"
  2. 查看部分日志
  3. 评审模式重新运行(跳过交叉讨论)
预防措施:一致性检查使用评审模式,全新决策使用辩论模式。

Deferred Items Lost

延期事项丢失

Symptom: Phase 5 decision says "DEFER: <item>" but no tracker created.
Cause: No tracker system detected (no beads, no
bd
on
$PATH
).
Fix: Manually file from decision log prose:
bash
undefined
症状:阶段5决策显示"DEFER: <事项>"但未创建跟踪项。
原因:未检测到跟踪系统(无beads,
$PATH
中无
bd
命令)。
解决方法:从决策日志中手动创建:
bash
undefined

From log.md

来自log.md

Deferred: Implement rate limiting

延期事项:实现限流

bd create
--title "Implement rate limiting for /search"
--context "From design-council-2026-05-17-pagination"

**Prevention**: Install beads or integrate another tracker (see `references/tracker-integration.md`).
bd create \ --title "为/search端点实现限流" \ --context "来自design-council-2026-05-17-pagination"

**预防措施**:安装beads或集成其他跟踪系统(查看`references/tracker-integration.md`)。

Prompt Cache Misses

提示词缓存未命中

Symptom: Token costs higher than predicted.
Cause: Brief modified between spawns (5-minute cache window).
Fix: Don't edit
~/.claude/councils/<slug>/brief.md
during Phase 2 spawn.
症状:Token成本高于预期。
原因:生成阶段(阶段2)中修改了简报(缓存窗口为5分钟)。
解决方法:阶段2生成过程中不要编辑
~/.claude/councils/<slug>/brief.md

Performance Characteristics

性能特征

MetricReview ModeDebate Mode (3 rounds)
Wall-clock2–3 min4–7 min
Tokens60–90k150–250k
Seats (typical)4–66–11
Cache savings~5k × seats~9k × seats
Parallelism: Wall-clock ≈ slowest seat, not sum of seats.
指标评审模式辩论模式(3轮)
时长2–3分钟4–7分钟
Token用量60–90k150–250k
角色数量(典型)4–66–11
缓存节省~5k × 角色数~9k × 角色数
并行性:时长≈最慢角色的耗时,而非所有角色耗时之和。

Configuration Files

配置文件

Brief Artifact

简报文件

bash
~/.claude/councils/<slug>/brief.md
bash
~/.claude/councils/<slug>/brief.md

Contents

内容

  • CLAUDE.md constraints
  • Referenced specs
  • Memory overrides
  • Beads context (if detected)

**Lifecycle**: Created Phase 1, read by all seats, deleted Phase 6 teardown.
  • CLAUDE.md约束条件
  • 参考规格
  • 记忆覆盖项
  • Beads上下文(若检测到)

**生命周期**:阶段1创建,所有角色Agent读取,阶段6清理。

Decision Log

决策日志

bash
~/.claude/councils/<yyyy-mm-dd>-<slug>/log.md
bash
~/.claude/councils/<yyyy-mm-dd>-<slug>/log.md

Frontmatter

前置元数据


slug: pagination date: 2026-05-17 mode: DEBATE roster: [principal-engineer, ...] primary-tracker-id: BEAD-126 status: resolved


**Lifecycle**: Persists after teardown. User artifact space.

slug: pagination date: 2026-05-17 mode: DEBATE roster: [principal-engineer, ...] primary-tracker-id: BEAD-126 status: resolved


**生命周期**:清理后持久保留。属于用户文件空间。

Code Examples

代码示例

Invoking from Code

从代码中调用

typescript
// In a TypeScript project
// User says: "convene council to review this cache layer"

// CEO automatically:
// 1. Reads current file context
// 2. Assembles brief from CLAUDE.md + memory
// 3. Shows plan card
// 4. On "go": spawns roster
typescript
// TypeScript项目中
// 用户指令:"召集委员会评审这个缓存层"

// CEO自动执行:
// 1. 读取当前文件上下文
// 2. 从CLAUDE.md + 记忆中汇编简报
// 3. 显示计划卡片
// 4. 收到"go"后:生成角色Agent

Custom Seat Brief (domain-expert)

自定义角色简报(domain-expert)

bash
undefined
bash
undefined

User: add domain-expert

用户:add domain-expert

CEO: "What domain? Provide brief."

CEO:"领域是什么?提供简介。"

User:

用户回复:

PostgreSQL query optimization. We're deciding between materialized views vs. incremental aggregates. Expert should eval EXPLAIN plans.

CEO injects this into domain-expert spawn prompt:
You are domain-expert (PostgreSQL query optimization).
Context: Eval materialized views vs. incremental aggregates. Review EXPLAIN plans in brief.
Brief: file://~/.claude/councils/cache-layer/brief.md
undefined
PostgreSQL查询优化。我们正在决定使用物化视图还是增量聚合。专家需要评估执行计划(EXPLAIN)。

CEO会将此内容注入domain-expert的生成提示词:
You are domain-expert (PostgreSQL query optimization).
Context: Eval materialized views vs. incremental aggregates. Review EXPLAIN plans in brief.
Brief: file://~/.claude/councils/cache-layer/brief.md
undefined

Execution Plan Format

执行计划格式

markdown
undefined
markdown
undefined

Execution Plan

执行计划

Phase 1: Cursor Token Implementation

阶段1:游标令牌实现

Owner: platform-engineer context Files:
  • src/api/search.ts
  • src/types/pagination.ts
负责人:platform-engineer上下文 文件:
  • src/api/search.ts
  • src/types/pagination.ts

Phase 2: HMAC Signing

阶段2:HMAC签名

Owner: security-engineer context
Files:
  • src/auth/tokens.ts
  • src/auth/rotation.ts
负责人:security-engineer上下文
文件:
  • src/auth/tokens.ts
  • src/auth/rotation.ts

Phase 3: Integration Tests

阶段3:集成测试

Owner: test-engineer context Files:
  • tests/api/search.test.ts
  • tests/auth/tokens.test.ts
负责人:test-engineer上下文 文件:
  • tests/api/search.test.ts
  • tests/auth/tokens.test.ts

Merge Strategy

合并策略

Worktree per phase. Merge order: 1 → 2 → 3. Conflict expected: src/api/search.ts (line 47, imports). Resolution: Accept Phase 2 (security adds token import).
undefined
每个阶段使用独立工作树。合并顺序:1 → 2 → 3。 预期冲突:src/api/search.ts(第47行,导入语句)。 解决方式:接受阶段2的修改(安全角色添加令牌导入)。
undefined

Environment Variables

环境变量

No secrets required. All state in
~/.claude/councils/
(user artifact space).
If integrating a custom tracker (not beads):
bash
export COUNCIL_TRACKER_CMD="jira"  # Default: bd
export COUNCIL_TRACKER_CREATE_ARGS="create --project DESIGN"
See
references/tracker-integration.md
for adapter contract.
无需密钥。所有状态存储在
~/.claude/councils/
(用户文件空间)。
如需集成自定义跟踪系统(非beads):
bash
export COUNCIL_TRACKER_CMD="jira"  # 默认值:bd
export COUNCIL_TRACKER_CREATE_ARGS="create --project DESIGN"
适配器契约请查看
references/tracker-integration.md

Version Compatibility

版本兼容性

  • Claude Code: v0.9.0+ (requires
    TeamCreate
    ,
    Agent.run_in_background
    )
  • Beads: v0.3.0+ (optional, for tracker integration)
  • Tmux: 3.0+ (optional, for split-pane observability)
  • Claude Code:v0.9.0+(需要
    TeamCreate
    Agent.run_in_background
    功能)
  • Beads:v0.3.0+(可选,用于跟踪系统集成)
  • Tmux:3.0+(可选,用于分屏可观测性)

Further Reading

扩展阅读

  • Implementation handoff playbook:
    references/implementation-handoff.md
    in plugin source
  • Tracker integration:
    references/tracker-integration.md
  • Changelog:
    CHANGELOG.md

  • 实现移交手册:插件源码中的
    references/implementation-handoff.md
  • 跟踪系统集成
    references/tracker-integration.md
  • 更新日志
    CHANGELOG.md

许可证:MIT
源码https://github.com/sjsyrek/design-council ",