---
name: kanban-board
description: Use this skill when the user asks to add, create, list, start, link, update, assign, offload, or manage Kanban tasks, cards, or board items. Trigger for kb or kanban requests, Claude Code or Antigravity task routing, agent override settings, auto-review, commit or PR automation, task dependencies, backlog triage, and board operations.
---

# Kanban Board

Use the installed Kanban CLI for board operations. Do not guide the user through manual UI steps when a CLI operation can do the job.

Command prefix: `kanban`

## Scope

This skill is for board management only. If the user asks for implementation work in the context of Kanban, create or update Kanban tasks with clear prompts instead of editing source files or coding.

Safety boundaries:

- Do not stage, commit, edit repo source, or implement code as part of board-management mode.
- Never use destructive git commands.
- Do not put secrets, credentials, tokens, or private keys in task prompts.
- Prefer current CLI `--help` output over examples in this skill if flags or behavior differ.

## Workspace

Always prefer `--project-path` so operations target the intended board.

Choose the project path this way:

- If the user gives a workspace path, use it.
- If the current working directory is inside `.cline/worktrees/`, use the main workspace path instead of the worktree path.
- Otherwise use the repository or workspace root that owns the requested board.

Kanban stores all board state globally under `~/.cline/kanban/workspaces/`. Each workspace has its own directory there, containing its board, session, and metadata state. Prefer the Kanban CLI for normal operations; inspect that location only when diagnosing persisted board or session state.

Use the command prefix alone to check whether the Kanban runtime is available:

```bash
kanban
```

If the runtime is unavailable, tell the user to start Kanban with that prefix alone and retry.

## Core Commands

Inspect help when uncertain:

```bash
kanban --help
kanban task --help
```

Use these task commands:

```bash
kanban task list --project-path "$PROJECT_PATH"
kanban task create --project-path "$PROJECT_PATH" ...
kanban task update --project-path "$PROJECT_PATH" ...
kanban task start --project-path "$PROJECT_PATH" ...
kanban task done --project-path "$PROJECT_PATH" ...
kanban task delete --project-path "$PROJECT_PATH" ...
kanban task link --project-path "$PROJECT_PATH" ...
```

Recommended agent override values:

```bash
--agent-id claude|antigravity|default
```

Use Claude Code as the default implementation agent. Its model choices are discovered live from the configured Claude Code gateway rather than copied into this skill. Choose the inherited Claude Code configuration unless the task needs a specific discovered model; use the available effort choices for the selected model.

Use Antigravity when its installed `agy` CLI is appropriate for the task. Its model and effort choices are discovered from the local CLI; do not hard-code model names or effort values in task prompts.

The current task CLI exposes only the agent override. When a specific Claude Code or Antigravity model/effort is requested, create or update the task with the appropriate `--agent-id`, then set the discovered model and effort in the Kanban task settings.

## Model selection and routing

Discover available models and supported effort levels from the running Kanban service and the selected agent's CLI. Use the inherited configuration unless the user requests a specific available model. Choose a small model for isolated work and increase capability when ambiguity, failed verification, or cross-module changes justify it. Do not publish or rely on a fixed gateway catalog.

Auto-review flags:

```bash
--auto-review-enabled true --auto-review-mode commit|pr
```

Use auto-review only when the user explicitly asks for autonomous commit or PR behavior.

## Operating Procedure

Run `task list` before operations that require task IDs. Confirm with `task list` after create, update, link, start, or other state-changing operations.

For create and update, make the task prompt implementation-ready. Include:

- Goal
- Context
- Relevant files or areas
- Implementation notes
- Acceptance criteria
- Verification commands or checks
- Risks and boundaries
- Handoff expectations

Preserve the target repository's `AGENTS.md` rules and existing architecture boundaries in every task prompt.

## Task Routing

When the user asks to offload a task, inspect the backlog and pick the most bounded, implementation-ready item. Prefer tasks with clear acceptance criteria, limited file scope, and low architectural ambiguity.

Set the task agent override to Claude Code by default:

```bash
--agent-id claude
```

Use Antigravity only when the user asks for it or when it is clearly better suited to the task and its local CLI is available:

```bash
--agent-id antigravity
```

For either agent, discover models and supported effort levels from the running Kanban service at execution time. Never put static gateway model catalogs into this skill; they change with the configured provider.

Only start, run, or offload the task when the user asks to start, offload, or run it. If the user only asks to set the override, update the card and leave it unstarted.

## Dependencies

Use `task link` for dependencies.

If both tasks are backlog items, treat `--task-id` as the task that waits on `--linked-task-id`. Run `task list` first to confirm both IDs, then run `task link`, then run `task list` again to verify the relationship.

Use links actively when deciding task order:

- Start linked prerequisite cards before dependent cards unless the user explicitly wants speculative parallel work.
- If linked cards run in parallel, review and integrate prerequisites first, then reconcile dependent work against the accepted prerequisite state.
- Use links to document architectural or data-flow dependencies even when separate worktrees make file-level conflicts unlikely.
- Do not treat links as merge automation; they are ordering and reconciliation signals for coordinator review.

## Response Style

Report the exact task IDs affected, the operation performed, and any notable CLI output. If an operation could not be completed, include the command attempted and the next concrete retry step.