For AI agents

This is the part that makes Kandown different from a task list with an AI feature bolted on, so it is worth two minutes.

The design assumption is simple: an agent is another user of the board, not an integration. It gets the same context you do, through an interface built for how agents actually work: one command that returns everything, and output you can pipe.

One command for context

kandown work

That prints one deterministic document. Its fixed order starts with Kandown's immutable safety core, then real column roles and available commands, enabled extension summaries, the active workflow, tracking cadence, additive skills, global and project instructions, and finally a targeted task context or compact board digest.

One call, full context.

kandown init adds a single line to your AGENTS.md / CLAUDE.md pointing at it, a pointer rather than a block of rules copied in to go stale. That distinction is the whole point: rules that live in the CLI are upgraded when the CLI is upgraded.

Tuning the output

Settings has three tabs: Workflow, Skills, and Kandown Work. A project selects one exclusive workflow and may add compatible skills. Instruction detail and task-tracking cadence are independent. Freely named columns receive semantic roles, and the preview is the exact shared compiler output used by the CLI and agent launcher.

The complete compiler budget remains visible across all three tabs. Read everything opens a full-screen rendered Markdown view of the exact document, with estimated tokens, words and characters. Individual workflow protocols, guides, templates, skills and project instructions also show their estimated token cost. Tokenization varies by model, so Kandown labels these counts as estimates.

The output contract

This is the part that makes Kandown safe to script:

stdout carries data only (ids, JSON, tables). Everything decorative (✓ Created…, warnings, errors) goes to stderr.

So $(kandown create …) captures exactly one id, and --json | jq never chokes on a checkmark. Exit code 0 on success, non-zero on failure.

kandown list --json | jq '.[] | select(.priority=="P1")'

ID=$(kandown create "Refactor auth middleware" -p P1 -t backend)
kandown move "$ID" "In progress"

kandown commit -m "tasks: add auth refactor"

Offline task work

Task commands never contact a registry. Store access is explicit: opening a store or running a store/install/update command may fetch approved GitHub metadata. Workflow packages are pinned to a release or commit, checksum-verified, validated, and updated only after a displayed diff.

The update check that does exist is skipped whenever stdout is not a terminal, so it can never fire in an automated context. Set KANDOWN_NO_UPDATE=1 if you want it gone entirely.

Keeping the board honest

A board an agent writes to is only useful if what it writes is true. Two mechanisms help:

• report: lines on subtasks and the task report field are where an agent records what it actually did. A completed task should read as a work log, not a row of ticks.
• The dependency gate refuses to move a blocked task to the terminal column, from any interface. An agent cannot mark work done that depends on work that is not.

Reading these docs as an agent

This documentation is published as plain Markdown as well as HTML, so an agent does not have to parse a React page to follow an instruction.

All three are generated from the same source as the pages themselves on every deploy, so they cannot fall behind what the site says.

Where to go next

• Project instructions: teaching agents your project's specifics
• Launching agents: handing a task to Claude Code, Codex, Goose and others
• MCP server: driving the board over the Model Context Protocol