> ## Documentation Index > Fetch the complete documentation index at: https://lizamas.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # 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 > [card] 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. > [card] 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. > [card] 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. > [card] Drift prevention > > Any drift in the goal document compounds during decomposition. A single ambiguous sentence can produce multiple tasks pointing in different directions. > [!WARNING] > > 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: ```text theme={null} 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: ```text theme={null} 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 > [!WARNING] > > 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: ```text theme={null} 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. > [!TIP] > > 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: ```bash theme={null} /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`: ```bash theme={null} 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: ```markdown theme={null} # Goal: [Project Name] ## Problem Statement ## Target Users ## Solution Overview ## 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 > [!NOTE] > > **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`. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.