Your first story

Your team is set up. Now pick one real piece of work and let kanman finish it. This page shows both ways in, what happens on the way, and what to do when kanman stops to ask.

Pick a good first story

The first story should build trust, not test limits. Good candidates:

• small (size S), in an area your team knows well
• with an outcome a person can see or call: a new API field, a filter, a validation message, a CSV column
• not touching infrastructure, migrations of production data, or security settings

Avoid broad refactors and anything that needs a decision from someone who is not in the room. kanman would stop and ask, which is correct but slow for a first run.

Way 1: Start from a requirement (in the conversation)

1. Open your workspace (it opens on the conversation with kanman) or press N anywhere. Check that your team is on the chip next to the message box.
2. Paste the requirement as you would write it to a colleague: a sentence, a paragraph from a spec, or a Slack thread copied as text. Press Enter.
3. kanman first decides what the message is. Only a work request becomes stories; a status question gets an answer, and an operational request (pause or resume the team, cancel a run, expedite or deprioritize a story) comes back as a card whose button names the change, for example Pause team; a paused team can be resumed from the same card with Resume team. Pausing and resuming need a workspace admin. If the requirement is too vague, kanman asks up to three questions first; answer them in the review and click Draft again.
4. For a work request, kanman drafts one or more stories, each with:
   • acceptance criteria in Given/When/Then
   • a Demonstrate block: concrete steps that show the outcome
   • a test plan, a size (S, M, L) and the affected areas
   • the details kanman decided on its own (What I assumed) and the questions only you can answer, each marked Blocks approval or Doesn’t block
   • a readiness score from 0 to 100
5. The drafts arrive as a card. If a draft needs an answer, kanman says so in one sentence and lists the questions under it: Answer, Let kanman decide or Not relevant, or reply in the chat (“1: …, 2: not relevant”). See Answer kanman’s questions. Reject what you do not want and Approve the rest; Open review shows every detail to edit what is wrong. Only stories that pass every readiness check can be approved; owners and admins can also approve a story that only open questions hold back.
6. Click Write N stories in the card (or Write N stories to tracker in the review).

Approved stories are written to your tracker in one batch and carry the pickup label (kanman by default). They land in the Backlog column. Writing does not start the work: kanman tells you so in the conversation (“PU-43 is in the Backlog. Say "start" or move it to Ready and I’ll begin.”), and every written story in the card offers Start now. It moves the story to Ready exactly like dragging it, so you can also say “start PU-43” (or just “start it” right after writing). If you have several written stories, kanman asks which one you mean. On the Local plan runs are not included, so kanman explains that and links to Choose plan; when all run slots of the team are busy, the story still moves and waits for a free run slot.

Way 2: Start from an existing issue

If the issue is already written:

1. Add the pickup label (kanman by default) to the issue in GitHub, GitLab or Jira.
2. kanman mirrors the issue onto the team board, in the column of its status. The story page (/teams/<team>/stories/<KEY>) shows its readiness and lets you add missing acceptance criteria and a Demonstrate block.

A story needs a Demonstrate block: it names the pages kanman looks at and what the acceptance test shows. See Stories and acceptance criteria.

Move the story to Ready

Click Start now on the written story in the conversation, say “start” and its key, drag the card to the Ready column in kanman (or use Move to on the card), or move the issue to the matching status in your tracker. With an acceptance manifest, kanman first starts your app and looks at the pages the Demonstrate step names, in light and dark mode, while the card waits in Refining. What happens next depends on the size of the story and on your repository (the proof follows the team setting, routine and complex stories by default):

The evidence of the finished run shows how long it took from Ready until the pull request was ready, see Ready to PR ready.

Approve the plan

With plan approval set to always (the default), kanman asks for your OK on its plan before writing code: the approach, the files it expects to touch, and how it will demonstrate the result. The decision appears at the top of the run page, where the work is, and in Decisions; the card’s run badge says that it needs you. Click Approve plan, or choose Request changes and write your note right away (the field has the cursor; Ctrl+Enter or Cmd+Enter sends it): your note stays on the card, and kanman comes back with the reworked plan and says which change it made (“I reworked the plan for SBX-157 as asked: …”). Reject ends the run and moves the story back to the Backlog.

Follow the run

The run page (/teams/<team>/runs/<run-key>) opens on its overview: what kanman is doing right now, every step from plan to merge with its state and time, the cost against the run budget and the latest progress. The tabs Steps, Evidence, Agent log and Cost & details hold the rest, see The run page. While the run is checked, the evidence fills in check by check as each one finishes. When the run reaches Review, Open pull request is the page’s one main button. You can Stop the run at any time and Retry it later.

When kanman stops and asks

kanman never guesses on things that need a person. Typical stops, all in Decisions:

Each decision explains the situation and kanman’s recommendation. Your answer, your name and the time are recorded in the audit log.

Review and merge

When the run reaches Review, the pull request carries the evidence pack: the plan, each acceptance criterion with its result and file references, the gate results with artifacts (Playwright trace, screenshots), tests, CI, policy decisions, cost and duration. Review the code as usual. Merging moves the story to Done. On a new team, the Setup card on the board then completes with a short summary of the first verified change.

After the first story

• Let two or three more stories through before you change settings.
• Look at the run cost and duration in the evidence packs to calibrate the run budget.
• When the team trusts the flow, consider a different preset: Choose and tune a preset.