Quickstart: the demo sandbox

The fastest way to understand kanman is to watch it finish one story from start to end. The demo sandbox is a small public repository built for exactly that. It is safe to experiment with: it has no secrets, no production data and no users.

By the end of this quickstart you will have:

• a team connected to your copy of the sandbox repository
• three drafted stories with acceptance criteria, two of them approved and written to GitHub Issues
• one story that kanman built, checked with the repository’s CI and an independent review, and merged

What you need

• A kanman account. If your company already uses kanman, you may already be invited: sign in at app.kanman.ai. Otherwise create an account at app.kanman.ai/signup and open the link in the confirmation email. The same card then asks for your workspace’s name and web address, and Create workspace opens your workspace, where kanman introduces itself and offers Set up a team. A new team starts with a 14-day trial of the Team plan, without a credit card (see Plans and billing).
• A GitHub account that can create repositories (personal or in an organization).
• About 15 minutes. Most of it is waiting while kanman works.

You do not need Docker or Node on your machine. kanman provisions everything it runs in its own sandbox.

The sandbox repository

kanman-ai/pilot-sandbox is a small invoicing service in TypeScript: a Fastify API, a plain HTML invoice list, unit tests and a CI workflow. Amounts are integer cents, and the data is seeded in memory on every start.

The CI workflow is what makes it a good first repository: kanman judges every change by the repository’s own CI, plus a review by a helper that did not write the change. See How kanman checks its work.

Step 1: Copy the sandbox into your account

1. Open github.com/kanman-ai/pilot-sandbox and click Use this template (or Fork).
2. Create the copy in your account or organization. Keep the name pilot-sandbox.
3. In the new repository, open Settings > General > Features and make sure Issues is turned on. GitHub turns Issues off for forks by default, and kanman writes stories to GitHub Issues. Open Actions and enable workflows too, so the CI runs on kanman’s pull requests.

kanman opens pull requests against your copy, never against the original.

Step 2: Create the team

1. Open the team setup. If you just created your workspace, click Set up a team under kanman’s first message. Otherwise click the workspace name at the top left and choose New team.
2. Tracker: click Connect on the GitHub card. GitHub’s sign-in opens in a small window; authorize kanman with the GitHub account that owns your copy. When the window closes, your GitHub connection appears in the list and is selected. (If your browser blocks the window, click Open in this tab: you come back to the same step with everything you entered.) See Connect GitHub for the permissions.
3. Repositories: enter <your-account>/pilot-sandbox as the tracker project, name the team, for example “Sandbox Team”, add the repository <your-account>/pilot-sandbox and keep the base branch main.
4. Executor: choose Claude Code and Pay through kanman.
5. Skip Look, then click Create team on the last step.

The team gets kanman’s default columns (Backlog, Refining, Ready, In progress, Review, Done) and default limits on its own; there is nothing to map.

The team’s own chat with kanman opens, with the team’s board beside it (every team has its own chat; Personal is the conversation across all teams). Its header says Idle, and a Setup card pinned at the top of the team’s chat shows your progress: workspace, connection and team are done, the next step is your first story. The Setup card leads you through the rest of this quickstart; it is the same in every browser, and Hide removes it for everyone in the workspace.

Until the team has its first story, its Mind (the board) says Nothing on my mind yet and offers the one next step: Connect a repository if the team has none, otherwise Tell me what to work on. Stories does the same until kanman has worked and measured something, and switches to the real view as soon as there is something to show.

Step 3: Turn a requirement into stories

1. In the Setup card, click Describe it (or press N). The box of your sandbox team’s chat takes the focus; the chip under it names the team. If you write a requirement in Personal instead, kanman offers to Continue in your team and takes your request along. See Talk to kanman.

2. Paste this requirement and press Enter:

   Customers need to export their invoices as CSV, filtered by date range.
   

3. After a few seconds kanman answers with a card of three drafted stories. Click Open review to read them in full: each has Given/When/Then acceptance criteria, a test plan and a size.

4. Edit a criterion if you want to, then click Back to the conversation. In the card, Reject the story you do not need and Approve the other two.

5. Click Write 2 stories. The card says “2 stories written”.

kanman writes the approved stories to GitHub Issues in one batch, with the kanman label. They appear in the Backlog column with the badge “Ready for kanman”.

Step 4: Move a story to Ready

Click Pick a story in the Setup card: the Ready column lights up. Drag the story “Export invoices endpoint” (the exact title may differ) into it, or use Move to on the card.

A story in Ready that is not assigned to a person is kanman’s to work. kanman notices the move right away, looks at the whole board, plans the work and hands it to a helper. If it needs something only you can give, it asks you once, in the line above the message box.

Step 5: Watch kanman work

The helper works in its own sandbox, on its own branch. While it works:

• the line above the message box says Working on 1 thing; select it to see what the helper is doing right now
• the story’s live line in the conversation changes in place: planned, in progress, checks running, in review, merged
• the run page, opened from the story card or All tasks above the message box, shows the latest progress and the cost

Desktop Mobile

Step 6: Checks and merge

When the helper is done, kanman scans the change for credentials, pushes the branch and opens a pull request in your pilot-sandbox copy. Then:

1. The repository’s CI runs on the pull request. If a job fails because of the change, kanman reads the log and has it fixed.
2. A reviewer that did not write the change compares the diff to the story’s acceptance criteria and looks for dropped or weakened tests.
3. When CI is green and the reviewer approved the latest commit, kanman merges the pull request.

If you want a person to approve every merge, require a review in your repository’s branch protection on GitHub; kanman then waits for that approval like any colleague. See Merging.

When the pull request is merged, the card moves to Done and the Setup card completes with two next steps: Invite your team and Set budgets. Click Done to fold the card away.

What to try next

• Move the second approved story to Ready and watch two helpers work side by side. The 14-day Team trial allows up to five runs at a time.
• Ask kanman “why did you merge it?” in the conversation. It answers from the team’s activity log.
• Read How a story flows for the full picture, then Set up a team on one of your own repositories.