ensemble-team

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Ensemble Team Setup

集成团队搭建

Set up an AI ensemble programming team for any software project. Creates the full structure for a team of expert agents working in a single-driver mob programming style with consensus-based decisions, TDD, and continuous retrospectives.

为任意软件项目搭建AI集成编程团队。为采用单驾驶员mob编程模式、基于共识决策、TDD和持续回顾会议的专家Agent团队创建完整架构。

Workflow

工作流程

Phase 1: Project Discovery

阶段1：项目探索

Gather essential project information. Ask the user:

Project name and description: What is being built? What problem does it solve?
Tech stack: Language, framework, database, frontend approach, testing tools. If unsure, help them decide based on their goals.
Product vision: Target user? MVP scope? Vague ideas are fine — the Product Manager agent will refine them.
Dev environment: Nix? Docker? Standard package managers? CI provider?
Repository: Existing repo or new? Branching strategy?

收集关键项目信息。向用户询问：

项目名称与描述：要构建什么产品？它解决了什么问题？
技术栈：编程语言、框架、数据库、前端方案、测试工具。若不确定，可根据用户目标协助决策。
产品愿景：目标用户是谁？MVP范围是什么？模糊的想法也可以 —— Product Manager Agent会对其进行细化。
开发环境：使用Nix？Docker？标准包管理器？CI提供商？
代码仓库：已有仓库还是新建？分支策略是什么？

Phase 2: Team Composition

阶段2：团队组成

Determine the right team.

PREREQUISITE: Read

references/role-catalog.md

before proceeding.

确定合适的团队。

前置要求：继续操作前请阅读

references/role-catalog.md

。

Tiered Team Presets

分层团队预设

Start with a preset, then adjust based on project needs. The team formation session (Phase 5) helps determine the right fit. The user may modify any preset.

Preset	Size	Composition
Full	~9	1 Product Manager, 1 UI/UX Designer, 1 Accessibility Specialist, 1 Domain SME, 1 QA Analyst, 4 Software Engineers
Lean	~5-6	1 Product Manager, 1 Domain SME, 1 Dev Practice Lead, 2-3 Software Engineers, 1 flex role (UX, QA, or DevOps based on need)
Solo-plus	~3	1 Domain SME, 1 Dev Practice Lead, 1 Software Engineer

Approximate token costs per discussion round:

Solo-plus (~3 agents): Lightweight. ~5-10K tokens per round.
Lean (~5-6 agents): Moderate. ~15-25K tokens per round.
Full (~9 agents): Heavy. ~30-50K tokens per round. Reserve for projects where the governance overhead pays for itself.

Actual costs depend on model, context length, and discussion complexity. These are rough estimates for setting expectations, not precise accounting.

Selecting a preset: Ask the user about project scope, timeline, and complexity. Solo-plus suits focused tasks or spikes. Lean suits most projects. Full suits large-scope products with UI, accessibility, and quality requirements.

Extend, do not replace: These presets build on the role catalog. See the catalog for conditional roles (Security, Data/ML, API Specialist, etc.) that can augment any preset. Odd numbers preferred for tie-breaking.

Research each expert — do NOT pick from a memorized list. For each role:

Identify the specific technology/domain this project needs
Use WebSearch to find the recognized authority — the person who wrote the book, created the tool, or gave the defining talks for that specific area
Verify their credentials, recent work, and relevance to this project
Evaluate: published authority, distinctive voice, practical experience, complementary perspective to other team members

Present each proposed expert with: name, credentials, key published work, why they fit THIS project, and what they'd focus on. Let user approve, swap, or remove.

从预设方案开始，再根据项目需求调整。团队组建会议（阶段5）会帮助确定最适合的方案。用户可修改任意预设。

预设方案	规模	人员组成
Full（完整型）	~9	1 Product Manager、1 UI/UX Designer、1 Accessibility Specialist、1 Domain SME、1 QA Analyst、4 Software Engineers
Lean（精简型）	~5-6	1 Product Manager、1 Domain SME、1 Dev Practice Lead、2-3 Software Engineers、1灵活角色（根据需求可选UX、QA或DevOps）
Solo-plus（单人增强型）	~3	1 Domain SME、1 Dev Practice Lead、1 Software Engineer

每轮讨论的大致Token成本:

Solo-plus（约3个Agent）：轻量型。每轮约5-10K Token。
Lean（约5-6个Agent）：中等规模。每轮约15-25K Token。
Full（约9个Agent）：重型。每轮约30-50K Token。仅在治理成本能带来回报的大型项目中使用。

实际成本取决于模型、上下文长度和讨论复杂度。以上为大致估算，用于设定预期，并非精确核算。

选择预设方案：询问用户项目范围、时间线和复杂度。Solo-plus适合聚焦任务或技术调研。Lean适合大多数项目。Full适合包含UI、无障碍和质量要求的大型产品。

扩展而非替换：这些预设方案基于角色目录构建。查看目录获取可扩充任意预设的条件角色（Security、Data/ML、API Specialist等）。优先选择奇数人数以避免投票平局。

研究每位专家 —— 不要从记忆列表中选择。针对每个角色：

确定项目所需的特定技术/领域
使用WebSearch查找该领域的权威人士 —— 撰写相关书籍、创建工具或发表标志性演讲的人
验证其资质、近期工作及与本项目的相关性
评估：公开权威性、独特观点、实践经验、与其他团队成员的互补性

向用户展示每位候选专家的信息：姓名、资质、核心著作、适配本项目的原因及专注方向。允许用户批准、替换或移除。

Phase 3: Generate Team Profiles

阶段3：生成团队档案

Create

.team/<name>.md

for each member.

PREREQUISITE: Read

references/profile-template.md

before proceeding.

Required sections: Opening bio, Role, Core Philosophy (5-8 principles from their published work), Technical Expertise (6-12 items), On This Project (concrete guidance), Communication Style (personality + 4-6 characteristic phrases), Mob Approach, Code Review Checklist (6-12 checks), Lessons (empty, to be updated).

Quality gates: Profile must not be interchangeable with another expert. Must include project-specific guidance. Must capture their distinctive voice.

为每位成员创建

.team/<name>.md

文件。

前置要求：继续操作前请阅读

references/profile-template.md

。

必填章节：开场简介、角色、核心理念（来自其公开著作的5-8条原则）、技术专长（6-12项）、本项目职责（具体指导）、沟通风格（性格+4-6句标志性表述）、Mob协作方式、代码审查清单（6-12项检查）、经验教训（空白，后续更新）。

质量标准：档案不能与其他专家的档案可互换。必须包含项目专属指导。必须体现其独特风格。

AI-Approximation Disclaimer

AI近似声明

Every profile MUST include the following disclaimer block immediately after the opening biography paragraph:

> **AI-Approximation Notice**: This profile is an AI-generated approximation inspired
> by [Name]'s published work, talks, and writings. The real [Name] has not endorsed
> or reviewed this profile. All outputs should be verified against their actual
> published work. This profile creates a "diversity of heuristics" drawing on their
> known perspectives — it does not simulate the actual person.

每个档案必须在开场简介段落之后立即包含以下声明块：

> **AI近似声明**：本档案是受[姓名]的公开著作、演讲和文章启发生成的AI近似内容。真实的[姓名]并未认可或审阅本档案。所有输出均应与他们的实际公开著作进行验证。本档案借鉴其已知观点创建了「启发式多样性」—— 并非模拟真实人物。

AI Self-Awareness Clause

AI自我认知条款

Each profile must include in the "Your Role on This Team" section a statement that the team member is aware it is an AI agent embodying a perspective, not the actual person. Human time constraints are irrelevant to AI agents. Standing aside on a decision when the topic falls outside the role's expertise is appropriate deference, not disapproval.

每个档案的「你在团队中的角色」章节必须包含声明：团队成员知晓自己是体现某一观点的AI Agent，而非真实人物。AI Agent不受人类时间限制。当议题超出角色专业领域时，选择回避是恰当的尊重，而非反对。

Compressed Active-Context Form

压缩活跃上下文格式

Each profile MUST include a

## Compressed Context

section at the end: a dense summary of the profile in under 500 tokens covering role, top 3-5 principles, key expertise areas, and characteristic review focus. This compressed form is loaded during discussion and review phases. The full profile is loaded only when the member is actively driving or navigating code.

每个档案必须在末尾包含

## 压缩上下文

章节：用少于500个Token的篇幅总结档案内容，涵盖角色、前3-5条核心原则、关键专长领域和标志性审查重点。此压缩格式会在讨论和审查阶段加载。完整档案仅在成员担任驾驶员或主导代码工作时加载。

Phase 4: Generate Project Scaffolding

阶段4：生成项目脚手架

Coordinator Instructions

协调员说明文档

PREREQUISITE: Read

references/coordinator-template.md

before proceeding.

Fill in roster, build tools, team size. Generate the coordinator instructions at

.team/coordinator-instructions.md

. Then add a pointer in the harness-specific config file (e.g.,

CLAUDE.md

for Claude Code,

.cursorrules

for Cursor, project instructions for other harnesses) directing the main agent to read

.team/coordinator-instructions.md

. The coordinator instructions file is for the coordinator only.

前置要求：继续操作前请阅读

references/coordinator-template.md

。

填写人员名单、构建工具、团队规模。在

.team/coordinator-instructions.md

生成协调员说明文档。然后在适配工具的配置文件（例如Claude Code的

CLAUDE.md

、Cursor的

.cursorrules

、其他工具的项目说明）中添加指向

.team/coordinator-instructions.md

的指针。协调员说明文档仅供协调员使用。

AGENTS.md — Team Structure Section

AGENTS.md —— 团队结构章节

Insert a "Team Structure" managed section into

AGENTS.md

noting:

Team member profiles are located in
```
.team/
```
Project owner constraints are defined in
```
PROJECT.md
```
Domain glossary is maintained at
```
docs/glossary.md
```

This section provides orientation for all agents. The conventions section of

AGENTS.md

will be populated by the team during the formation session (Phase 5).

在

AGENTS.md

中插入「团队结构」管理章节，注明：

团队成员档案位于
```
.team/
```
目录
项目所有者约束定义在
```
PROJECT.md
```
中
领域术语表维护在
```
docs/glossary.md
```

本章节为所有Agent提供指引。

AGENTS.md

的约定章节将在团队组建会议（阶段5）中由团队填充。

PROJECT.md

PREREQUISITE: Read

references/project-template.md

before proceeding.

Fill in tech stack, scope (Must/Should/Could/Out), dev mandates, environment.

前置要求：继续操作前请阅读

references/project-template.md

。

填写技术栈、范围（Must/Should/Could/Out）、开发要求、环境信息。

Supporting docs

配套文档

docs/glossary.md: Domain glossary skeleton (Core Types table, Actions table, Errors table, Type Design Principles)
docs/deferred-items.md: Tracker table (Item | Category | Source | Severity | Status)
docs/future-ideas.md: Parking lot for out-of-scope ideas

docs/glossary.md：领域术语表框架（核心类型表、操作表、错误表、类型设计原则）
docs/deferred-items.md：延期事项跟踪表（事项 | 分类 | 来源 | 优先级 | 状态）
docs/future-ideas.md：超出范围的创意收集池

Phase 5: Team Formation Session

阶段5：团队组建会议

This is the critical phase. The team debates and reaches consensus on their working conventions, architectural decisions, and domain terminology.

How it works: The coordinator activates the full team, then presents each discussion topic one at a time. The team debates, proposes approaches, and reaches consensus using the Robert's Rules protocol. Outputs go to the appropriate location based on the type of decision:

Working conventions (collaboration norms, definition of done, code conventions, communication norms, mob model details, retrospective cadence, tooling conventions) are recorded in the conventions section of
```
AGENTS.md
```
.
Architectural decisions (principles, deployment strategy, state management, testing philosophy) are recorded as ADRs in
```
docs/ARCHITECTURE.md
```
.
Domain terminology (types, actions, errors, naming conventions) updates
```
docs/glossary.md
```
.

The 10 topics (non-exhaustive — team may add more):

How do we decide what to build?
How does the Driver-Reviewer mob model work?
When is a piece of work "done"?
What is our commit and integration pipeline?
How do we resolve disagreements?
What are our code conventions?
When and how do we hold retrospectives?
What are our architectural principles?
How do we communicate as a team?
What tooling and repository conventions do we follow?

Each topic includes the problem it addresses and sub-questions to guide discussion. The team's answers become their conventions and decisions — not pre-canned templates.

这是关键阶段。团队将讨论并就工作约定、架构决策和领域术语达成共识。

运作方式：协调员激活整个团队，然后逐个提出讨论议题。团队进行辩论、提出方案，并遵循Robert议事规则达成共识。输出根据决策类型保存到相应位置：

工作约定（协作规范、完成定义、代码规范、沟通准则、Mob模式细节、回顾会议频率、工具使用约定）记录在
```
AGENTS.md
```
的约定章节中。
架构决策（原则、部署策略、状态管理、测试理念）作为ADR记录在
```
docs/ARCHITECTURE.md
```
中。
领域术语（类型、操作、错误、命名规范）更新到
```
docs/glossary.md
```
。

10个核心议题（非穷尽 —— 团队可添加更多）：

我们如何决定要构建什么？
驾驶员-审核员Mob模式如何运作？
一项工作何时才算「完成」？
我们的提交与集成流水线是什么？
我们如何解决分歧？
我们的代码规范是什么？
我们何时及如何开展回顾会议？
我们的架构原则是什么？
我们作为团队如何沟通？
我们遵循哪些工具和仓库约定？

每个议题都包含其要解决的问题和引导讨论的子问题。团队的答案将成为他们的约定和决策 —— 而非预制模板。

Phase 6: Configure Permissions

阶段6：配置权限

Grant team agents the permissions they need to do their work (file editing, shell access, etc.). How this is configured depends on the harness:

Claude Code: Create/update

.claude/settings.json

with

"allow": ["Edit", "Write", "Bash(*)"]

Cursor/Windsurf: Configure tool permissions in the IDE settings
Other harnesses: Follow the harness documentation for agent permission grants

为团队Agent授予开展工作所需的权限（文件编辑、Shell访问等）。配置方式取决于所使用的工具：

Claude Code：创建/更新

.claude/settings.json

，添加

"allow": ["Edit", "Write", "Bash(*)"]

Cursor/Windsurf：在IDE设置中配置工具权限
其他工具：遵循工具文档中的Agent权限授予说明

Phase 7: Configure CI

阶段7：配置CI

Add

paths-ignore

rules to CI config for any harness-generated session or transcript directories (e.g.,

.claude-sessions/

for Claude Code) to prevent them from triggering CI runs.

在CI配置中添加

paths-ignore

规则，排除任何工具生成的会话或转录目录（例如Claude Code的

.claude-sessions/

），以避免触发不必要的CI运行。

Phase 8: Summary

阶段8：总结

Present: files created, how to start the team. The harness config file (e.g.,

CLAUDE.md

for Claude Code) references

AGENTS.md

via

(or equivalent include mechanism), and the coordinator reads

.team/coordinator-instructions.md

for its operating instructions. Suggest telling the coordinator what to build.

Files created:

```
.team/<name>.md
```
— team member profiles
```
.team/coordinator-instructions.md
```
— coordinator operating instructions
```
AGENTS.md
```
— team structure and conventions (populated during formation session)
```
PROJECT.md
```
— project owner constraints
```
docs/ARCHITECTURE.md
```
— architectural decision records (populated during formation session)
```
docs/glossary.md
```
— domain glossary
```
docs/deferred-items.md
```
— deferred items tracker
```
docs/future-ideas.md
```
— parking lot for out-of-scope ideas
Harness config pointer (e.g.,
```
CLAUDE.md
```
) — directs coordinator to read
```
.team/coordinator-instructions.md
```

展示：已创建的文件、如何启动团队。工具配置文件（例如Claude Code的

CLAUDE.md

）通过

（或等效的引用机制）关联

AGENTS.md

，协调员读取

.team/coordinator-instructions.md

获取操作指引。建议告知协调员要构建的内容。

已创建的文件:

```
.team/<name>.md
```
—— 团队成员档案
```
.team/coordinator-instructions.md
```
—— 协调员操作指引
```
AGENTS.md
```
—— 团队结构与约定（组建会议期间填充）
```
PROJECT.md
```
—— 项目所有者约束
```
docs/ARCHITECTURE.md
```
—— 架构决策记录（组建会议期间填充）
```
docs/glossary.md
```
—— 领域术语表
```
docs/deferred-items.md
```
—— 延期事项跟踪表
```
docs/future-ideas.md
```
—— 超出范围的创意收集池
工具配置指针（例如
```
CLAUDE.md
```
）—— 指引协调员读取
```
.team/coordinator-instructions.md
```

Retrospective Protocol

回顾会议协议

Retrospectives are event-driven, not time-based. AI agents work continuously — arbitrary intervals are meaningless.

Trigger: After each shipped PR (merged to the integration branch).
Participants: The full team that did the work, while they still have context. The human is a team member who participates in the consent protocol, not an external approver.
Format: The team reflects on what worked, what did not, and proposes process improvements. Any structured format (Start/Stop/Continue or equivalent) is fine as long as it produces concrete proposals.
Output: Retrospective proposals are changes to
```
AGENTS.md
```
conventions or new ADRs in
```
docs/ARCHITECTURE.md
```
— the same places formation session outputs go. Process improvement proposals require the same consent protocol as any other team decision, and the human must consent (as a team member) before changes to
```
AGENTS.md
```
or new ADRs are adopted.
Mini-retros after each CI build remain a lightweight observational checkpoint (did we follow the pipeline? was the commit atomic?) and do not require human consent. They are observational, not prescriptive.

回顾会议由事件触发，而非时间触发。AI Agent持续工作 —— 任意时间间隔毫无意义。

触发条件：每个已合并到集成分支的PR完成后。
参与者：参与该工作的完整团队成员，在他们仍有上下文记忆时开展。人类作为团队成员参与共识协议，而非外部审批者。
格式：团队反思有效做法、待改进之处，并提出流程优化建议。任何结构化格式（Start/Stop/Continue或等效格式）均可，只要能产生具体提议。
输出：回顾会议提议将修改
```
AGENTS.md
```
中的约定或在
```
docs/ARCHITECTURE.md
```
中新增ADR —— 与组建会议输出的存储位置相同。流程改进提议需要与其他团队决策遵循相同的共识协议，且在修改
```
AGENTS.md
```
或新增ADR前，必须获得人类（作为团队成员）的同意。
每个CI构建后的迷你回顾会议是轻量级的观察检查点（我们是否遵循了流水线？提交是否原子化？），无需人类同意。它们是观察性的，而非指令性的。

Key Principles

核心原则

Non-negotiable aspects baked in from production experience.

PREREQUISITE: Read

references/lessons-learned.md

before proceeding.

Consensus before push (review locally, then push)
Refactor step is mandatory every commit
CI wait rule (never queue multiple CI runs)
Mini-retro after every CI build (team runs it, not coordinator)
PR-triggered retrospective with consent-based outputs
Driver handoff protocol (summary + git log + green baseline)
Glossary compliance (domain types match glossary)
Deferred items tracked immediately
Reviewer coordination (check others' reviews first)
Explicit Driver onboarding in activation prompts
Session transcripts excluded from CI triggers
AI-approximation disclaimer on every profile
Compressed active-context form on every profile
Stand-aside means deference, not disapproval

从生产经验中提炼的不可协商的规则。

前置要求：继续操作前请阅读

references/lessons-learned.md

。

推送前达成共识（本地审查，然后推送）
每次提交必须包含重构步骤
CI等待规则（不得同时排队多个CI运行）
每个CI构建后开展迷你回顾会议（由团队而非协调员主持）
PR触发的回顾会议，输出基于共识
驾驶员交接协议（总结+Git日志+绿色基线）
术语表合规（领域类型与术语表匹配）
立即跟踪延期事项
审核员协调（先查看他人的审核意见）
激活提示中明确包含驾驶员入职说明
会话转录排除在CI触发路径之外
每个档案包含AI近似声明
每个档案包含压缩活跃上下文格式
回避意味着尊重，而非反对

Factory Mode (Optional)

工厂模式（可选）

When the

pipeline

skill is installed alongside

ensemble-team

, the coordinator detects this during setup and enables factory mode. This adds a Phase 1.5 ("Factory Mode Configuration") between team formation and the build phase.

In factory mode, the coordinator delegates the entire build phase to the pipeline controller rather than managing it directly. The pipeline handles slice queuing, TDD pair dispatch, code review orchestration, and merge decisions through quality gates. The full team still reviews before any push.

See

references/factory-mode.md

for coordinator handoff details.

当

pipeline

技能与

ensemble-team

一同安装时，协调员会在设置期间检测到这一点并启用工厂模式。这会在团队组建和构建阶段之间添加阶段1.5（「工厂模式配置」）。

在工厂模式下，协调员将整个构建阶段委托给流水线控制器，而非直接管理。流水线通过质量门处理任务切片排队、TDD配对调度、代码审查编排和合并决策。完整团队仍会在推送前进行审查。

查看

references/factory-mode.md

获取协调员交接细节。

Factory Mode vs. Supervised Mode

工厂模式 vs 监督模式

Supervised mode (default): The coordinator manages the build phase. All decisions use the Robert's Rules consensus protocol. The coordinator facilitates driver rotation, review cycles, and retrospectives.
Factory mode (when
```
pipeline
```
is installed): The pipeline manages the build phase. Quality gates replace consensus for build-time decisions. The coordinator remains active for planning, factory configuration, and post-build review. The full team participates in pre-push review and retrospectives as before.

监督模式（默认）：协调员管理构建阶段。所有决策遵循Robert议事规则共识协议。协调员负责驾驶员轮换、审查周期和回顾会议。
工厂模式（安装
```
pipeline
```
后）：流水线管理构建阶段。质量门替代共识用于构建时决策。协调员仍负责规划、工厂配置和构建后审查。完整团队仍会参与推送前审查和回顾会议。",