tags

#help #pipeline

Help: the pipeline¶‹ PreviousNext ›

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¶

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 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¶

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 (pro and 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. Tap a role to see its items (and its agent's).

Every step is on the record¶

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¶

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):
  • Features: a short description of each feature it builds, in your words.
  • 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¶

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¶

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 instead of doing the work now.
• Ask for links, so you can open each item.
• Say "mark it important" (or "drop it", "move it to the to-do list") 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¶

Say "park it" to your AI about an idea and it becomes an item for you, 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¶

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¶

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.

Important items¶

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 ★.

The list's order¶

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

Next up: rank, size and batches¶

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 ↑ ↓; a handover and important items always come first. 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¶

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.

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).

Taken means locked: follow-ups¶

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¶

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¶

When an AI's conversation gets full, it writes a handover item for its own role (where things are, what's next) and parks one for you: "Start a new chat as the coder". Start the new chat with "You are the coder. Work the pipeline."; it takes the handover, which closes the start a new chat item by itself.

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

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.
• Move to 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 moved to to-do, linked to its to-do. (Parking is the other way round: an idea becomes an item for later.)
• Promoting and moving to to-do 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, move to to-do or drop, each linked, and you decide on the Work page.

Only people move work between people¶

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.

See also: Help, the system view.

Where a person steps in: permissions¶

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; the AI can suggest it), asks (the AI asks first and waits for your approval), 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.