Everything the engine does, written down

Download the CodyCody engine for your platform, activate it with your license key, and start the two servers your coding agent and browser connect to.

Add the engine to Claude Code, Codex or any MCP client over streamable HTTP, authenticated with an agent token you issue and can revoke.

List the published workflows the engine can run, with the description and input schema each one declares.

Start a workflow instance. The engine runs its own steps until one needs the agent, then returns that step's instruction.

Report the result of the current step and receive the next instruction. The same call completes an instruction, a decision, a shell command, a review and an approval gate.

The current state of one workflow instance — status, current step, and progress through any task list.

List workflow instances, filtered by status or workflow, newest first.

The execution log of one instance — every step started, completed, waited or failed, with the engine's notes.

Cancel a running instance. The reason is recorded in its audit trail.

Rewind an instance to an earlier step when a step was answered wrongly. Rewinds engine state only, and reports what it could not undo.

List the reusable skills on the instance — standalone markdown procedures an agent can fetch and follow.

Fetch a skill's full instructions with every nested skill and instruction-file reference resolved, ready to follow.

A workflow is a directed graph run cooperatively by the engine and an agent. Design for that split — the engine decides what happens next, the agent does the work.

A workflow is one JSON document — name, description, input schema, steps and transitions. The naming rules that templates depend on.

The fourteen step types — what each one's config means, which ones the agent performs, and the contracts the engine enforces around them.

How steps connect, which steps branch, how loops are built, and the labelled transitions that task loops and reviews require.

The {{dotted.path}} syntax that carries input, step results, task data and variables between steps — and the two places it behaves differently.

What publish checks, and what it does not — the runtime failures an author has to prevent by hand.

Reusable prompt content that lives outside workflows — attached to steps, embedded by reference, or fetched by agents directly.

Eight rules for workflows that produce auditable results, terminate, and survive being run by an agent that remembers nothing between steps.

From the Team tier, a coding agent can create, validate and publish workflows through the REST API with its agent token. Without a token the API refuses every request.

A package is a set of published workflows, sub-workflows and instruction files for one job. What ships, and where to read what each one does.

The SDLC package runs a whole software lifecycle as workflows — requirements, architecture, style guide, decomposition, build and test, change, deployment and release.

Run phases 1 to 5 of the SDLC package in order — requirements, solution design, style guide, decomposition, then development and test — and what each one asks of you.

Recover a baseline from code that already ships, retrofit a test suite under a coverage ratchet, fix a bug reproduction-first, and run a change through the impacted phases only.

Run the composed system locally against stubs or live services, provision the hosting environments as infrastructure-as-code, and promote a versioned release with verification and rollback.

Every workflow in the SDLC package with its inputs, outputs and gates, the id conventions and file layout it uses, the shipped Python helpers, and what to do when a run stops.