Cards and Cline Kanban — a comparison

Cline Kanban's honest claim is on guiding and fitting in: a board that aggregates many running CLI agents into one glanceable surface, with worktree isolation that lets them coexist without file-level conflict. Cards' honest claim is on guiding and checking: a per-job work surface that absorbs the re-entry tax and gives a reviewer an intent baseline. They operate at different layers and answer different questions — which agent needs attention right now, versus what this one job was for — so a team facing both attention load and context loss could run both.

The companion piece, [What Cards actually changes](../../formula/cards-impact-on-terms-introduction.md), lays out a five-step pipeline: starting new attempts, guiding them, checking them, fitting them into the larger project, and sometimes approving them through a real authority gate. This page walks Cards and Cline Kanban through that pipeline, pipe by pipe, without ranking them. In the marketplace ontology, Cline Kanban is a multi-agent control plane and attention interface: its primary layers are Attention and Supervision and Isolation and Boundary, with a secondary touch on Delivery and Integration. Cards is a control artifact and memory/continuity system: its primary layers are Control Artifact and Memory and Continuity, with a smaller presence on Delivery and Integration.

Cards is a VS Code extension for building with coding agents from plan to commit. It keeps one coding-agent job organized inside VS Code — description, plans, context, comments, sessions, transcripts, commits, changed files, and attribution — and actions on that job launch the configured coding agent from the job's context. The operator is a professional developer who reads diffs, shapes plans, and ships to a shared repository. The unit of work is a card: one bug fix, feature, cleanup, or investigation, persisted as a local git repository on disk. Cards does not run the agent; the harness the developer already uses (Claude Code, Codex, Cline, and the model behind it) does the calling, editing, and command-running. But Cards is not a passive notebook either: its default setup ships actions and skills that direct how the plan forms, how it is stress-tested, how the implementation is checked, and how the change merges. The boundary is execution, not direction.

Cline Kanban is a local, browser-hosted board for orchestrating CLI coding agents in parallel. The operator is the same kind of person — a developer comfortable with git and the command line who already runs tools like Claude Code, Codex, Cline, or OpenCode. The unit of work is a card on the board: one discrete agent task that gets its own terminal and its own ephemeral git worktree. Cline Kanban does not run the model or execute the code either; it detects the installed CLI agent and drives it inside the worktrees it manages, aggregating their state onto one page. Cards is organized around keeping one job intelligible from plan to commit. Cline Kanban is organized around keeping many running jobs visible and physically separated at once.

Cards raises the quality of each attempt at creation; Cline Kanban raises the convenience of launching and chaining many of them. Starting is the act of launching an attempt at all — turning an intention into a running piece of agent work.

Cards starts work through an intake interview. The default `interview` action draws out what the work is, why it matters, what success looks like, and what constraints apply, so that by the time the agent launches, the card already carries a written description and a plan. The effect is on seriousness, not speed: vague ideas get sharpened into real attempts or dropped before they consume downstream capacity. The ontology layer is Control Artifact — the plan and description become inspectable artifacts before any code is written.

Cline Kanban starts work two ways: a developer types a description and clicks to create a card, or a sidebar chat agent decomposes a larger goal into linked cards, with Kanban injecting board-management instructions into that session. Linked cards form dependency chains that auto-start the next task when a predecessor finishes; with auto-commit enabled, a single prompt can run a sequence of agent attempts without the developer touching the board again. The ontology layer is Attention and Supervision feeding the Execution Mode layer — the board lowers the friction and manual cost of launching and sequencing many attempts.

The structural difference is plain. Cards raises the quality of each attempt at creation; its question is whether this work is worth starting. Cline Kanban raises the convenience and automation of launching and chaining attempts; its question is what should start next when this finishes. Neither raises raw starting throughput: if the constraint is API rate limits or machine memory, the ceiling is set by hardware and provider. Both share the same backfire — a poor intake or a poor decomposition prompt produces badly scoped attempts that waste downstream capacity.

Cards reduces the steering an attempt needs on return; Cline Kanban makes more of the developer's attention available in the moment by making many running agents glanceable. Guiding is the human work of pointing the agent at the right thing and keeping it pointed there across the life of the work.

Cards reduces how much steering each attempt needs. The card survives every session break. When the developer returns after a meeting, a day, or a week, the description, plan, comments, and the running map of changes are already on disk; the developer reads the context rather than reconstructing it, and the agent in the next session does not need a long re-explanation because the job context is durable. This is a per-attempt reduction: the same developer, the same hours, but each card costs fewer of them to steer. There is a smaller secondary effect — because the card is ordinary files on the machine, it can be glanced at outside the heavy editor — but that is limited to the same computer, not a phone or shared dashboard. The ontology layer is Memory and Continuity: the card preserves what survives interruption and handoff.

Cline Kanban makes more of the developer's attention available to steer with. Its board converts the problem of supervising several agents from a sequence of context-switches between terminal windows into a single glanceable surface — each card shows the agent's latest message, so a glance tells the developer which cards are running, blocked, or done. The product's framing is to watch the board, not the terminals. Less time lost to finding out what each agent is doing means more time available for actual steering. The ontology layer is Attention and Supervision: the board is a supervisory model for staying oriented across many agents at once.

These mechanisms are independent and can coexist. Cline Kanban also closes a per-attempt steering loop Cards does not: comments on a diff line route back to the agent as feedback, so a near-miss gets corrected inside the same run rather than restarted. Cards has commenting on the card too, but its comments are durable signal carried with the work, read by the next launched session rather than injected mid-run into a running terminal. Both share the same outer constraint: neither expands the developer's hours, and neither is a shared team surface — the card lives on one machine; the board is a local page reachable on the developer's own devices but not an org-wide dashboard. Both also share an overload failure mode: a card that becomes a notification flood, or a board that becomes a wall of status indicators, each flips from saving attention to consuming it.

Both make human checking cheaper without automating it, and both share the same vulnerability: neither provides independent verification. Checking is the work of deciding whether what the agent produced is actually right before it counts.

Cards lowers the cost of checking by giving the reviewer a complete work object for intent. The description and plans were written before and during the work, not retrofitted afterward; the attribution tree projects the cumulative changes against the current state of the codebase. The reviewer reads the card and the map and judges output against a baseline rather than reconstructing the intent from a transcript. The ontology layer is Control Artifact supported by human verification — Cards supplies the intent baseline but does not automate the check.

Cline Kanban lowers the cost of checking through a diff viewer with a checkpoint system that scopes changes to specific message ranges, so the reviewer can follow what changed at each step instead of seeing only the final cumulative diff. Inline comments flag issues and route back to the agent. The ontology layer is also human verification: the board organizes the agent's own output for a human to read but introduces no second opinion.

Both occupy the same fundamental vulnerability: neither provides independent verification. In Cards, the markers and the agent share blind spots; in Cline Kanban, the diff and the transcript come from the same system that launched the agent. Neither introduces a separate reviewer, an independent test harness, or an outside system. Both also share the most dangerous failure mode: rubber-stamping. Cards adds advisory markers — a plan marked approved, a change marked merge-ready — and a reviewer who clicks them without checking the substance makes half-checked work look fully checked; this is the single most dangerous trap in Cards, and it nets out negative unless real, independent checks sit behind the markers. Cline Kanban's neat presentation can produce the same false confidence — an organized diff trusted as reviewed when nobody engaged with it. Neither can claim checking honestly without a real check behind the surface.

This is the pipe where the two products diverge most: Cline Kanban prevents file-level conflicts structurally, through per-card worktrees, while Cards only makes collisions visible. Fitting in is the work of merging a finished piece into the larger project without breaking what is already there.

Cards has a modest claim. The attribution tree makes collisions visible at a glance — which parts of the project a piece of work has touched — and the default setup gives each piece its own isolated working copy so pieces in flight do not stomp on each other. The ontology layer is context isolation plus a Delivery and Integration touch through the workflow markers. But Cards does not run merges, manage releases, coordinate dependencies between separate pieces of work, or take an opinion on the team's integration process.

Cline Kanban's claim here is more structural and is its strongest mechanism alongside guiding. Each card gets its own ephemeral git worktree — a lightweight, isolated copy of the repository. Agents in separate worktrees cannot create file-level merge conflicts because they share no filesystem state. Symlinks to gitignored directories such as `node_modules` avoid reinstalling dependencies per task. A built-in flow lets the developer click Commit or Open PR, and the agent converts the worktree into a commit or branch and resolves merge conflicts if the base branch has moved. The ontology layer is Isolation and Boundary at the code-isolation level, with a Delivery and Integration touch through the commit and PR flow.

Both share a hard limit. Worktree isolation and Cards' isolated working copies prevent file-level conflicts but not logical conflicts — two agents changing related code in ways that, combined, produce a system that does not work. Neither addresses integration outside the repository: cross-team coordination, full-system build pipelines, staged rollouts, or production deployment. Both carry the same concurrency warning: running many parallel agents raises integration cost faster than throughput, and gains measured on a few simultaneous pieces should not be extrapolated to dozens.

Neither product has anything to claim here. Approving is a real authority gate: a separate party who must formally sign off on each piece of work because of policy, regulation, or organizational rule. Cards carries advisory markers that can look like approval steps but are not; they do not block anything at the system level, with one narrow exception for the final merge marker, and there is no place for a compliance officer to log in. Cline Kanban's board is local to the developer's machine with no approval queue, no role-based work gate, and no compliance surface; role-based access and authentication logs are described only as future work for the broader Cline platform, not present in the research-preview Kanban product. For a team whose binding constraint is a real authority gate, neither product is built for that problem, and that is a deliberate choice in both cases rather than a missing feature.

Cards raises the accepted fraction by removing context-loss rejections. When a reviewer can read the description and plan written at the start, rejections shift from "I have no idea why this was built this way, send it back" to substantive "this approach is wrong." The intake interview also keeps vague ideas out of the started pool. This is conditional: if rejections are driven by code quality, requirements changes, or business decisions, none of those are about context loss and Cards will not move them.

Cline Kanban raises the accepted fraction through two different mechanisms. The card structure turns an unnamed terminal session into a labeled card with a description and a visible lifecycle, so each run is more likely to be a real attempt. The inline commenting loop catches near-misses: the reviewer sends a correction rather than abandoning the card, so the work gets steered back rather than scrapped.

Both share the same counterweight. Easier, more structured starting can make the developer less discriminating. Cards' structured intake can create the feeling that every attempt is well-founded; Cline Kanban's low-friction card creation can fill the board with cards that should never have been started. A board with ten cards looks productive even when some were not worth the overhead.

Cards' distinctive mechanism here is the attribution tree projected against the current state of the project: it answers whether a piece of work is still in place a month later without forensic digging through git history, and the card preserves the rationale so a future reader is less likely to undo the work for the wrong reason. The risk is a stale plan that outlives its assumptions; the system has signals to re-confirm a plan, but it cannot force a team that ignores them.

Cline Kanban's checkpoint system and diff history preserve what changed, in what order, and why, so a later reader can trace the progression. The durability cost is the worktree model: worktrees are ephemeral, and trashing a card removes the worktree, leaving only a resume ID rather than a full state reconstruction. The full working environment of a completed card is gone once cleaned up. Both products thus face a stale-artifact risk and neither has a robust mechanism for detecting it automatically.

Cards reduces cleanup through default failure-mode agents that critique plans and implementations before they cause downstream work, and through an intact on-disk record that makes a senior rescue faster. Cards increases cleanup through the rubber-stamping pattern: advisory markers clicked without review let half-checked work merge and fail later. In real-world use this increase is usually the dominant effect unless the team wires real, independent checks behind the markers.

Cline Kanban reduces cleanup by preventing file-level merge conflicts through worktree isolation — conflicts that never happen need no resolving — and trashing a card removes its worktree cleanly. Cline Kanban increases cleanup through auto-commit and auto-PR modes, which can ship unchecked work into the repository for someone else to revert; the rubber-stamping pattern applies to its organized diff as well. Neither product reduces cleanup that comes from the agent itself going in circles, retrying a failing approach, or compounding mistakes inside a session; that cost sits outside what either tool addresses.

Cards installs as a VS Code extension (from the Marketplace, or Open VSX if you're on Cursor, Windsurf, or VSCodium) and runs against your existing local Git repository. Trying it costs the time to install the extension and point it at a coding-agent CLI you may already run — the same kind Cline Kanban itself detects and drives, such as Claude Code, Codex, or Cline. Cards imports nothing from Cline Kanban's boards, so an existing board is untouched either way, and reversing the trial is just deleting the extension and the local `~/.cards/cards-repos/` directory it created. Because the two operate at different layers — a board for watching many agents versus a work object for one job — a developer already running Cline Kanban can add Cards for the jobs where re-entry and review are the bottleneck without giving up the board for the rest.

Cline Kanban's honest claim is on guiding and fitting in: the board aggregates many running CLI agents into one glanceable surface, and worktree isolation lets parallel agents coexist without file-level conflict. That matches a developer or small team running several CLI agents at once who has found that cycling through terminal windows does not scale and that concurrent edits collide. Cards' honest claim is on guiding and checking: the card absorbs the re-entry tax for one job and gives a reviewer an intent baseline, with smaller effects on starting, fitting in, accepted yield, and durability — and nothing on approving. That matches a developer who loses time reconstructing context after interruptions and whose reviewers cannot tell what was intended. The two operate at different ontology layers and answer different questions — Cline Kanban answers which agent needs attention right now and keeps their files apart; Cards answers what this one job was for and what it still amounts to. They are not alternatives; a team facing both attention load across parallel agents and context loss on individual jobs could run both.