One front door for the exo workflow lifecycle. This skill is a router. It classifies the request into one of three intents, loads the shared substrate, then loads the matching intent recipe and follows it.

Exo is an agent workflow platform. Every intent drives it through an exo MCP server.

Several exo connections coexist normally, one per workspace, sometimes several on one deployment. Enumerate the exo MCP servers this session has before doing anything else.

With exactly one, use it. With more than one, ask which through the structured question tool and stop until the user answers, because a wrong guess writes to the wrong workspace. Do not switch connections partway through an intent. Start over if the target changes.

Call on the chosen server. It confirms the connection and returns the workspace ID. Report that ID so the user can see which workspace they are about to change. If no exo MCP tools are present or fails, read and follow it, then call again. Do not classify an intent until it succeeds.

reaches the same workspace over REST, and it has to reach the same one. It reads , , and from the process environment, falling back to the profile named by , which is the file . Pass with the name of the MCP server you chose on every call, so the two cannot point at different workspaces.

Read . It holds the shared substrate every intent uses: the run-walking read primitives, the DTO discovery discipline, the resource write primitives, the unprobeable nodes, and the note on why the improve intent reads the debug recipe inline rather than invoking it.

intents/debug.md

intents/improve.md

intents/build.md

Pick exactly one. If the request is genuinely ambiguous between intents, ask the user which one in a single question rather than guessing.

Put every question to the user through the harness's structured question tool, whatever it is called here. Free-text prose questions with bullet lists or "Q1/Q2/Q3" prompts are not allowed, even when the question feels open-ended. Bucket open areas into concrete options and let the user type a custom answer instead. Batch related questions into one call so the user answers a structured form rather than a thread of replies. Respect the current limits of the tool you have, and ask directly in prose only when no structured tool is available or the answer is inherently free-form, such as a name, a metric, or a path. This applies to intent disambiguation, the build interrogation in , the proposal and rerun gates in , and any candidate-disambiguation prompt in .

Require an explicit answer at every approval, production write, credential, and rerun gate. Never attach auto-resolution to those questions.

The boundaries between intents are intentional gates, not friction to remove. A build that ends in a first run does not auto-continue into improve, because the user owns when to cross from constructing to iterating. An improve pass that finds a failed run reads the debug walk inline rather than switching intents, because the diagnosis is a sub-procedure of the loop, not a separate request.

All paths in the intent files are relative to this skill's root directory: for executables, for shared docs and templates, for the three recipes. holds per-harness interface metadata that no recipe reads.