The Core Loop

TL;DR

Refine an idea through an Intake Session or place a complete GitHub Issue on the Frontier. The Dispatcher selects the work, the Runtime edits and tests the code, and the Dispatcher pushes the committed changes and opens a Pull Request. If implementation needs a decision, a Clarification asks you before work continues.

The core loop is idea → Issues → code → Pull Request. You decide how an idea enters the loop. Zozo then prepares an isolated checkout, runs the coding agent, verifies the project, and turns the committed result into a Pull Request.

Idea → Issues → Code → Pull Request

1. Bring an idea. Start with a feature in plain terms. It can be an early idea or a fully specified GitHub Issue.
2. Make the work ready. Use an Intake Session to refine an early idea into an Issue Plan, then confirm it so the Dispatcher can Publish the plan as GitHub Issues. For an existing, complete Issue, add the ready-for-agent label yourself. Either route places ready work on the Frontier.
3. Select an Issue. Auto-dispatch watches your active Projects, applies eligibility and pacing rules, and selects an Issue when capacity is available. You can also start a targeted Dispatch for one named Issue.
4. Implement the change. The Dispatcher creates a Managed Worktree, an isolated checkout and branch for the attempt. It opens a Thread and starts a Run. The Provider launches its Runtime in that worktree. The selected Credential supplies the billing identity, model, and effort for that new Thread. The coding agent reads the Issue and repository, edits the files, runs the project's build and tests, and commits the completed implementation.
5. Open the Pull Request. After the Run completes with committed changes, the Dispatcher pushes the branch and opens a Pull Request that closes the Issue. The Runtime handles the code; the Dispatcher owns the GitHub branch, Pull Request, and label changes.
6. Review or land it. With open-PR-only, the Pull Request waits for your review. With auto-merge, it enters Landing, which verifies the tested commit against the Pull Request's target branch before merging it. See Watch a Project for both merge policies.

When Landing needs an agent to repair conflicts or failing checks, its authorization and separate conflict and checks repair limits survive a restart and a move to a fallback Credential. A usage limit continues the same repair without spending a repair attempt. Stop prevents automatic continuation, including while the Landing waits for a Credential or capacity. Retry landing grants fresh authorization after a stop or terminal block and reports whether the result is running, waiting, or queued. Repeated retries while work is active don't start another repair or reset either repair limit.

Deleting a repair Run or Thread removes its conversation history, but doesn't revoke an authorized Landing. Zozo can reconstruct the repair from the existing Issue, Pull Request, branch, Base Branch, and surviving Workspace. It verifies that the old repair has stopped writing first and tells the new repair agent which history is missing. If those facts or the preservation of local work can't be established, the Landing stays blocked and records the specific obstacle instead of starting over.

An Issue can enter Clarification during implementation when a load-bearing decision is missing. The same Thread continues after you answer.

Stage a Batch Before Main

Confirm CI runs against the staging branch first

Many repositories run Pull Request workflows only when the target is the default branch, or configure required checks only there. A Pull Request that targets staging may report no checks at all. Every Landing then waits for the full checks window and blocks. Zozo can't distinguish checks that never report from checks that are merely slow, so confirm that CI runs on Pull Requests targeting staging before changing the Project's Base Branch.

After CI is ready, create a staging branch from main. Open Projects in the Dashboard, enter staging in that Project's Base Branch field, and leave auto-merge enabled. New Managed Worktrees start from staging, their Pull Requests target staging, and Landing merges each verified change into staging.

Zozo closes each Issue itself when its Landing succeeds and leaves a comment naming the branch it landed on. GitHub only closes an Issue when a Pull Request merges into the default branch, so on staging Zozo's close is what lets the Issues blocked on it move to ready-for-agent.

Verify the completed batch on staging, then merge staging into main by hand. Changing the Base Branch affects future attempts only. An open Pull Request keeps the target it already records, so a settings change can't retarget work that's waiting in the Landing Queue.

A newly added Project stores GitHub's current default branch as a concrete Base Branch. A Project saved by an older Zozo version keeps its legacy main fallback until you select Resolve from GitHub or enter and save a branch yourself. Zozo verifies that a saved branch exists on GitHub and refuses the save when GitHub can't be reached.

Two Ways In

There are two ways to place work on the Frontier. Intake is the recommended path for an idea that still needs refinement. Manual labelling is the direct path for an Issue that's already complete.

Intake: The Recommended On-Ramp

An Intake Session is a read-only, human-driven conversation in the Dashboard. You describe the idea, then choose an Intake Mode that determines whether the Agent makes the decisions, grills you for them, or organizes them in a Wayfinder Map. You review the resulting Issue Plan containing the proposed Issues, labels, and dependencies before anything is Published.

When you confirm the plan, the Dispatcher Publishes it to the Project. It creates the GitHub Issues in dependency order and places the ready ones on the Frontier. The Intake Session can read your Project, but it doesn't modify the repository or generate implementation code.

Use Intake when the idea still has open questions. You can answer in real time or resume later from the Dashboard's Needs Attention page. Resolving missing requirements before Dispatch reduces avoidable rework during implementation. See Choose an Intake Mode to compare Small, Medium, Large, and the two Grilling Styles before you start.

The Intake interview format is adapted from Matt Pocock's MIT-licensed grill-with-docs skill.

When a screen's look or behavior is easier to judge than to describe, start a Prototyping Session first. It builds a live Prototype you revise by prompt, then hands off into an Intake Session carrying the brief, the Prototype, and a digest of your Revisions.

Label It Yourself: Direct Entry

If you already know exactly what you want, write the GitHub Issue and add the ready-for-agent label. This places it on the Frontier, where the Dispatcher can select it during the next eligible Dispatch.

Use this route for Issues that already contain the requirements and acceptance criteria the coding agent needs. Start with Intake when the idea still needs refinement.

See Watch a Project for the labelling steps and Label Reference for the labels read by the Dispatcher and Dashboard.

Clarification: It Asks Instead of Guessing

Sometimes an Issue that looked ready is missing a load-bearing decision. If the answer isn't available in the Issue, documentation, or codebase, the implementation attempt enters Clarification and asks you for the missing information.

Clarification stays on the same Thread and preserves the work already completed in its Managed Worktree. The agent asks one question at a time until it has what it needs and ends its turn with a Declared Understanding in a clarification-resolved block. The Dispatcher records your answers and that summary, then resumes implementation on the same Thread under normal dispatch admission without an acknowledgement click.

While Clarification waits, the Issue appears on the Dashboard's Needs Attention page. Questions wait indefinitely for your answers. A reply with neither a question block nor a valid Declared Understanding stays parked with its last message and composer so you can reply again.

You can also redirect a Clarification reply while it's running, the same way you can redirect a dispatched Issue attempt. See Redirect an Intake, Clarification, or Wayfinder Ticket Session for how delivery works. Objective conflicts require explicit adoption of the revised objective before implementation can resume.

Related

• How Dispatch Decides: learn the three Auto-dispatch triggers, selection order, admission priority, and stop conditions.
• Choose an Intake Mode: choose Small, Medium, or Large and set the Grilling Style for a conversation.
• Work Model: follow the code-to-Pull Request path and understand how concurrent work is bounded.
• Watch a Project: add a Project, label an Issue, choose a merge policy, and configure its Base Branch.
• Label Reference: look up the label vocabulary, promotion vetoes, and meaning of blocked.
• Core Concepts: review the Provider, Runtime, Thread, Run, and Event vocabulary.
• Prototyping Sessions: build and revise a live Prototype before an Intake Session plans the implementation.