Roadmap
iKAgent → Roadmap shows published plans as a flow of phases. Phases that wait on each other run left to right; phases with the same dependencies sit in one column and run in parallel.
Two groups
- Your workspace: plans published by the teams you belong to. Members of other teams do not see them.
- iKanban: what we are building in the agent workspace. Every signed-in user sees these.
Newest plan first in each group.
What a phase shows
Its name, its status and the percent of its tasks that are done. No task titles, keys, people or links.
- Done: every task in the phase is done.
- In progress: a task has started or is done.
- Waiting: no task has started. A phase that waits on an unfinished phase says waiting on that phase.
- Cancelled tasks do not count.
Who publishes a plan
A plan is a top-level Feature; its child Features are the phases.
- Any member of the team can publish one of the team’s top-level Features, on a workspace with an active subscription. A child Feature cannot be published.
- Only iKanban staff publish the iKanban plans.
- Coding agents publish their plan before multi-step work and then start at once, without waiting for a confirmation. The
ikanban-roadmapskill in your repository’s.iKanban/folder tells them how. Agent setup writes it for you.
Plan and phase names are visible to every member of the team. Never put a secret, an internal link or customer data in them.
The Roadmap follows the plan file
An agent keeps its plan as one JSON file in your repository. The file opts in with a top-level roadmap block (team, project, and the plan_id the first sync writes). The agent changes only that file; the sync makes the Roadmap match it.
npx ikanban roadmap sync <plan.json>publishes the plan and applies every change.--checkchanges nothing and exits 1 when the Roadmap differs.npx ikanban hooks install(once per repository) adds a git pre-push hook and an agent hook for Claude Code, Gemini CLI and Copilot CLI. The plan reaches the Roadmap on each agent write and each push, from any git host. No CI is needed.- MCP:
sync_roadmap_plandoes the same in one call, withdry_runto see differences.
| Gate | What happens |
|---|---|
| Who may sync | a member of the team, on a workspace with an active subscription. The iKanban plans: iKanban staff only |
| Matching | each phase and task has a key in the file (F2, F2-T3). A key is found again on every sync, so nothing is created twice, even after a phase is renamed on the Roadmap |
| New tasks | one per task in the file, titled <key>: <text>, in the project of the block, assigned to the person who runs the sync (never to the AI Agent). They count toward the team’s issue limit |
| A task leaves the file | it is cancelled; the Roadmap leaves cancelled tasks out |
| A phase leaves the file | deleted when only its plan tasks were under it; otherwise it stays and the sync warns |
| Other tasks under a phase | never changed. When they hold a phase back from the status in the file, the sync warns |
| Refused, nothing changed | a plan or phase name with a link or email address, a key used twice, a dependency outside the plan or in a cycle, more than 1,000 tasks |
| No key or no network | the command says why and changes nothing. From a hook it never blocks the push or the agent |
| When it shows | at once; at most 60 seconds on a busy server |
The pencil and the comment
- Pencil: renames a phase. Members of the team see it on their workspace plans; iKanban plans can be renamed only by iKanban staff.
- Comment: feedback for the agent working on the phase. The number next to it counts your threads on that phase.
Feedback and the agent’s questions
- Open the comment on a phase, write what to consider or correct, and select Send.
- The agent working on the phase gets it. The agent may ask you a question; it shows in the thread and in your inbox.
- Write your answer in the thread and select Reply. It goes back to the same agent session.
Each thread shows a status: Queued (waiting for the agent), Delivered, Agent asked or Answered.
| Gate | What happens |
|---|---|
| Who may send | any signed-in user who sees the phase |
| Who sees a thread | only you; iKanban superadmins see every thread on a phase; other customers see none |
| Length | feedback and replies up to 2,000 characters; an agent’s question up to 500 |
| Rate limit | 10 messages an hour per person, feedback and replies together; more answers try again later |
| Delivery waits | while the agent’s run is going, your feedback waits and goes in when the run finishes. With no agent session on the phase yet, it waits for the next run on the phase |
| Advisory only | the agent gets your text marked as customer feedback to consider, never as instructions. It does not run commands, add links or change scope because of it. Any code change still goes through pull request review |
| Laptop runners only | feedback goes only to a laptop runner session, and only once iKanban turns this on, after a desktop app release carries the feedback-turn safety below. Until then it waits. A GitHub session never gets it: a GitHub run has no feedback-turn safety, and a comment would put your text on the repository. On a phase with only GitHub sessions, it waits for the next laptop run |
| Safety on that turn | the agent’s turn that carries feedback asks a person before a push or network call, even when the runner is set to Allow everything, and never pushes to main or merges |
| What the agent learns | your words only, never your name or email |
| The agent’s questions | keys, links and email addresses are removed before you see them, and each question is copied to iKanban superadmins |
Slack posts
A workspace can post Roadmap changes to Slack. It is off by default.
- Turn it on: Settings → Connections → Slack → Post iKanban build updates. Only workspace owners and admins can change it.
- Where it posts: the Default updates channel in the same dialog. With no channel, nothing is posted.
- When it posts: once when a phase changes status (waiting, in progress, done), within about 2 minutes. A phase that does not change is never posted again. Turning the setting on does not post the current status of each phase.
- What it posts: one line per change, for example Checkout redesign: F2 Settings page is now done, and the plan’s flow as text.
- Which plans: the iKanban plans and your workspace’s published plans. The channel sees plan and phase names of every team in the workspace.
The count in the sidebar
The number next to Roadmap is how many plans changed since you last opened the page: a new plan, a renamed phase, or a task that moved. Opening Roadmap clears it. The count follows your account, so it is the same on every device.