/war-room

name: war-room
description: Sokka's war room for architecture decisions. Use for architect, /architect, "architect this", "design this", "how should we build this", "which approach", when a change crosses a module or service boundary, or when there are two or more plausible designs. Sketches types, signatures, and module boundaries before code, runs competing designs in parallel on different models, records the decision, and stays in the loop while implementation fills in.

Sokka's war room

Before the invasion, Sokka laid every option on the table and argued each one out loud. Do the same before you commit to a design that other code will depend on. Sketch the types, the signatures, and the module boundaries with `not implemented` bodies and pseudocode. Put several minds on the map, synthesize the best of them, and only then fill in code against the chosen sketch.

On Codex, read [avatar-mode/references/codex.md](../avatar-mode/references/codex.md) for tool equivalents.

Start

Open a todolist with one entry per phase.

1. Ground 2. Sketch 3. Agree 4. Implement 5. Scrap

Phase A: Ground the problem

Build a real mental model of every system the new code touches. Naming a file is not grounding.

1. **Frame the decision.** One sentence on what must be decided, and the constraints that cannot move (deadlines, compatibility, performance budgets, team ownership). 2. **Read the terrain.** Run `seismic-sense` over the relevant subsystems and produce the architectural explanation it prescribes. Note the existing patterns a new design should match or deliberately break. 3. **Learn why it is shaped this way.** If the design redefines ownership or layering, run `past-lives` on the existing shape, so its rationale becomes a constraint instead of a guess.

Skip Phase A only when the work is truly greenfield, with no surrounding system to integrate.

Phase B: Sketch

Design it twice. Require at least two structurally distinct candidates before synthesis, even when the first looks good enough. They are whole-shape alternatives, not point fixes inside one shape (Exhaust the Design Space, Air in `four-elements`). Always include the smallest design that could work. Each candidate states:

• The data shape and who owns it.
• The public interface, as signatures or a short example call.
• What changes for existing callers.
• What it makes easy and what it makes hard later.

Run the candidates in parallel

Always run the candidates as a bakeoff with `agni-kai`, so different models produce them. One model drafting both candidates alone does not count as designing it twice. Give it the design-sketch task and the Phase A grounding artifacts, and pass [references/runner-prompt.md](references/runner-prompt.md) as each runner's prompt.

• **Runners.** Take the models from the `panel` line of the avatar-setup sheet (default `opus, fable, sonnet, haiku`). One runner per entry. Disagreement between models is signal.
• **Dispatch.** Each runner is Sokka (`subagent_type: "team-avatar:sokka"`) with that entry's model, in its own git worktree or its own subdirectory under the sketch directory. Runners never share a working directory.
• **Effort.** A panel entry that names an effort (`opus @high`) passes that level as the Agent tool's `effort` parameter on Claude Code, or as `spawn_agent`'s `reasoning_effort` on Codex.
• **Without a bakeoff.** If `agni-kai` cannot run, dispatch the runners the same way yourself, then synthesize by hand. Pick the strongest candidate as the base, graft the best idea from each other candidate onto it, and record what was taken, what was rejected, and why.
• **As a subagent.** A character running as a subagent does not dispatch. Draft the candidates yourself, one after another, each in its own file, and say in the reply that the panel was not run.

Settle facts by experiment

If a question has an observable answer (latency, memory, the ergonomics of a call site), run `scouting-flight` instead of arguing.

Screen and compare

1. **Screen for red flags.** Check every candidate against [references/design-red-flags.md](references/design-red-flags.md). Assume the next contributor is an agent that sees only the files it opened, copies the nearest example, and takes the shortest path that compiles. Prefer the design where a change that looks right from one file is right for the whole repo. 2. **Compare on interface depth.** Prefer the design that hides more complexity behind a smaller, simpler public surface. A rich interface can keep call chains short by concentrating capability instead of scattering it across layers. 3. **Compare in one table.** Rows are the designs. Columns are the criteria that matter for this decision, plus reversibility and diff size. Mark each cell with evidence or *inferred*.

The bakeoff, or your hand synthesis, returns one synthesized design package. Its synthesis decision fills the "Synthesis decision" section of the rationale.

Phase C: Agree (opt in)

By default, go straight to implementation with the synthesized design. There is no human checkpoint.

Opt in to a checkpoint only when the invoker asks for one ("architect with checkpoint", "stop and show me before implementing"). Then surface the synthesized design and pause for sign-off.

• **If the human must choose** (a product or preference call), present the comparison table and your recommendation. Do not ask an open question.
• **Scaffold first.** The synthesis can ship as its own commit either way. Planned and scoped breakage during fill-in is fine (Foundational Thinking, Water, and Outcome-Oriented Execution, Fire, in `four-elements`).
• **Attack the favorite.** For adversarial pressure before implementing, run `lie-detector` on the synthesized sketch, or have `earth-rumble` review it as if it were already merged. Answer each finding or change the design.
• **Pushback is evidence.** If the human pushes back on the shape, in a checkpoint or after the fact, treat that as Phase A ev