How it works

This page follows a request from the moment you submit it until it is delivered. For each step it says what happens, who does it and where in the panel you see it. Why the road looks the way it does is on the page What Kanbanero is.

The panel is light or dark as your device is set. To choose for yourself on the device you are using, pick Automatic, Light or Dark under Appearance at the bottom of the menu, once you have signed in, and press Apply. The choice is kept on that device only, and this guide is not affected by it: it follows only your device.

Who takes part

Requester is the one who describes what is needed. That is probably you.
Engineer is a developer on the team. The engineer sets the work going, and the work itself is done by AI, Claude, in the engineer's own session.
Admin creates projects with New project in the menu, and invites people to them under Members. Until an invited person has signed in for the first time, an admin can take the invitation back on the same page with Remove invitation. An admin may also approve a sprint and answer when work has got stuck.

The same person can have several roles, and may then do everything the roles allow together.

To invite someone, an admin opens Members, fills in their email address, name and role, and presses Invite. Members then shows a ready message under Message to send: the panel's address, the address to sign in with, and two steps, first signing in to Kanbanero in the browser and then connecting an AI. The admin copies the message and sends it to the person herself, by email, chat or whatever suits. Kanbanero does not send invitations by email, or in any other way.

The order of the two steps matters: an AI finds the person's projects only after she has signed in to the panel once. At her first sign-in she lands on Welcome (/welcome), which shows the same two steps with the first one done, and she can open it again later. Someone who signs in without an invitation gets the page Not invited, which says that an invitation from an admin is needed and shows the address she signed in with. An account alone opens nothing in Kanbanero; with Sign out she can try another account.

An admin also connects the project to its repo on GitHub, under Repository on Settings: choose the installation of the GitHub app, give the repo if the project has none yet, and press Connect. GitHub is asked whether the installation reaches the repo before anything is saved. If the panel answers that the GitHub app is not installed, the app has no installation on the account or organisation that owns the repo. Whoever owns the repo installs the app on GitHub, and the panel links to the page where that is done; then the admin chooses the installation on Settings. Once a project is connected, its repo and installation are not changed there. Until then, approved work waits for the connection before it is brought into the code.

Work only moves while an engineer is connected

Kanbanero runs no AI itself. Every step below that is not yours is taken when an engineer has their session running. If nobody is connected the work stands still, also in the middle of a request, and it carries on when someone on the team starts their session again.

You do not need to keep watch. When a question, a prototype, an objection or a decision is waiting for you, you get a notification under Notifications in the menu, and the same when your request is delivered. On Requests, under the tabs and above the list, Waiting for you also appears when something is: questions and objections on your requests, questions under Decisions that wait for an answer, and a sprint that waits for your approval. The block shows under the Open tab. A prototype to approve is not listed there; you see it in the notification and on the request's own page. No email is sent.

Step 1: You submit the request

Who: you, as the requester.
What: You describe in your own words what should change, for whom, and how you will know it came out right. You do not need to have all the answers; if something is missing, the analysis asks.
Where: Under Requests in the menu, with the button New request. Fill in What should change? and Describe it in more detail, attach screenshots if you like, and press Submit.

If you have connected an AI assistant under Connect your AI, you can describe the request to it instead, and it submits it for you, in every project you are in; see Your AI at the bottom. If you want to change something afterwards, you do it on the request's own page, under Rewrite the request or attach files. Only the one who filed a request, or an admin, can rewrite it, and only before work on it starts.

If something that worked has stopped working, or does what it should not, report a bug instead: press Report a bug next to New request, or ask your AI to report it for you. A bug asks four questions: what happened, what should have happened, how to make it happen again, and how serious you think it is. Your answers let whoever looks into it see what you saw, and see it again, without first coming back to you; only what should have happened may be left empty, if you are not sure. After that a bug is analysed like any other request, and fixed through a story that takes the steps below.

Step 2: Analysis and questions

Who: the engineer's AI analyses, and you answer.
What: The request is read and interpreted. If something is unclear you get a question. If something is better seen than described, it can become a prototype, a clickable sketch to take a position on.
Where: The questions are at the top of the request's page under Waiting for you. Write in Your answer and press Answer. A prototype is shown further down the same page, under Prototypes: press Approve this version, or write in What do you want changed? and press Ask for a change. More on prototypes below.

You, who submitted the request, are the one who answers its questions and approves its prototype. Questions that concern the whole project and not just one request are gathered under Decisions in the menu. There every requester in the project can answer, with Answer, and the answer stays as the project's decision. A request that waits for such a decision says so on its page.

The analysis may also object to a request: it says why the request seems to pull the product away from the project's goal, and what it suggests instead. The one who filed the request gets a notification, the objection is first on the request's page under Waiting for you, and Waiting for you on the start page lists it until it is answered. Any requester in the project can answer it, once, with one of three choices. I agree, I'll rewrite it means the request is rewritten and the analysis reads it again; if you did not file it yourself, the one who did, or an admin, rewrites it. Build it as it stands means nothing changes and it is built as written. The goal must change means the request was right and the goal was out of date: you write the new goal there and then. The work goes on whichever you pick, and also while you decide. The objection stays on the page with the answer, who gave it and when.

The project's goal says what the product is meant to become, for whom, and what matters most right now. It is under Goal in the menu, where everyone in the project can read it and any requester can change it. Each change is a new version, and the earlier ones stay readable there.

When something is easier to show than to describe, the team makes a prototype: a clickable sketch of what they mean to build. It is on the request's own page under Prototypes, and you get a notification when a new version is ready for you. While a prototype waits for you, the request's stories are not broken down into tasks, and the screens it shows are not built.

The team may make more than one variant of a prototype, each under its own name, so that you can compare them side by side. For each variant you see its latest version, marked Waiting for your approval while it waits for you.

To say yes to a prototype, press Approve this version. Approving is final: you approve one version for the whole request, and that version is what gets built. The latest version of every other variant then reads Not chosen, and you can still open it.

To ask for something different in a prototype, write in What do you want changed? and press Ask for a change. The version then reads Change requested, and what you wrote stays beside it as Your comment:. The team answers with a new version of the same variant. Above it you see In answer to your comment: and what you wrote, so you can check that it was understood.

Under the latest version of a prototype, Earlier versions keeps the versions before it, oldest first. Open one to see it, what became of it, and the comment you gave it. Until you have approved a version, you may approve an earlier one too, if you liked it better. Only you, who filed the request, can approve a version or ask for a change. If a prototype looks empty, reload the page.

A prototype is shown in a frame of its own, kept apart from the rest of Kanbanero. A prototype never reaches your sign-in. A link to a prototype never opens another prototype.

Step 3: Stories

Who: the engineer's AI splits up the request, and you read.
What: The request is split into stories, smaller parts that can each be built and checked on their own. Each story is in turn broken down into tasks, the smallest pieces of work, and each task is estimated.
Where: Under Stories in the menu, all stories are listed in the order they are built. The request's page lists the ones that belong to it.

There are two queues. The order on Requests decides when the requests are analysed, not when they are built. There every open request has a box at the far left with its position. Choose another number in the box to move the request there; on a computer you can also drag the row.

What is built first is decided by the order of the stories under Stories. A new story goes last. That order cannot be changed in the panel, but a requester can ask their AI assistant to move a story; see Your AI at the bottom.

Step 4: The sprint is proposed and approved

This step exists in projects that work in sprints. If the project does not require sprints, the work moves on to the build without waiting for it.

Who: an engineer proposes the sprint, in the panel or through their AI. You or an admin approves it.
What: The engineer gathers what is to be built next into a sprint, with a goal and a dependency check: what the sprint relies on outside the code itself. Nothing in a project with sprints is built until you have said yes.
Where: Sprints in the menu, and then the sprint's own page. Read the goal, the dependency check and the contents, and press Approve sprint with the sprint's number, at the top of the page.

If something is missing before the sprint can be approved, an estimate for example, the page says what instead of showing the button. Approval is done only in the panel; your AI cannot approve for you. After your yes the goal is locked and the sprint takes no more requests, but you can take one out with Take out.

If the analysis rates a bug you reported as critical, you or an admin can confirm it on the bug's page with Confirm as critical, and its fix then does not wait for a sprint. It is still reviewed and released like everything else.

Step 5: Build and review

Who: the engineer's AI builds and reviews, in separate rounds. You can follow the work.
What: Each task is built and tested. Then the work is read by a reviewer who did not build it, with security in mind as well. If the reviewer finds a fault, the task goes back to the build. Only approved work is brought into the code.
Where: In progress in the menu shows what is being built or reviewed right now, in which step, and when the work was last heard from. The page updates itself. On the request's page you see how many tasks are done.

Board in the menu shows how the running sprint is going: one row per track, with the columns Planning, Ready, Building, Review and Done, and each story as a card in the column of its least finished task. A card whose work is stopped by a flag says so, and when the flag is a question for you, the card is marked A question for you. Requests and stories outside the sprint come last, under No track. If no sprint is running, the page says so.

If a task gets stuck several times it is flagged and ends up under Flagged. There an engineer or an admin answers. If the question is about what should be built, and not how, you get a notification that the task is waiting for an answer from you, and the question is shown in amber, as your turn, by the task on the request's page. You can read it under Flagged, but not answer there: the answer is written by an engineer or an admin. Give your answer to one of them, and they enter it.

If it turns out during the work that a story does not hold, it is sent back to the analysis. If the analysis then proposes that something be split, merged or cancelled, the proposal is on the request's page under Back to the analysis. Nothing changes until a requester, or an admin who is a member of the project, presses Confirm; Decline says no.

Step 6: Delivery

Who: the engineer's AI writes what was delivered. A person on the team releases it.
What: When everything in the request has been built, reviewed and brought in, it shows as done, with a note on what was delivered. Getting the change to the people who use the product, a release, is a separate step that a person on the team takes. Kanbanero never releases anything itself.
Where: The note is on the request's page under Delivered., and you get a notification. In a project with sprints, the sprint's page says The sprint is waiting for a release until what was built is released.

If you are not happy with what was delivered, you submit a new request. A delivered request is not reopened.

Step 7: Retrospective and closing

This step, too, exists only in projects that work in sprints.

Who: an engineer closes the sprint. You read it and make use of what came out of it.
What: When every request in the sprint is done or cancelled, and the work is released, a retrospective is written: was the goal reached, what was caught along the way, what decisions were made and what can be better. The engineer's AI can put forward a proposal, but it becomes the retrospective only when the sprint is closed. After that the next sprint can be approved.
Where: The sprint's page. The engineer writes or adjusts the retrospective and presses Close the sprint.

In the closed sprint, each point the retrospective lists as an improvement can become a new request with Make it a request, and each decision it lists can be carried over to Decisions with Carry over to the decision log. That is done by a requester, or an admin who is a member of the project. A closed sprint is not reopened.

What it costs

Every request shows on its page what the work has taken so far, in time and in tokens. The estimate is not there. In a project with sprints it is on the sprint's page, per story, and after the approval next to what the work actually took. If you have connected an AI assistant, it can also tell you the estimate for a request. The time is the time someone worked, not time spent waiting in a queue. Tokens measure how much text the AI has read and written: a measure of the amount of work, not a price.

Your AI

You can also do step 1, and your answers in step 2, through your own AI assistant, which you connect under Connect your AI. In all your projects it can submit a request, change it, answer questions and move a request or a story in its queue. One connection is all you need for that, also in a project that works in sprints. Approving a prototype or a sprint you always do yourself, in the panel.

Only the building work itself is different. In a project that works in sprints, the engineers take work from the queue through the project's own address. You do not need it to submit, change or answer anything.

Connect your AI also shows that address for each project you are in that works in sprints, and says what it is for.