A plan in a markdown file
Your team sees it. Your agent does not.
It sits in the repo, reviewed and current — and every session still starts with you pasting it into the prompt again.
Plan your projectand manage agentson the go.
Put tasks on your board. Your AI agent picks them up, writes the code, tests it and sends you an update. You review and approve right from your phone.
cawdev is not open to everyone yet. We are letting in a few teams at a time so we can fix things properly with each one.
cawdev · roadmap · cawdev/console
Live on the board, right now
Why cawdev
You wrote the plan down. Your agent still cannot see it.
Every team building with agents keeps the plan somewhere. Both of the usual places cost you something.
A plan in a tracker
A nice board your agent cannot use.
People can read it, so the plan is at least somewhere real. Your agent gets an API and a login that were never meant for it.
Either way
No record of the work.
Nothing tracks which session touched what, what it asked you, or what it changed. It all disappears when the terminal closes.
cawdev keeps one plan that your team and your agents both read.
How it works
From idea to shipped, without repeating yourself.
Five steps. The card is the unit of work in every one of them.
- 01
Write the card
Add what you want built to the board — or file what is broken, with a severity. Type it yourself, or describe it in a sentence and let an agent draft it for you to edit.
Considering → Planned → In development → Merged → Shipped
- 02
Hand it to your agent
Connect your agent to the board once per repo. From then on it can read the board, pick up a card, comment on it and move it along.
One entry in .mcp.json — nothing to install
- 03
Press start
The work runs on your own machine, in its own copy of the repo. Start several cards at once and say up front whether they share a branch in order or take one each in parallel.
A fresh workspace for every run
- 04
Answer, do not babysit
It stops and asks whenever it needs a decision — starting with the plan, before any code exists. It waits for you rather than guessing.
Allow once · for this session · for the project
- 05
Say whether it is done
The finished branch waits to be read. Done, or not done with a note — which the next session is handed as the thing to fix, rather than a card to build again from scratch.
The one status no machine can supply
Away from the desk
The work runs on your machine. You do not have to be at it.
A run that needs a person stops and waits. Waiting is all it does — so the answer can come an hour later, from a train, from a phone.
09:41
cawdev · runslive
R84 · cawdev/console · 4m
Plan · waits for you
Plan ready — three steps, no code written yet.
- 1NOT_DONE joins the status enum
- 2Migration, then the guard that reads it
- 3The board column, and its count
Send it backAgree
2 more runs waiting on you
Before
Start it from wherever you thought of it
Describe what you want built in a sentence and let an agent draft the card. Edit it, pick the branch, press start. The machine that does the work is at home; you are not.
During
Answer what it asks
The plan to agree, the command to allow, the question only you can settle. Each one is a thing to tap, not a terminal to go and find.
During
Read the session as it goes
The same live transcript, streaming. Type to the agent mid-run if it is heading the wrong way, or stop it.
After
Say whether it is done
Read what came back on the branch, then mark it done or send it back with a note. The one status no machine can supply, and it takes a thumb.
Inside a run
What your agent knows, and what it cannot do.
A run is a sequence, not one long conversation. Every stage is yours to turn off, and any of them can stop and wait for a person — wherever that person happens to be.
The default, per project. Turn a stage off, or make any of them wait for you.
It reads the brief first
A session is handed what the project is before it starts: what each part is responsible for, the words your code uses, and the traps. A session interviews you and writes it once.
docs/brief/ — a file in your repo, not a field in ours
Your rules reach the sessions they apply to
Write “never edit the generated files by hand” once. A session refactoring the exporter is told. A session fixing a button is not.
Refactoring · Testing · UI · Security · Performance · Docs
You read the plan before there is any code
The first stage writes a plan and stops. Agree with it, or send it back — while sending it back still costs nothing.
A plan you can point at, not three paragraphs in a transcript
A second check, on the machine, at the call
Permissions decide whether a command may run. This reads what comes back. A private key on its way into a transcript, or an rm -rf outside the checkout, stops and asks you.
Stopped, not failed — the run waits for your answer
What you get
The same board, for different reasons.
Pick the one that sounds like you.
Stop re-explaining the plan every session.
You already wrote down what to build. Your agent should just read it.
- The card is the prompt
- Your agent pulls the card, its status and the thinking behind it. Nothing to paste, and nothing that went stale last week.
- It runs on your machine
- Sessions work in your own checkout with your own credentials. cawdev never clones your repo and never holds a git login.
- It picks up where it stopped
- A session that runs out of context writes down where the work got to, and the next one on that branch is handed it. A run that fails carries on from the workspace it already had.
- Terminal, browser, or the phone in your pocket
- One command shows every session on the machine, in your own scrollback, and lets you answer one — or split into a window each, roadmap on top, when you have several going. The console does the same job in a browser, and fits on a phone.
Five repos, or fifty. One place to look.
A board per project, and no ceremony piled on top of it.
- Every project in one place
- Each project points at a repo and has its own board and its own people. One install covers all of them.
- One page for what is waiting
- Planned, broken and in flight, per project and across all of them, with the projects that need you first. Every number opens the board it came from, on a laptop or on a phone.
- Release notes you did not write
- The changelog is built from what actually shipped, grouped by release and in the right order. No more writing it the night before.
- The same reviewers on every repo
- Turn on the experts a project should have, and every session gets them — a coding run has a reviewer, a question does not. They arrive from the runner rather than the checkout, so a repository cannot add to what a run may do.
Agent work you can account for.
Who asked for what, who approved it, and what changed — all written down.
- It stays on your infrastructure
- The board, the database and the sessions all run inside your own network, next to the code they work on. An agent reaches only what its owner can reach right now.
- Approval before the work, not only after
- A project decides which stages of a run stop for a person, whether a run opens a pull request, and whether anything reaches the main branch unread. Whoever has to approve does it from whatever screen they have.
- Secrets do not reach the transcript
- A check on your own machine reads what each tool call returns, and a key or a token on its way into a stored transcript stops and asks. Destructive commands stop the same way.
- Nothing is quietly deleted
- Cards and comments are never removed, and turning an idea down takes a written reason. Every run stays on its card, under the name of whoever started it.
In the console
Built for the part where the agent is working.
Not a dashboard you check afterwards. It is where the work happens.
Watch the session live
Every run, streaming as it goes. Read what the agent is doing, type to it mid-run, or stop it — from your own terminal, from the console, or from the console on a phone.
Questions reach a person
The agent’s question goes to whoever started the run, and waits on whatever screen they open next. Answer a dozen at once as one form, or pass one on.
Permissions that fit
Allow a tool once, for the rest of the session, or for the whole project. Not one big switch.
Reviewers you chose
One word asks every reviewer the project turned on about the same diff, and returns one report — grouped by what was found rather than by who found it.
Docs that stay true
ROADMAP.md, CHANGELOG.md and ISSUES.md are generated from the board, and cawdev tells you when the files have drifted.
Straight answers
The questions you were going to ask anyway.
Only if you are in the beta. We are running with a small number of teams on purpose — few enough that we can sit with each one, watch where it breaks, and fix it before the next team arrives. Ask for a spot and we will tell you where the queue stands.
By fit, not by order. We take teams already running coding agents daily with a real backlog to point them at, and we keep the group small enough to support properly. Tell us what you are building and you will hear back either way.
Nothing during the beta. There is no card to enter and no trial clock. We will never resell your model usage either — you bring your own agent subscription, and those tokens stay billed to you.
No. You keep your repo, your editor and your agent — and your tracker, if you have one. cawdev is where agent work is directed and recorded, not where the company plans its quarter.
On your own machines. The board and its database sit on your infrastructure, and runs happen in a copy of your own checkout with your own git credentials, so cawdev never needs a git login. There is no hosted version yet.
Not yet — it is being built. What works today is the console itself: it is a web page that lays out at any width, so a phone browser gets the board, the live sessions and every question waiting on you. Your board runs on your own network, so reaching it from outside is however you reach any other internal tool.
Claude Code, Codex CLI and Antigravity — pick one per machine, or run a different agent in each window when you have several sessions open. You choose the model and how hard it thinks for each run, with a default per person.
Three things. Anything outside what you have allowed stops and asks you first. Each machine carries its own ceiling of what may ever run unattended, and no project rule can widen it. And a check on that machine reads what comes back, so a secret in the output or an rm -rf outside the checkout stops too.
It stays yours. Your data lives in your own database, and the roadmap and changelog are ordinary markdown files in your repo. Nothing is locked in a format only we can read.
Limited beta
Ask for a spot in the beta.
cawdev is open to a small number of teams at a time. Tell us what you are building and who is building it, and we will get back to you when the next spot opens.