For Every Role

AI coding agents can take on more of the implementation work. People still decide what should be built, weigh tradeoffs, check results, and carry the reasoning forward. The same workflow serves solo founders building with AI agents and product teams where architects, developers, product managers, analysts and stakeholders share the work.

The Workflow

Everything on an app board follows the same three steps.

Understand. The board is a current map built from the code itself. It contains systems, connections, aspects extracted from the repo, and insights from analysis.

Plan. Decide what should change and write it as a work item: a living spec anchored to the elements it concerns. It can start as an outcome ("customers can download past invoices"), a concrete technical change, an insight, a captured board edit or a plugin filing. Each joins the same queue.

Evolve. Developers pull that queue into their coding session with /work-items, implement the change, and run /sync. The sync updates the board and verifies the work item's structural claims against the repo.

Use the section below that matches how you work.

Solo Founders

You usually start with a product direction, a repo, and AI agents helping with implementation. Map the repo with the code plugin, write product bets as work items, and pull those work items into your coding session. When an agent changes code, run /sync: the board records what changed, and the work item records why.

Product Teams

On a product team, each role starts somewhere different, and all of them use one board, one queue and one verification loop.

Architects

You usually start with the map. Draw the system landscape and add a layer per system, or let the workspace plugin or chat create it. The Hands-On path and the Plugin or Chat path cover both ways.

Then define the vocabulary. Archetypes define what a node is. Context tags define where it belongs. Together they make the landscape queryable: "every gateway in the identity domain", "services with no owning team".

Day to day, you read the canvas, aspects such as database schema and API surface, and insights. You also author work items. For cross-service work, the work item editor finds elements on any board from Add elements. A work item changes one app and links the others as references; a change another app needs gets its own work item there.

Use the workspace plugin for work too large for chat: adopting a decision across apps, running a structured review, or working through a folder of RFCs.

Developers

You usually start inside your coding session. Open the service board and read its consumers, dependencies, and data stores before changing code (Boards Guide). To see a change's blast radius, open an insight's traced path in the Insights Bar. An analysis starts from chat or /insights.

You can then work the queue from the repo:

• /work-items pulls handed-off work items into your session with their anchors and instructions. You claim, implement, verify, and resolve them.
• /skills compiles this app's compiled skills into the repo, so conventions and operating knowledge arrive as files.
• /sync sends the change back to the board and verifies structural work items, including yours and anyone else's.

The code plugin lists every command and flag.

Product Managers and Business Analysts

You can start from outcomes without using technical vocabulary.

Write what should become true in the work item editor. Open it with Create work item on the Work items screen or the hub's work items card. Right-click a system to open it with that system already anchored.

Add the systems and screens involved: select one on the canvas and choose Add to work item on its toolbar, or find it in the editor's Add elements list. Describe what should happen in plain language; anchors attach without file names. The optional Why field keeps the problem, the goal and what is out of scope, when that reasoning is worth keeping.

Hand off the work item and follow it on the Work items screen, where the stage band counts work items from Draft and Handed off to Completed. When work comes back, read the resolution note.

You can also draft work items in chat from insights, a bound PRD, or a page or Jira epic you've connected. If your team tracks work in Jira, Send to Jira turns a work item into a linked issue.

Stakeholders

Some people only need to read the board. Publish it, and they can open a read-only, interactive URL without an account. Make it public, unlisted, or protected by a token, a password, or both. If they work in Slack, share the board to a channel, or use Automations to post each publish to a channel.

Roles are trust, not titles

Your organization role controls what an account can do, not the kind of work that person does.

A business analyst and a principal engineer can both be editors, with the same authority to author, hand off, and confirm work items. A board can narrow access further: make it private and share it with named people. Permissions & Access explains how organization roles, board access, and published visibility combine.

One review is always required: human over machine. When a plugin run or a chat conversation proposes something, it is created as a draft and waits for a person to hand it off.

What's next