Outcome. The request reaches the end state its shape calls for, produced by the Compound Engineering skill whose job that is, with everything unresolved recorded where the user will see it. Most requests end with that skill's result and no branch. A change to the code is the one shape with more steps of its own: it ends in an open pull request whose URL you hold, with CI decided, after being implemented, simplified, reviewed with the eligible findings applied and the rest recorded, any durable learning captured, committed, and pushed. Merging stays with the user unless they granted it for this run.

Work source. On the routes that change the code, nothing is implemented without a work source verified this run, and only two things qualify: an implementation-ready plan, which ce-work implements; or a fixed return from ce-debug, where the fix is the implementation. The plan is one the session identifies, as references/intake.md defines. Never search the plans directory for a candidate or act on a file you discovered. Never plan from scratch over an existing plan.

Route by what the request is. Match the request to the skill whose job it is; the host's skill list is the catalog. Read references/intake.md before choosing; it alone defines the routes, their precedence, what each child skill is passed, and how each return is read. In short:

A plan path, or a plan ce-plan wrote this session, takes the plan route.
A concrete report of failing or wrong behavior goes to ce-debug; reproducing it is that skill's job, not intake's.
A change that hangs on a judgment the user did not settle goes to ce-pov first, and only a verdict that supports the change continues; a judgment with nothing to build ends at the verdict.
Product shape with more than one plausible reading goes to ce-brainstorm when a human is present, and to ce-plan in pipeline mode when not.
A request whose result is not a code change goes to the skill that owns that result (ce-explain, ce-prototype, ce-pov, ce-ideate, and so on); that invocation is the whole run: return its result and end.
Any other change to the code goes to ce-plan.

When unsure, take the route that asks more of the evidence.

Interaction. Ask the user only through ce-brainstorm, and only when a human is present. Everything else proceeds without waiting: reversible work is done and shown for the user to correct afterward, and only an irreversible action outside what they granted (a merge they did not grant, a force-push, deleting data) stops instead. lfg runs from schedulers, loops, and nested orchestrators. The one other question is the routing disambiguation references/stage-routing.md defines: when the conversation assigns planning or implementation to a model or harness, read that file before routing; it alone carries the carrier strings and the sanitization.

Stop, and say why, when any of these holds: