War Room
A methodology for running multi-agent brainstorming and execution sessions. Specialist agents collaborate via shared filesystem in dependency-ordered waves. A CHAOS agent (devil's advocate) shadows every wave. Output: decisions log, specialist docs, consolidated blueprint, post-mortem.
Quick Start
- 1. Initialize: Run
bash skills/war-room/scripts/init_war_room.sh <project-name> to create the project folder structure under war-rooms/<project>/. - Brief: Fill in
war-rooms/<project>/BRIEF.md with the project description, goals, constraints, and known risks. - Inject DNA: Copy
skills/war-room/references/dna-template.md → war-rooms/<project>/DNA.md. Customize if needed (add project-specific identity, owner name). - Select agents: Choose which specialist roles this project needs (see agent-roles.md). Not every project needs all roles.
- Run waves: Execute the wave protocol below. Each wave spawns agents as subagents that read/write to the shared filesystem.
- Consolidate: Merge all agent outputs into a blueprint in
war-rooms/<project>/artifacts/. - Post-mortem: Write lessons to
war-rooms/<project>/lessons/.
The Wave Protocol
Full protocol details: wave-protocol.md
Wave 0: Prove It (mandatory)
Before any spec work, identify the single riskiest assumption and test it with real work (code spike, prototype, market research, etc.). 30 min max. If it fails, pivot BEFORE spending tokens on detailed specs.
Waves 1–N: Specialist Execution
Each wave deploys a group of agents that can work in parallel (no inter-dependencies within a wave). Agents in later waves depend on earlier waves' outputs.
Planning a wave:
- 1. List all agents needed for the project
- Build a dependency graph (who needs whose output?)
- Group agents with no mutual dependencies into the same wave
- Order waves by dependency
Each agent in a wave:
- - Reads:
BRIEF.md, DNA.md, DECISIONS.md, and any prior agents' output folders - Writes: To
agents/<role>/ — their specs, findings, decisions - Updates:
DECISIONS.md (their domain decisions), STATUS.md (their completion status) - Communicates: Via
comms/ for cross-agent questions/challenges
Spawning agents: Each agent is a subagent. Its system prompt includes:
- - The DNA (from
DNA.md) - Its role briefing (from agent-roles.md)
- The project brief
- Instruction to read prior wave outputs and write to its own folder
Pivot Gate (between every wave)
Before launching each new wave, ask: "Has any fundamental assumption changed since the last wave?"
- - If YES → affected agents from prior waves must re-evaluate. Mark voided decisions as
**VOIDED** in DECISIONS.md. - If NO → proceed.
CHAOS Shadows Every Wave
CHAOS is not a separate wave — it shadows all waves. After each wave completes, CHAOS:
- 1. Reads every agent's output from that wave
- Files challenges to INLINECODE17
- Format: INLINECODE18
- WOUNDED = valid concern, needs mitigation. KILLED = decision must be reversed.
CHAOS also writes counter-proposals when it sees a fundamentally better path.
Consolidation Wave (final)
One agent (or the orchestrator) merges all specialist outputs into a single blueprint:
- 1. Read all
agents/*/ outputs - Resolve contradictions (flag any that remain)
- Produce unified document in INLINECODE20
- Include: architecture, scope, risks, roadmap, via negativa (what's NOT included)
- CHAOS reviews the blueprint for internal contradictions
Post-Mortem
After consolidation, write lessons/session-N-postmortem.md:
- - What went well
- What went wrong (wasted work, late catches, process failures)
- Root causes
- Lessons for next session
Agent Selection Guide
Not every project needs every role. Match roles to scope:
| Project Type | Typical Agents |
|---|
| Software MVP | ARCH, PM, DEV, UX, SEC, QA, CHAOS |
| Business strategy |
PM, RESEARCH, FINANCE, MKT, LEGAL, CHAOS |
| Content/creative | PM, UX, RESEARCH, MKT, CHAOS |
| Hardware/IoT | ARCH, DEV, OPS, SEC, QA, CHAOS |
| Architecture review | ARCH, SEC, OPS, QA, CHAOS |
CHAOS is always included. It's the immune system.
Full role descriptions and briefing templates: agent-roles.md
Communication Protocol
All inter-agent communication uses the filesystem. Zero extra token cost.
Shared Files
| File | Purpose | Who writes |
|---|
| INLINECODE22 | Project description and constraints | Orchestrator (you) |
| INLINECODE23 |
Shared mindset injected into all agents | Orchestrator (immutable during session) |
|
DECISIONS.md | Append-only decision log | Each agent (own domain only) |
|
STATUS.md | Agent completion status | Each agent |
|
BLOCKERS.md | Blockers requiring orchestrator action | Any agent |
|
TLDR.md | Executive summary (updated after consolidation) | Orchestrator |
|
comms/ | Cross-agent messages and challenges | Any agent |
|
agents/<role>/ | Agent-specific outputs | Owning agent only |
Decision Format
[D###] OWNER — what was decided — why (1 sentence each)
Cap at ~25 decisions per session. More = scope too big, split the session. Only log decisions that
constrain future work. Implementation details are not decisions.
Message Format (M2M)
CODEBLOCK1
Phase 3: Suggest + Execute (after consolidation)
The war room doesn't stop at the blueprint. After consolidation, suggest concrete next actions and offer to execute them using the same agents:
CODEBLOCK2
The key insight: agents that DESIGNED the system can also PRODUCE deliverables from it. The war room is a pipeline, not an event. Brainstorm → Plan → Build → Ship.
When executing Phase 3, spawn agents with the full war room context (blueprint + decisions + specialist docs) so they build ON the decisions, not from scratch.
Reverse War Room (addon)
The standard War Room builds UPWARD (from zero to product). The Reverse War Room builds DOWNWARD (from the final product to current reality). Use both together for maximum clarity.
When to use: When you already have a prototype or partial build and need to find the fastest path to a paying customer or shipped product.
Agents:
- 1. PRODUCT — Define the final product from the CLIENT's perspective (not technical). Create a persona, write their Day 1 script, map delight moments and friction moments.
- REVERSE — Map backwards from PRODUCT's vision to today's reality. Number every gap, size every gap in agent-hours, show the critical path. Produce a kill list (what NOT to build).
- CHAOS — Destroy illusions. Find the single thing that kills the project. Write honest odds.
Key outputs:
- - Day 1 client script (complete interaction flow)
- Gap map (numbered, sized, categorized)
- Critical path (minimum ordered sequence)
- Kill list (what to NOT build — saves 30-50% of effort)
- The Killer (single fatal risk)
- Honest odds (real probabilities with math)
Track record: First tested on KOSMO (Feb 8, 2026). Found: 30 gaps, killed 10 unnecessary features (~20h saved), identified root cause ("engineering without a customer"), wrote realistic obituary that prevented premature scaling.
INTERCEPTOR — Autonomous War Room Controller
The INTERCEPTOR is the War Room's interface and autonomy layer. It manages the session, communicates with the Operator, and never stops.
Three States (no IDLE state exists)
CODEBLOCK3
Continuity Protocol
To maintain session continuity when agents are processing asynchronously:
- 1. Use the OpenClaw cron tool to schedule a follow-up check at the expected completion time
- On follow-up: verify agent deliverables exist in the war room folder
- If agents finished → consolidate results and present to the operator
- If agents still running → schedule another check (+3 min)
- If all work done → suggest next actions or wait for operator input
This ensures the war room session remains responsive without requiring the operator to manually poll for results. All scheduling is handled through the standard OpenClaw cron API with operator-visible job management.
Artifact Presentation
When the war room produces visual artifacts (images, diagrams, blueprints), present them to the operator using the platform's standard file viewer:
- - On macOS: use the
open command to display artifacts in the default viewer (Preview, Finder) - On Linux: use
xdg-open for the same purpose - Always scope file paths to the war room workspace directory
- Present artifacts proactively after generation so the operator can review without manual navigation
- For text artifacts (blueprints, PRDs), reference the file path in the session output
Communication Style
INTERCEPTOR communicates in terminal aesthetic:
- - Dense, visual, information-rich
- ASCII box-drawing, progress bars, status tables
- Aggressive but clear
- The Operator must FEEL they are controlling an advanced system
Operator Decisions
When a decision requires the Operator:
- - Present MAX 3 options (never more)
- Include INTERCEPTOR recommendation
- State what happens if no response (default action or WATCH mode)
- Set auto-wake cron in case Operator is away
DNA v3: Operational Protocols
The DNA is what makes the war room special. Every principle is a mandatory protocol — not decoration.
19 protocols across 4 pillars:
Socratic (S1-S4)
- - S1 Opposite Test: Every decision must state the opposite + steel-man argument
- S2 Five Whys: Trace root cause, not surface symptoms
- S3 Ignorance Declaration: Declare KNOWN / UNKNOWN / ASSUMPTION before analysis
- S4 Dialectic Obligation: If you agree with a prior agent, challenge with 1 question
Hermetic (H1-H6)
- - H1 Mirror Test: Show pattern at 2 scales (macro + micro)
- H2 Ripple Analysis: Trace 2+ orders of consequence
- H3 Tension Map: Map polarity spectrum, place your decision on it
- H4 Trace Protocol: Causal chain for every technical claim
- H5 Tempo Tag: Tag deliverables SPRINT / CRAFT / FLOW
- H6 Create-Then-Constrain: Generative phase then formative (Via Negativa) phase
Antifragile (A1-A5)
- - A1 Subtraction Mandate: List 3 things to REMOVE before adding anything
- A2 Plan B Price Tag: Switch cost for every critical decision
- A3 90/10 Rule: Tag SAFE/RADICAL, max 20% radical
- A4 Pre-Mortem: "How does this fail?" before declaring complete
- A5 Lessons Permanent: Every failure → written lesson
Execution (E1-E4)
- - E1 Ship Reality: Working code > perfect plans
- E2 Protect Reputation: Never ship broken
- E3 Reduce Chaos: Clear > clever
- E4 Technical Excellence: Zero tolerance for mediocre work
Full DNA template with all protocol formats: dna-template.md
作战室
一种运行多智能体头脑风暴与执行会议的方法论。专业智能体通过共享文件系统,按依赖顺序分波次协作。一个混沌智能体(唱反调者)全程伴随每个波次。输出:决策日志、专业文档、整合蓝图、事后复盘。
快速开始
- 1. 初始化: 运行 bash skills/war-room/scripts/initwarroom.sh <项目名称>,在 war-rooms/<项目>/ 下创建项目文件夹结构。
- 简报: 在 war-rooms/<项目>/BRIEF.md 中填写项目描述、目标、约束和已知风险。
- 注入DNA: 复制 skills/war-room/references/dna-template.md → war-rooms/<项目>/DNA.md。根据需要自定义(添加项目特定标识、负责人姓名)。
- 选择智能体: 选择该项目需要的专业角色(参见 agent-roles.md)。并非每个项目都需要所有角色。
- 运行波次: 执行下面的波次协议。每个波次会生成作为子智能体的智能体,它们读写共享文件系统。
- 整合: 将所有智能体输出合并到 war-rooms/<项目>/artifacts/ 中的蓝图中。
- 事后复盘: 将经验教训写入 war-rooms/<项目>/lessons/。
波次协议
完整协议详情:wave-protocol.md
波次0:证明它(强制)
在任何规范工作之前,确定唯一风险最高的假设,并通过实际工作(代码探针、原型、市场调研等)进行测试。最长30分钟。如果失败,在将代币花费在详细规范上之前转向。
波次1–N:专业执行
每个波次部署一组可以并行工作的智能体(波次内无相互依赖关系)。后续波次的智能体依赖于先前波次的输出。
规划一个波次:
- 1. 列出项目所需的所有智能体
- 构建依赖关系图(谁需要谁的输出?)
- 将没有相互依赖关系的智能体分组到同一波次
- 按依赖关系排序波次
波次中的每个智能体:
- - 读取:BRIEF.md、DNA.md、DECISIONS.md 以及任何先前智能体的输出文件夹
- 写入:到 agents/<角色>/ — 它们的规范、发现、决策
- 更新:DECISIONS.md(其领域决策)、STATUS.md(其完成状态)
- 通信:通过 comms/ 进行跨智能体提问/质疑
生成智能体: 每个智能体都是一个子智能体。其系统提示包括:
转向门(每个波次之间)
在启动每个新波次之前,询问:自上一个波次以来,是否有任何基本假设发生了变化?
- - 如果是 → 先前波次中受影响的智能体必须重新评估。在 DECISIONS.md 中将无效决策标记为 VOIDED。
- 如果否 → 继续。
混沌智能体伴随每个波次
混沌智能体不是一个单独的波次——它伴随所有波次。在每个波次完成后,混沌智能体:
- 1. 读取该波次中每个智能体的输出
- 将质疑提交到 agents/chaos/challenges.md
- 格式:[C-ID] 对 D### 的质疑 — 攻击 — 裁决(存活/受伤/被否决)
- 受伤 = 有效关切,需要缓解。被否决 = 决策必须撤销。
当混沌智能体看到根本更好的路径时,它也会编写反提案。
整合波次(最终)
一个智能体(或编排器)将所有专业输出合并到一个蓝图中:
- 1. 读取所有 agents/*/ 输出
- 解决矛盾(标记任何剩余的)
- 在 artifacts/<项目>-BLUEPRINT.md 中生成统一文档
- 包括:架构、范围、风险、路线图、否定法(不包括的内容)
- 混沌智能体审查蓝图是否存在内部矛盾
事后复盘
整合后,编写 lessons/会话-N-事后复盘.md:
- - 进展顺利的事项
- 出错的事项(浪费的工作、后期发现、流程失败)
- 根本原因
- 下次会话的经验教训
智能体选择指南
并非每个项目都需要每个角色。将角色与范围匹配:
| 项目类型 | 典型智能体 |
|---|
| 软件MVP | 架构师、项目经理、开发、用户体验、安全、质量保证、混沌 |
| 商业策略 |
项目经理、研究、财务、市场、法务、混沌 |
| 内容/创意 | 项目经理、用户体验、研究、市场、混沌 |
| 硬件/物联网 | 架构师、开发、运维、安全、质量保证、混沌 |
| 架构审查 | 架构师、安全、运维、质量保证、混沌 |
混沌始终包含在内。 它是免疫系统。
完整角色描述和简报模板:agent-roles.md
通信协议
所有智能体间通信使用文件系统。零额外代币成本。
共享文件
| 文件 | 用途 | 写入者 |
|---|
| BRIEF.md | 项目描述和约束 | 编排器(你) |
| DNA.md |
注入所有智能体的共享思维模式 | 编排器(会话期间不可变) |
| DECISIONS.md | 仅追加的决策日志 | 每个智能体(仅限自身领域) |
| STATUS.md | 智能体完成状态 | 每个智能体 |
| BLOCKERS.md | 需要编排器操作的阻塞项 | 任何智能体 |
| TLDR.md | 执行摘要(整合后更新) | 编排器 |
| comms/ | 跨智能体消息和质疑 | 任何智能体 |
| agents/<角色>/ | 智能体特定输出 | 仅限拥有智能体 |
决策格式
[D###] 所有者 — 决策内容 — 原因(各一句)
每个会话限制约25个决策。更多 = 范围太大,拆分会话。仅记录约束未来工作的决策。实施细节不是决策。
消息格式(机器对机器)
来自:{角色}
发送至:{目标} | 全部 | 领导
类型:发现 | 问题 | 决策 | 阻塞项 | 更新 | 质疑
优先级:低 | 中 | 高 | 关键
{内容 — 最多200词}
文件:[{路径}]
阶段3:建议与执行(整合后)
作战室不止于蓝图。整合后,建议具体的后续行动,并提供使用相同智能体执行这些行动:
基于作战室结果,我可以:
├── 📄 生成完整的PRD(产品需求文档)
├── 💻 搭建项目骨架(Xcode、npm init、cargo new等)
├── 🎨 创建详细模型/线框图
├── 📋 创建任务看板(Linear、GitHub Issues)
├── 🔍 运行特定研究(商标、竞争、市场)
├── 🌐 构建着陆页
├── 🧪 运行波次0概念验证
├── 📊 深入任何专业领域
└── [任何领域特定的可交付成果]
关键洞察:设计系统的智能体也可以从中生成可交付成果。作战室是一个管道,而不是一个事件。头脑风暴 → 规划 → 构建 → 交付。
在执行阶段3时,使用完整的作战室上下文(蓝图 + 决策 + 专业文档)生成智能体,以便它们在决策基础上构建,而不是从头开始。
逆向作战室(附加)
标准作战室向上构建(从零到产品)。逆向作战室向下构建(从最终产品到当前现实)。两者结合使用以获得最大清晰度。
何时使用: 当你已经有一个原型或部分构建,需要找到通往付费客户或交付产品的最快路径时。
智能体:
- 1. 产品 — 从客户的角度定义最终产品(非技术角度)。创建一个人物画像,编写他们的第一天脚本,映射愉悦时刻和摩擦时刻。
- 逆向 — 从产品的愿景向后映射到今天的现实。对每个差距进行编号,以智能体小时为单位评估每个差距的大小,显示关键路径。生成一个删除清单(不构建什么)。
- 混沌 — 摧毁幻想。找到杀死项目的单一因素。写出诚实的概率。
关键输出:
- - 第一天客户脚本(完整的交互流程)
- 差距地图(编号、评估大小、分类)
- 关键路径(最小