mana
Mana is a local-first coordination system for AI coding agents. It turns work into durable Markdown records with clear scope, dependencies, verification gates, attempts, notes, and facts.
Use it when agent work needs to survive beyond one chat session: planning, delegation, retries, handoffs, audits, and multi-step implementation.
Why mana
Coding agents are effective, but their default working medium is fragile:
- plans live in prompts or ad hoc Markdown files
- “done” is ambiguous
- retries restart without context
- dependencies stay implicit
- useful failures disappear into logs
Mana gives that work a durable shape:
- tasks describe executable work
- epics organize larger efforts
- verify gates define completion
- dependencies encode order
- attempts and notes preserve execution history
- facts capture verified project memory
Everything lives in .mana/ as plain files, so the system is inspectable, git-friendly, local-first, and usable by any agent that can read files and run shell commands.
Installation
Build from source:
Quick start
Initialize mana in a project:
Create a task with a verify gate:
Inspect the queue:
Work the task manually or hand it to an agent:
# make changes
If you use an agent runtime, configure it once and dispatch through mana:
[!TIP] Prefer targeted verify commands.
cargo test parser::handles_unicodeis usually a better task gate than a broad project-wide test suite.
Core concepts
Task
A task is one executable unit of work. It should have a concrete goal, useful context, relevant paths, and a verify command that exits 0 when the task is complete.
Epic
An epic is a non-dispatchable parent for larger work. Use epics for features, migrations, audits, and refactors that need decomposition before execution.
Fact
A fact is verified project knowledge. Facts are useful for architecture notes, environment requirements, and constraints that agents should not rediscover repeatedly.
Verify gate
A verify gate is a shell command attached to a task. mana close <id> runs the command before closing the task. If it fails, the task stays open and the failure is recorded for the next attempt.
How it works
Mana stores records in .mana/:
.mana/
├── config.yaml
├── index.yaml
├── 1-add-csv-export.md
├── 2-improve-errors.md
├── 2.1-add-error-type.md
└── archive/2026/04/
A task is a Markdown file with YAML frontmatter:
---
id: "1"
title: Add CSV export
kind: task
status: open
verify: cargo test csv::export
paths:
- crates/app/src/export.rs
- crates/app/tests/export.rs
---
Add a `--format csv` option to the export command.
Acceptance:
- existing JSON export behavior is unchanged
- CSV output includes headers
- `cargo test csv::export` passes
The normal loop is:
- define the work as a task
- claim or dispatch it
- attempt the implementation
- run the verify gate
- close on success, or record failure context and retry
Working with agents
Mana is agent-agnostic. Any runtime can work from mana as long as it can read files and run commands.
Configure command templates with {id} placeholders:
Useful commands while agents are working:
mana context <id> is the agent handoff surface. It assembles the unit spec, prior attempts, dependencies, project rules, and relevant files into one briefing.
Planning and decomposition
Use epics and child tasks when work is too broad for one safe attempt:
Dependencies can be explicit:
Or artifact-based:
Sequential work can be chained:
Fail-first checks
By default, mana expects a task’s verify command to fail when the task is created. This prevents creating tasks whose completion check already passes.
Use --pass-ok for refactors, documentation, cleanup, or safety checks where the command may already pass:
Command overview
# lifecycle
# graph and queue
# dependencies and memory
# agents and context
# maintenance and integration
See command-specific help for options and examples:
Pipe-friendly usage
|
|
|
|
Configuration
Project configuration lives in .mana/config.yaml. Global configuration lives under the user mana config directory.
Common settings:
| Key | Description |
|---|---|
run |
Agent command template for task execution. {id} is replaced with the unit ID. |
plan |
Agent command template for decomposing larger work. |
run_model |
Default model for run-compatible agent flows. |
plan_model |
Default model for planning flows. |
review_model |
Default model for review flows. |
max_concurrent |
Maximum parallel agents. |
max_loops |
Maximum run-loop cycles before stopping. |
verify_timeout |
Default verify timeout in seconds. |
rules_file |
Rules file included in mana context. |
file_locking |
Avoid scheduling concurrent tasks with overlapping paths. |
batch_verify |
Run shared verify commands once after agents complete. |
auto_close_parent |
Close parent units when all children are closed. |
auto_commit |
Commit changes when a unit closes. |
on_close / on_fail |
Hook templates for close and failure events. |
[!WARNING] Do not store secrets in mana config or unit files. Use environment variables or your agent/runtime’s secret mechanism.
MCP integration
Mana includes an MCP server for IDE and agent integrations:
The MCP surface exposes project status, unit context, tree views, and common unit operations to compatible clients.
Development
The workspace contains:
crates/mana-core- durable model, operations, config, index, graph, verificationcrates/mana-cli- CLI commands, output, MCP server, runtime adapters
Documentation
mana --help- command groups and examplesmana <command> --help- detailed command helpCONTRIBUTING.md- contribution workflowCHANGELOG.md- release history