tags: #help #pipeline
order: 50
description: the list of work, by role

Help: the pipeline¶✎ edit

The pipeline (on your Home, and in the Toolbox) is the project's list of work waiting to be done: ideas you parked, questions for you, and work passed between you, the other members and your AI agents, with a clear separation of roles and permissions: each one does its own part, and you decide where a person has to step in. Tap a box to see what can be done there.

For creator and pro projects: you and your maker¶✎ edit

You and your AI, the Maker (chat): tell it what you want and it builds it; when there's no time now, say "park it" and it goes on the list. The list is the pipeline: each idea or thing to do is an item, new until your AI (or you) takes it, then done. Your AI asks you when it needs a decision, and you can drop anything you don't want. That's all there is to it.

The map at the top of your Pipeline page (creator and pro projects; sample data here): you on the left with what's waiting for you, the pipeline in the middle with its items by status (a pill each: new, in progress, waiting, review), your AI on the right, coloured by what it's doing (as on the Agents page). Tap a part to see its items; How it works comes back here.

For master projects: roles and agents¶✎ edit

Master projects add specialist roles (designer, coder, tester, guardian) and their agents, the Agents page, handovers and the MCP server; see Agents.

A guardian agent watches the changes in its areas and reports what it finds, as items for whoever made the change; it never fixes another role's work (being designed). How to run agents, guardians included: Agents.

The map at the top of your Pipeline page (master projects; sample data here): you, then each role in turn (designer, coder, the tester while it's testing, the guardian), each coloured by what its agent is doing and topped with its items by status; when several agents work in one role, they share its circle: the count inside, a slice of colour for each one's state. On master projects the Agents page lists every agent, whatever its role. Tap a role to see its items (and its agent's).

Every step is on the record¶✎ edit

Nothing an agent or a person does in the pipeline is lost.

Every item keeps its history: who made it and for whom, who took it and when, every status change, every note and answer, who asked for a change (asked by you), and links to what changed. Open any item in the pipeline: its full history is at the bottom of its page. Done and archived items keep their page, so an old item number still opens.
Every step leaves its mark in the documents: a step changes the Spec, the Design, the implementation notes or the tests, and each change gets a changelog line naming the item behind it. Every topic keeps all its versions, with what changed between them: open a topic's History (for example the Spec's, in a project that has one).
So you can always trace a change back: from a line in the spec to the version that brought it in, to the item, to who asked and why. Your agents can do the same, so when something odd creeps in they find where it came from instead of guessing.
Agents can watch the flow for you: background agents such as guardians read what changed every day and report drift or gaps as pipeline items (Agents › guardians), the Agents page shows what each agent is doing right now, and Agent history shows what agents did.

What each role records¶✎ edit

Each role writes down what it did, in the project's documents, not just in a chat, so the next person or agent can pick it up.

Coder:
- Implementation notes: where each feature lives in the code, any test-only switches, and changes to how things run or are deployed.
- Design: an As built note on the feature's section whenever the build settled or changed a detail.
- Tests and routes: design tests marked as passing, what a test really checks where it differs from the text, and routes moved from planned to built.
- Project log: one line per batch of work.
- Pipeline: a closing note on each item, and an item for the designer for every design call the build raised.
Designer:
- Spec: one line per behaviour, each with its code, and a dated line for every decision you made.
- Design: how each feature works, ending with its routes and codes; "Accepted" notes when a build's details are agreed.
- Design tests: written before the code exists, linked to the behaviours they check.
- Help and marketing: the feature's help text and a blurb when it's approved.
- Pipeline: your decisions recorded on each item, items for the coder once you've approved, and approved visual pieces handed over as finished files.
Tester:
- Tests: each design test's status (tested, gap, not built), plus its own acceptance and regression tests.
- Pipeline: an item for every failure, with how to reproduce it, for the role that owns it.
Guardian:
- Pipeline: one review item per topic it checked, with what drifted or is missing and where, even when it found nothing worth fixing.
Maker (your AI on Hero, Creator, Pro):
- Specification: the project's Spec: each app and feature it builds, in your words, and a dated Log of what it built.
- Your project: the pages, flows and sample runs it made, each named after its feature.
- Pipeline: what it parked for later, and a short record of what it built.
Everyone: every change keeps its version in the topic's history, every item keeps its full history, and every agent's work shows in Agent history.

Who does what¶✎ edit

Each role has one job, and they pass work to each other through the pipeline, never around it.

You (and any other member): say what you want, answer questions and approvals, review what's done, decide what ships. You're the only one who moves work to other members or projects; your AI marks things important, drops, promotes or moves them to the to-do list only when you ask.
Maker (your AI, on Hero, Creator and Pro): the do-everything role. Builds what you ask (model, pages, data, fixes), parks what's for later, asks you before risky steps, keeps a short record of what it built.
Designer (Master): turns what you ask into the Spec (what it does), the Design (how it works) and the design tests, and builds approved visual pieces itself. Brings you the calls to make; sends work to the coder once you've approved it; decides the details the coder brings back, asking you when it's yours to decide.
Coder (Master): builds what the designer hands on, runs the design tests with every build, deploys a preview and keeps the implementation notes current. Never changes what a design test checks; sends details the build settled back to the designer as one item.
Tester (Master): owns and runs the design tests, adds its own, and sends failures back as items. Its run is the one that says a feature is done.
Guardian (Master): reads what changed each day in its areas (spec, design, implementation, tests, deployments) and reports drift or gaps as one item per topic, for the role that owns it. It reports; it doesn't fix.
Administrator (a person): looks after the project and the box: levels, members, tokens, permissions, deploys.

How they talk. Work always goes through pipeline items: a role hands an item on, or makes a new one for the next role, with links to what changed. Agents can also leave each other short messages on the Agents page, for information, never orders; they only work with agents of the same person. What waits for you shows first on your Work page (Pro and up) or at the top of the pipeline, and how far agents may go without you is set on the Permissions page.

Sample prompts¶✎ edit

How people drive the pipeline by talking. Put your project's name where it says <project>; more in ExampleAiPrompts.

1. Start a designer

You are the designer on . Work the pipeline.

Answer, roughly: "I took the handover P-63 and closed it. Next for the designer is P-66, design calls from the last build: I'd accept 1–7 as built and write them in; item 8 is a gap, the build lacks something the spec keeps, so I'd make a coder item for it. OK to write these in and send that one on?"

2. Start a coder

You are the coder on . Work the pipeline.

Answer, roughly: "I took the handover and closed it. Building P-72 (important), then P-73 and P-74. Each one: build, run the tests, deploy a preview, update the documents, then the next. Details the build settled go back to the designer as one item."

3. Ask what's open about something

Any other items from the landing page in the pipeline?

Answer, roughly: "No, nothing open: the ladder (P-52), the Master door (P-54) and the shop example (P-75) are all done, and their design calls are closed. The only thing left is a to-do, not an item: the landing as an app you edit as content. Want me to promote it?"

4. What's waiting on me

What's waiting on me? Most important first, with links.

Answer, roughly: "Three things: P-81 needs your call on two details from the last build; P-9, run the memory guards on the box, is yours as administrator; and P-47, the maker role, waits for you to decide what the maker skill holds. The rest is moving without you."

5. Park an idea, and set its priority

Park it for the coder: the Work page should remember my filters. Mark it important.

Answer, roughly: "Parked as P-84 for the coder, marked important (asked by you), so it's taken next. Nothing else changed."

6. Answering a design call The designer asks: "P-81 has two small calls from the build. 1. Drop's check is looser than the other three: an AI has to send askedBy, but d2 doesn't check that it names its own person, as the rule says and the other three do. I'd make drop match, a small fix for the coder. 2. MCP's promote takes the line number as text and d2 turns it into a number; fine, I'll accept it as built. Should I send #1 to the coder?"

Yes, good, do it.

Answer, roughly: "Sent as P-91 for the coder; #2 accepted into the design; P-81 closed."

Tips.

Start a chat by naming its role and "work the pipeline".
"Park it" makes an item and parks it, instead of doing the work now.
Ask for links, so you can open each item.
Say "mark it important" (or "drop it", "demote it to a to-do") and your AI does it for you, recorded as asked by you (PIPE-37).
New work for the coder waits for your review unless your Permissions say otherwise.

Parking an idea¶✎ edit

Say "park it" to your AI about an idea and it becomes an item for you, parked (never picked until you unpark it), with your words at the top of its document. You can also make one from the Pipeline page (New item). An item has a title, who it's from and who it's for (a role, and a person), a kind (question, design, code, test, handover…) and a document that grows as people and agents work on it.

From → for, and who took it¶✎ edit

Each row shows who → whom: the role that made it and the role it's for, with a name when it's for someone else. Opening an item shows its document, where it came from, who took it and when, and its history. The items you have to act on yourself (for you, waiting on your answer, or an approval) stand out in the list and come first; your agents' items don't.

Taking, statuses and Done¶✎ edit

Take it makes an item yours and puts it in progress. Set its status as the work goes (pending, waiting, waiting on someone's input, done) or press Done. Your own items have a ✓ on their row in the list: one tap closes it, and Undo puts it back for a few seconds. Only the person an item is for, or their AI for one of their agent roles, takes and finishes it. Taken something you can't finish now? Put down (beside the status on the item's page, or POST /api/v2/pipeline/<id>/putdown {note?}) releases it: it's new again with no taker, so it can be picked up or parked. Its taker or its person may put it down; anyone else makes a follow-up.

Important items¶✎ edit

Tick an item's Important box (on the list or the item's page) and it goes to the top of the list, and your agents take it before anything else for their role. You mark items important, or your AI does when you ask it to; agents see the ★.

List, table or board¶✎ edit

Switch at the right of the line above the filters. List (the default): a card per item; on your own items a bar with ✓ Close and ↩ Return; an item in review for you shows ✓ Accept and ↩ Send back instead (in every view, whoever worked on it), and an approval ✓ Approve and ✕ Refuse, never a plain Close; and ⤒ ↑ ↓ ⤓ on items an agent could take next. Table: the compact rows. Board: a column per stage (New, In progress, Waiting, Review, Done for the last week), each with its count; on a phone, one column per screen, swiped. Your last choice is remembered in this browser; a link with ?view= wins. Mine | All narrows any of them to your items.

The row menu: the ⋯ at the right end of a row opens what else you may do with that item: Pause ⏸ it or Resume it, Park Ⓟ it (on hold, out of the pick order) or Unpark it, and Demote to a to-do (pro and master; type the topic, ToDo:PROJECT if you leave it empty). On a phone the ⤒ ↑ ↓ ⤓ live in this menu too, and the ✓ stays on the row. An item in progress can't be parked from here: its taker puts it down first.

What collides with what¶✎ edit

When agents work in parallel, each item can say what it touches — the files and topics it changes — and every open row carries one quiet chip after its size, so you can see at a glance what is safe to start beside what:

conflicts(3-7) — it changes the same files as 3 items already in progress, 7 files between them. Hover it (or tap it on a phone) for the items and the files.
may collide(2) — 2 items in progress might overlap it, but nobody can tell: one side or both say nothing about what they touch.
no collisions — nothing in progress touches its files.

A line above the list adds them up: 5 items with conflicts · 11 files. Only files count: two items that both write Design are not a conflict, because a topic is saved as a draft that d2 versions and merges, while a file is merged in git by whoever gets there second. A conflict is never a refusal — it is a fact for whoever decides what to run next, and two items that touch the same files are often better given to one agent than held apart.

Editing an item¶✎ edit

Edit on an item's page opens it in the same editor as a topic: a small front matter of its fields — title, kind, who it's for, size, important, rank, feature, touches, waitsOn, links — over its document. Save checks every field the way the API does, and a bad line is refused with the line named and nothing saved, so a mistyped size never leaves half a save behind.

What a save can't touch is shown greyed above the editor and changes only through its own buttons: its id, its status (the buttons and Pause/Park move that), who it's from, its taker and its dates. An item someone has taken is edited by its taker or by the person it's for; anyone else gets New follow-up as usual. Each save adds one history line naming the fields that changed.

Your AI can do the same over the API: GET /api/v2/pipeline/P-12?format=topic gives that text and PUT /api/v2/pipeline/P-12 with Content-Type: text/markdown writes it back.

Pausing: not now, without losing it¶✎ edit

Going away, or want your agents to stop taking new work for a while? Pause a new or pending item from its row's menu or its page, or press Pause all at the top of the list to hold every new and pending item the list is showing — so a list narrowed to one role (?role=coder) holds just that role's queue.

A paused item keeps its row, its rank and its place in the order, sits at the bottom of the live list with a yellow ⏸ Paused chip, and your agents skip it: it's off Next up and out of the pipe map's counts, so a dispatcher whose whole queue is paused goes idle instead of looking for work. Resume (on the row, on the page, or Resume all where Pause all was) puts each item back to exactly the status it had — pending stays pending — in its old order.

Paused is not parked. Parking says not this; pausing says not now. So a parked item has no Pause (it's already out of the way), and Resume all never unparks anything you parked on purpose. Because ⏸ now means pause everywhere, Park's icon is Ⓟ. Items in progress, waiting, or in review are never paused — put an item down first if you want to pause it. Pausing and resuming are yours to do; your AI does it when you ask it to.

The list's order¶✎ edit

Important items first, then what's in progress, then what's yours to act on (it stands out), then the rest, newest change first; then paused items, then the collapsed Parked group; done items last. A follow-up or an item waiting on another sits indented right under it.

Next up: rank, size and batches¶✎ edit

Open a role (tap it on the map, or Next up on its view) to see what its agent will take, in that order, numbered. Move an item with ↑ ↓, or send it to either end with ⤒ and ⤓; a handover and important items always come first, so ⤒ is the top of the ranked ones. Each item has a size (S, M, L; change it on its page): an agent that takes a small item also takes the small ones right after it, up to five, marked taken together.

Review, to look at, and return¶✎ edit

When an agent finishes an item, your project's Finish an item setting (on the Permissions page, by the item's size) decides what happens. Asks: it waits in review for you: Accept it (what waits on it starts now) or Send back with a note (it reopens for the same agent). Tells: it's done at once and goes on your to look at list (the N to look at › line above the list): mark it ✓ Seen, or ↩ Send back with a note, whenever you have a moment; nothing there holds anything up. Pro's default: small items go straight through, bigger ones wait.

Review with a comment: at the bottom of an item in review, after its document, Accept with a comment and Send back with a comment open an editor right there. Accept with a comment means "done, if…": the item goes back to the agent that finished it, which resolves your comment and closes it (saying how), or brings it back to your review with its questions. Send back with a comment means it isn't right yet: whatever the Finish setting says, the agent's next finish comes back to your review (the item says comes back to you). The row's ↩ Send back takes you there with the editor open. An agent with questions may also ask up its chain instead of you: a coder, tester or guardian asks the designer, the designer asks you; the item waits on the question until it's answered, and you see every hop in its history.

Return (on an item's page, ↩): sends an item back to whoever sent it, with a note saying why; it lands first in their Next up (their agent's, if an agent sent it).

Many proposals, one item: review batches¶✎ edit

When your designer has a dozen small proposals for you, it doesn't file a dozen items — it files one review batch (kind: batch), and its page shows each proposal as its own card: what it recommends first, the rest folded under Details, and a line linking the items it's about.

Answer each card where it stands: Accept, or Comment to say what should change. Your answer is written into that card and your agent hears it, so you can go down the page in one sitting. Accept the rest at the top takes every card you haven't answered (and every one your agent has revised); the line beside it says n of m answered. At the end of the page there's one big comment box for a free-form answer to the whole batch, the way you'd say it in chat — 1 x. 2 y, rest go — and your agent writes each card's answer from it.

An answered card shows what you said and folds away. A card your agent has revised after your comment reopens, marked, for another look. The batch is done when every card is accepted.

Two things worth knowing. Your answers reach your agent in one message a minute, so answering six cards quickly doesn't wake it six times; Send, at the end of the page, passes on what you've answered right away, and Accept the rest and the big comment box send at once by themselves. And an answer counts only for the text you saw: if your agent has revised a card since the page was drawn, your answer is refused, the card shows you the new text, and your comment stays in the box so you can send it against what's actually there.

Taken means locked: follow-ups¶✎ edit

Once someone has taken an item, only they change it. Anyone else who wants something changed makes a follow-up (the button on the item's page); it links to the item, and whoever took it is told.

Waiting on other items¶✎ edit

An item can wait on other items. When the last of them is done it becomes new again and its person is told, so an agent working the pipeline picks it up.

Handovers between chats and agents¶✎ edit

When an AI's conversation gets full, it writes a handover item for its own role: where things are, what's next, and the new chat's name and start prompt. Start the new chat with that prompt ("You are the coder. Work the pipeline."); it takes the handover first.

Released to the role. When an agent hands over, or goes quiet long enough to be marked gone, the items it was working on stay in progress but are released to its role: they read in progress · coder (released from coder-1), and nobody else can change them. The next agent in that role takes them up first, where they were; you can take one up yourself from its page (Take it). When an agent goes gone you get a notice listing what was released.

To-dos and items side by side: Work (pro and master)¶✎ edit

The Work page (/work, first tile of the Toolbox) shows the to-dos written in your topics on the left and the pipeline's items on the right, in one band per feature (a to-do's feature is the {#id} of the section it's under; an item's is its feature), with whatever has no feature in Unsorted, last. Flat shows one list per column instead.

Promote a to-do (also To pipeline in the Backlog): it becomes an item with its text and feature; the to-do stays, ticked, with a link to the item, as your draft of that topic.
Parked items stay off the Work page: a quiet N parked › under the item column opens them on the Pipeline page.
Demote to a to-do an item that should wait: it becomes a to-do in a topic you pick (by default ToDo:PROJECT, under From the pipeline, made if missing; Parked: needs more thinking is for to-dos you park by hand), as your draft, and the item is closed as a to-do, linked to it. (Parking keeps an item in the pipeline, on hold, until you unpark it.)
Promoting and demoting are your calls. Your AI does them when you ask it to (it names you as the one who asked, and the item's history says so); otherwise it suggests: an item for you, kind suggestion, listing what to promote, demote or drop, each linked, and you decide on the Work page.

Only people move work between people¶✎ edit

Your agents work for you: they take items for their own roles and hand them on to your other agents. Passing an item to another person, or moving it to another project, is always a person's decision.

Where a person steps in: permissions¶✎ edit

You decide, step by step, where a person has to step in. Each thing an agent can do in the pipeline (make an item, take one, drop it, mark it important, give the coder new work, publish, deploy…) has one of four settings: person (only a person does it, themself; the AI can suggest it), asks (you decide: the AI asks first and waits for your approval, or you tell it to and it goes ahead), tells (the AI does it and lets you know) and free (the AI just does it). A few are locked for everyone, whatever you choose: moving work to other members or projects, who can see a topic, tokens and vault grants, and memories only on your word. You start from a preset that follows your project's level (Cautious, Pro, Master speed), and can customize any step on the project's Permissions page. How that screen works: Permissions.