Delivery Loop

The delivery loop takes one change from a task to a shipped release. Every step shows in iKanban: on the board, in the sprint, in the release, in iKAgent → Pipelines and in iKAgent → Roadmap.

The agent does the steps. You decide when to merge and when to ship.

task (key) ─► sprint ─► release ─► branch + PR "KEY: …" ─► pipeline stages ─► merge ─► ship release
     └──────────────── Roadmap follows the plan file (multi-step work) ────────────────┘

The ikanban-delivery-loop skill in your repository's .iKanban/ folder tells the agent how. Agent setup writes it for you, with .iKanban/runbooks/delivery-loop.md: the same loop for you, with what you do and what you see at each step.

The steps

StepWhat the agent doesMCP tool
Where the work goesFinds your team, the active sprint, the open release and the feature.get_me, list_sprints, list_releases, list_features
TaskUses the key you name, or creates one task for the change.get_issue_by_key or create_task
SprintPuts the task in the active sprint.assign_task_to_sprint
ReleaseFiles the task under the open release.assign_tasks_to_release
Branch and pull requestNames the branch abc-123-short-name and the pull request ABC-123: what changed. The key links the pull request to the task.update_task (status in-progress, then in-review)
Pipeline stagesYour CI reports each stage with the task key. The agent reads the lane.get_pipeline
MergeMerges after the checks pass and you say so.update_task (status done)
ShipChecks that every task is done, cancelled or moved, then ships the release when you say so.get_release, update_release (status shipped)
RoadmapFor multi-step work, publishes the plan file before the work starts and syncs it after each change.sync_roadmap_plan

A step your CI does not run, for example a manual deploy, gets one event: npx -y ikanban pipeline event --task ABC-123@pr-45 --stage release --status passed --detail "v1.4 on prod". Set up CI reports with the ikanban-pipelines skill. See Pipelines and Roadmap.

The agent asks first

The agent asks you before it:

Where the MCP tools come from

Where the agent runsiKanban MCP server
Laptop runner session (the desktop app runs the agent)The runner gives it, from desktop 0.1.12.
Claude Code, Copilot CLI or Gemini CLI on its ownRegister <api_url>/sse once, transport http, header Authorization: Bearer <key>. See Claude Code.
CI (GitHub Actions, GitLab, any)None. CI only reports stages, with npx -y ikanban pipeline event.

With no iKanban tools in the session, the agent says so and stops. Update the desktop app, or register the server.

Gates

GateValueWhat you seeChange it
PipelinesPro and Pro+On Starter, Pipelines answer 402. The agent skips the pipeline step and says "Pipelines need Pro". It never fails the build for this.Upgrade the plan
Tasks per teamStarter 2,000 · Pro 5,000 · Pro+ 10,000create_task answers 402Upgrade the plan
Pipeline historyStarter 3 months · Pro 6 · Pro+ 12Older runs are goneAgent settings → Pipelines
Wait for checks10 minutes, in the foregroundThe report shows the checks as pendingSend a follow-up: "Read the checks and the pipeline lane, then give the report table."
Sprints, releases, RoadmapEvery plan——

When it does not work

SymptomCauseFix
No iKanban tools in the sessionDesktop app older than 0.1.12, or no MCP server registeredUpdate the app, or register the server
The pull request is not on the taskNo key in the branch or the titleRename the pull request to ABC-123: …
No lane in PipelinesCI does not report, or the plan is StarterUse the ikanban-pipelines skill; Starter has no Pipelines
create_task answers 400Missing feature_id, priority, estimate or task_typeFind the feature with list_features, then add the four fields
create_task answers 402The team reached its plan's task limitUpgrade, or ask the owner