Writing a Goal Document for Liza Multi-Agent Sprints

A well-written goal document is the foundation of every Liza multi-agent sprint. Learn how to produce one using Coach and Challenger pairing modes.

A goal document is the single authoritative input to liza init --spec. It tells the orchestrator what to build, for whom, and what “done” looks like — with enough precision that agents can decompose it into concrete tasks without guessing. Vague goals compound: every ambiguity in the goal document becomes a decision an agent makes without you, and bad micro-decisions accumulate into implementations that miss the mark.

​

Why the Goal Document Matters

Orchestrator input

The orchestrator cannot decompose your goal into tasks without a clear spec. It uses the goal document as the authoritative source for every planning decision.

Product decisions live here

Agents make implementation choices but not product decisions. Every product decision — what to build, for whom, what’s out of scope — must live in the goal document. If it’s missing, agents either guess or block.

Mental model building

Writing the goal document forces you to build a mental model of the system before agents start. That model is your primary tool for reviewing agent work throughout the sprint.

Drift prevention

Any drift in the goal document compounds during decomposition. A single ambiguous sentence can produce multiple tasks pointing in different directions.

The goal document is not a technical specification. It defines the problem (WHY) and desired behavior (WHAT), not how to implement it. Agents own the HOW.

​

Goal Document Sections

A complete goal document covers these sections:

Section	What It Contains
Problem Statement	The problem, with evidence — what’s broken or missing today
Target Users	Who benefits and what they need
Solution Overview	Key concepts, main flows, and design decisions at a high level
MVP Scope	A checkbox list of what’s IN the first deliverable
Explicit Out of Scope	What you are NOT building — explicit enough to prevent creep
General Specification	Per-capability behavior: inputs, outputs, rules, edge cases, UI layouts
Success Criteria	How you know you succeeded
Risks & Assumptions	What could go wrong

The General Specification section carries the most weight. For each capability, describe expected behavior explicitly enough that an agent does not need to infer how things work. If a UI is involved, include layouts and interaction patterns.

​

Step-by-Step Process

1. Start a pairing session

   Open your coding CLI (Claude Code, Codex, or any CLI configured with the Liza contract) in a terminal. You will use two collaboration modes in sequence: Coach first, then Challenger. A rough idea is enough to start — even a single sentence describing the problem.

2. Switch to Coach mode — surface the WHY

   Ask the agent to enter Coach mode:

   Switching to Coach — I have an idea for a project but the WHY isn't sharp yet.
   

   Coach mode is Socratic. The agent asks questions rather than proposing solutions. Expect questions like:

   • Who is this for? What problem are they hitting today?
   • What happens if you don’t build this?
   • What’s the smallest version that would be useful?

   Stay in Coach mode until you can articulate the problem statement, target users, and MVP scope without hesitation. If you find yourself saying “I think” or “maybe”, you are not done yet.

3. Switch to Challenger mode — stress-test the WHAT

   Once the vision feels solid, switch modes:

   Switching to Challenger — the vision feels ready, attack it.
   

   Challenger mode tries to break your plan:

   • What is the strongest argument against this approach?
   • What failure mode have you not considered?
   • What is explicitly out of scope, and are you sure it can wait?

   Defend or revise. The goal is not to survive unscathed — it is to surface gaps before agents hit them mid-sprint.

4. Write the goal document

   Still in the same session, ask the agent to draft the goal document based on your conversation. You can use templates/vision-template.md in the repo as a starting point. The draft should cover all sections from the table above.

   For the General Specification section, work interactively with the agent to produce per-capability behavior descriptions. If the product has a UI, have the agent produce layout and interaction descriptions now — agents cannot infer these later.

5. Review thoroughly

   Read every word of the document yourself. This step is not optional.

   Apply the engineer-unfamiliar test: could an engineer who has never heard of your project read this document and know exactly what to build? If not, the document is not ready.

   Check for:

   • Ambiguous or missing sections
   • Placeholders and “TBD” items on the critical path
   • Out-of-scope statements vague enough to cause creep
   • Any decision an agent would have to guess

   Do not skip this review. Any drift in the goal document compounds during task decomposition. A single ambiguous requirement can produce several tasks pointing in conflicting directions, costing you a full sprint worth of rework.

6. Get cold reviews from other agents

   Open a fresh pairing session in a new terminal — no context from your first session. Ask the fresh agent to review the document as if it were about to decompose it into tasks:

   Review this goal document as if you were an agent about to decompose it into tasks.
   Flag anything ambiguous, missing, or that would force you to guess.
   

   Liza’s contract makes agents accountable: they raise concerns rather than praise a document that is not ready. Address the feedback and iterate until the reviewer approves.

   If you have subscriptions to multiple model providers, use a different provider for the cold review. Diversity in model perspective surfaces different blind spots and produces a more robust goal document.

7. Final pass with /systemic-thinking

   Run a final review using the systemic-thinking skill:

   /systemic-thinking path/to/your-goal.md
   

   This skill examines the document for systemic gaps — assumptions that propagate through the design, missing feedback loops, and risks that interact with each other in non-obvious ways.

8. Initialize the project

   Pass the finished goal document to liza init:

   liza init "Your goal description" --spec path/to/your-goal.md
   

   The orchestrator uses this document as the authoritative source for task decomposition. Every planning task agents produce traces back to it.

​

What the Vision Template Looks Like

The templates/vision-template.md file provides a skeleton with all required sections pre-populated with guiding prompts. Its structure maps directly to the sections described above:

# Goal: [Project Name]

## Problem Statement
<!-- What problem exists today, with evidence -->

## Target Users
<!-- Who benefits and what they need -->

## Solution Overview
<!-- Key concepts, main flows, and design decisions -->

## MVP Scope
- [ ] Capability 1
- [ ] Capability 2
- [ ] Capability 3

## Explicit Out of Scope
- Feature X (reason)
- Feature Y (reason)

## General Specification
### [Capability Name]
- Inputs: ...
- Outputs: ...
- Rules: ...
- Edge cases: ...

## Success Criteria
- Criterion 1
- Criterion 2

## Risks & Assumptions
- Risk: ... / Mitigation: ...
- Assumption: ... / Validation: ...

Use the template as a checklist, not a rigid format. Add sub-sections wherever a capability needs more detail. The goal is completeness, not adherence to a structure.

​

The Core Rule

Agents make implementation choices; product decisions live in the goal document. If a decision is missing from the document, agents either guess (badly) or block waiting for clarification. Every product decision — what to build, for whom, how it behaves, what is out of scope — belongs in the goal document before you run liza init.