Because every phase and transition lives in YAML under .accordo/workflows/, a process that goes wrong is edited rather than re-prompted, and the same definition applies to every agent that connects. project_config.md is the part worth filling in early: it is where the workflow learns your test and lint commands, which is what turns generic phase guidance into steps that actually run in your repository.
A workflow engine for coding agents. Workflows are YAML files rather than code, so what the agent is told to do next comes from a schema you can read and edit — and when no existing workflow fits, the agent is walked through writing one.
- Workflows discovered on the server side from the project's workflow directory, with their actual content handed to the agent so it can choose the one that matches the task
- Guidance driven entirely by the chosen YAML schema — the next phase, and the criteria for moving to it, come from the definition rather than from anything hardcoded
- Workflow state read and updated as the run progresses, so a long task has a record of where it is instead of relying on the conversation
- Session cache management, which is what lets a workflow survive a restart of the server
- Semantic search over past workflow contexts, returning the raw findings for the agent to judge rather than a pre-filtered summary
- Guidance for authoring a new YAML workflow — structure, fields and complexity level — for tasks no existing workflow covers
Uv on the machine; it starts as uvx accordo-workflow-mcp. The project gets an .accordo/ directory: workflows/ holds your YAML files, sessions/ holds workflow state, and project_config.md carries the project's own test, lint, build and deploy commands, which workflows read to know how to run things here. Read and write access is needed inside the project directory and nowhere else. A companion CLI, installed by the project's install.sh, configures MCP clients and deploys the workflow rules to them. MIT.
One command — uvx accordo-workflow-mcp