Browse docs

← All docs

docs / workflows.md

Workflows

cix ships a set of workflows for running engineering work that outlives a single conversation. They are disciplines your assistant follows, not programs it runs.

They exist because long agent sessions fail in two predictable ways: drift, where the work quietly becomes something other than the task, and unverified done, where success is declared without evidence.

The five

WorkflowFor
The loopExecuting a task through fixed phases with hard gates
ResearchRecording an investigation while it is still open
DesignShaping work with unknowns before any code is written
PlansTracking multi-session, multi-repo work
TidyKnowing what state your repository is actually in

How they fit together

text
cix-research   what is true, and how do we know
      ↓
cix-design     what should be built, and what must stay true
      ↓
cix-todo       in what order, and what is done
      ↓
cix-loop       execute one step at a time, with evidence

Not every task needs all four. A one-line fix needs none of them. The judgement is about matching ceremony to risk: a schema change with three unknowns deserves a design; a typo does not.

cix-tidy sits outside the sequence — it runs at the start and end of a session.

Why the state lives outside the chat

Chat history is a poor memory. It's long, unsearchable, ordered by time rather than topic, and it disappears when the session does.

These workflows write to storage attached to your cix account, so an investigation you start on your laptop is readable next week from another machine, or by an agent session that has no memory of the one that started it.

That last case is the common one, and writing for it costs very little.

What they never do

None of these push, merge, deploy, or release. Those are decisions for the person running the work. A workflow's terminal state is committed and verified locally, with a clear statement of what is done and what comes next.

What you need

Research, design, and plans are stored with your cix account, and that workspace is part of a paid plan. Every paid plan includes it — there is no separate tier for it — and a free account does not have it.

Two consequences worth knowing before you start:

  • Installation is entitlement-checked. cix install --client claude adds the workflow skills only for a signed-in account with an active plan. If it cannot confirm one, it says so in a line and installs the rest of cix normally.
  • A refusal never deletes anything. If a plan lapses, stored research, designs, and plans stay exactly as they are and become readable again as soon as the plan is active. A refusal names the next step rather than failing generically.

The loop and tidy are disciplines rather than stored state, so they need no account on their own. The loop does write to research, design, and plans as it runs, so a full loop uses the workspace even though the discipline itself is local.

Client support today

The workflow skills install for Claude Code and Cursor. Codex and Gemini get the rest of cix — the index, the MCP server, and the editor integration — but not these skills yet.

cix-plan, which manages a plan by delegating each step to a separate agent, is not part of this release. It depends on a subagent runtime that cix does not ship, so no workflow here refers to it.

Both are statements about this release, not permanent boundaries.

Next: The loop.