Last updated July 5, 2026
Intents
An intent is a work item you author on the board and a developer implements in the repo. It's how architectural decisions stop being screenshots in Slack: you propose a change anchored to real board elements, approve it, and it flows into a coding session through Cdx Code. When the code actually changes, the board tells you — mechanically, not on trust.
Intents live on app boards: the hub leads with them, and the Intents panel on the canvas holds the full queue.
Where intents come from
The main path. An analysis or a /monitor run lands findings on the board; you review them and promote the ones that deserve action. Each promoted finding becomes one intent carrying its origin — so a production signal traces all the way to the commit that fixed it. See Insights.
That last one surprises people once, in a good way: on a governed board your structural edit didn't vanish — it became a proposal in the Intents panel, waiting to be implemented in the repo.
The lifecycle
| Status | What it means |
|---|---|
| Draft | You're still shaping it. Invisible to developers. |
| Open | You hit Lock & open — the intent is locked and visible to /intents pulls. |
| Assigned | Handed to specific people. |
| In progress | A developer claimed it — single-winner, so two sessions can't duplicate work. |
| Implemented | The developer resolved it as done, with a note and usually a commit or PR link. |
| Rejected / Resolved | Declined with a reason, or overtaken by events. |
The gate that matters is draft → open. Until you lock an intent, it's a sketch; the moment you open it, it's a commitment developers will pick up. The hub's intents card surfaces exactly this — N await your approval — with the lock action inline.
Trust, then verify
Two badges tell you how much to believe an intent's status:
- Verified — the developer claimed implemented, and a later
/syncpush matched the proposed change. The board proved it; this isn't self-reporting. - Stale — the board moved underneath a waiting intent (the anchored elements changed since you wrote it). Re-review before anyone implements against an outdated picture.
Working the queue
The Intents panel groups the queue by status. On a root board's command center you see every app's counts in one place, plus an All layers scope inside the panel for the whole board tree.
From either place you can:
- Lock & open a draft, or reject it
- Assign open intents to specific developers
- Open the detail view — the directive, the proposed changes, anchors that highlight on the diagram, and the resolution note when it comes back
The developer side
Developers don't visit the portal to pick up work. In their coding session, /intents pulls the open queue for the bound repo, claims an item, implements it against the directive, verifies with the project's own checks, and resolves — and the resolution flows back to your board. The full flow lives in the plugins guide.
The loop closes on its own: /monitor finds a production signal → you promote it to an intent → a developer implements → /sync verifies → the next /monitor run shows the signal gone.