Command reference

Usage:

kanbn ......... Show help menu

Where <command> is one of:

help .......... Show help menu

version ....... Show package version

init .......... Initialise kanbn board

board ......... Show the kanbn board

boards ........ List the boards in this workspace

task .......... Show a kanbn task

add ........... Add a kanbn task

edit .......... Edit a kanbn task

rename ........ Rename a kanbn task

move .......... Move a kanbn task to another column

comment ....... Add a comment to a task

remove ........ Remove a kanbn task

find .......... Search for kanbn tasks

status ........ Get project and task statistics

sort .......... Sort a column in the index

sprint ........ Start a new sprint

burndown ...... View a burndown chart

gantt ......... View a gantt chart

validate ...... Validate index and task files

archive ....... Archive a task

restore ....... Restore a task from the archive

remove-all .... Remove the kanbn board and all tasks

history ....... Show task history

contributors .. List the workspace's contributors

completion .... Set up tab completion for your shell

For more help with commands, try:

Show package version.

Initialise a kanbn board in the current working directory.

Options:

Initialise a kanbn board interactively.

Initialise a kanbn board with the specified name.

Initialise a kanbn board with the specified description.

Initialise a kanbn board and add the specified column. This option can be repeated to add multiple columns.

Create a secondary board beside the main one, at .kanbn/board-slug.md. Secondary boards

share the main board's task folder, so a task can appear on several boards, in a different

column on each. Combine with -n, -d and -c to set the board's name,

description and columns:

Running it again on an existing board updates its name, description and columns, exactly as

kanbn init does for the main board. A new board only picks up the default started and

completed columns if it actually has columns by those names, so a board with its own workflow

doesn't silently inherit "In Progress" and "Done".

The workspace has to exist first - run kanbn init with no -b to create it.

Show the kanbn board.

Options:

Show the specified board view. Views are defined in the "views" project option and can re-arrange, filter, sort and group tasks without moving them between columns.

See docs/views.md for the view format and worked examples.

Output raw data instead of rendering the board. The data will be returned in JSON format.

This is the quickest way to check what a view's filters actually match.

Target a board other than the main one. Falls back to the KANBN_BOARD environment variable and

then to the defaultBoard option. See kanbn boards for the list of boards.

Simple tasks - lines in a column that aren't task links - are shown dimmed at the end of their

column. They only appear in the default layout: a view filters and sorts tasks, and a simple task

has no fields to filter or sort on. They are left out of --json for the same reason.

List the boards in this workspace.

A board is a markdown file directly inside the kanbn folder, in the same format as the index. The

index file is the main board; every other markdown file beside it is a secondary board. All boards

share one task folder, so a task can appear on several boards, in a different column on each.

Create a board with kanbn init -b "board-slug", and target one with -b "board-slug" on

any board-scoped command.

Options:

Show every task that appears on more than one board, with the column it occupies on each.

Show every tracked task, not only the ones on more than one board.

Rename a board. The positional argument is the new slug, and --name sets the display name:

Either the new slug or --name may be omitted, but not both. The main board can't be renamed.

Delete a board file. Task files are never deleted, but tasks referenced only by this board become

untracked - if that would happen, the tasks are listed and -f is required to go ahead.

Output the board list, or the cross-board task overview, in JSON format.

Show information about a kanbn task.

Options:

Show task information in JSON format.

Target a board other than the main one. Falls back to the KANBN_BOARD environment variable and

then to the defaultBoard option. See kanbn boards for the list of boards.

A simple task - a line in a column that isn't a task link - has no task file to show, so this

reports which column it's in and how to promote it.

Create a new task and add it to the index.

Options:

Create a new task or add untracked tasks interactively.

Create a new task with the specified name. This option is required if not adding a task interactively.

Create a new task with the specified description.

Create a new task and add it to the specified column in the index. If this is not specified, the task will be added to the first available column.

Create a new task and set the due date. The date can be in (almost) any format.

Create a new task and set the planned start date used for gantt scheduling. The date can be in (almost) any format.

Create a new task and set the planned finish date used for gantt scheduling. The date can be in (almost) any format.

Create a new task and set its progress. This should be a number between 0 (not started) and 1 (complete).

Create a new task and set the assigned user name. If this option is left blank, the task is assigned to the current user.

The current user comes from KANBN_USER or your git identity, canonicalised against the contributors list if the workspace has one - see kanbn contributors --help.

Create a new task with a sub-task. The sub-task text can be prefixed with "[ ] " or "[x] " to set the completion status.

Create a new task with a tag.

Create a new task with a relation. The relation should be an existing task id, optionally prefixed with a relation type.

Examples:

"blocks my-task-1"

"duplicates my-task-2"

Create a new task with a custom metadata field.

The custom field must be declared in the customFields project option.

Find all untracked tasks and add them to the index. If a column name is not specified, the tasks will be added to the first column.

Add untracked tasks in the specified file(s) to the the index. This option can be repeated to add multiple files.

Examples:

Creates a task with id "my-task-1" in column "Todo" with a completed sub-task, 2 tags, and a "duplicates" relation to "my-task-2".

Interactively adds untracked tasks "my-task-3.md" and "my-task-4.md" to the "Done" column.

Add the task to a board other than the main one. This option can be repeated to put one task on

several boards at once - the task file is created once and every board named references it:

Each -b pairs with the -c in the same position; boards with no -c of their own

use the first one given, and a board that hasn't got that column falls back to its first column

with a notice. With a single board an unknown column is still an error.

Boards can declare actions - rules that fire when a task changes, e.g. "when this enters In

Progress, assign it to me and tag it active". See docs/actions.md.

Run without firing any action rules. KANBN_NO_ACTIONS=1 does the same for a whole shell.

Edit an existing task and set its 'updated' date. This command can be used to rename and move tasks as well.

Options:

Edit a task interactively.

Modify a task name.

Modify a task description.

Move a task to a different column.

Modify a task due date. The date can be in (almost) any format.

Modify the planned start date used for gantt scheduling. The date can be in (almost) any format.

Modify the planned finish date used for gantt scheduling. The date can be in (almost) any format.

Modify a task's progress. This should be a number between 0 (not started) and 1 (complete).

Modify a task assigned user name. If this option is left blank, the task is assigned to the current user.

The current user comes from KANBN_USER or your git identity, canonicalised against the contributors list if the workspace has one - see kanbn contributors --help.

Remove a sub-task.

Add or modify a sub-task. The sub-task text can be prefixed with "[ ] " or "[x] " to set the completion status.

Remove a tag.

Add a tag.

Remove a relation.

Add or modify a relation. The relation should be an existing task id, optionally prefixed with a relation type.

Examples:

"blocks my-task-1"

"duplicates my-task-2"

Remove a metadata field from a task. This option can be repeated to remove several fields.

Available fields: started, completed, due, plannedStart, plannedFinish, assigned, progress, tags,

plus any custom fields declared in the customFields project option.

Examples:

Reopen a completed task by clearing its completed date.

Clear both dates.

A field cannot be set and unset in the same command. If a task is moved into a started or

completed column by the same command, the unset is applied afterwards, so it wins.

Add or modify a custom metadata field.

The custom field must be declared in the customFields project option.

Remove a custom metadata field.

Target a board other than the main one. Falls back to the KANBN_BOARD environment variable and

then to the defaultBoard option. See kanbn boards for the list of boards.

Editing a simple task - a line in a column that isn't a task link - promotes it to a real task

file first, and then applies the edit. The new task is created in the column the line was in,

with a created date as of the promotion. There is no way back.

Boards can declare actions - rules that fire when a task changes, e.g. "when this enters In

Progress, assign it to me and tag it active". See docs/actions.md.

Run without firing any action rules. KANBN_NO_ACTIONS=1 does the same for a whole shell.

Rename a task. This will change the task filename and update the index. The task 'updated' date will also be set.

Options:

Rename a task interactively.

Rename the task with the specified name. This option is required if not renaming a task interactively.

Target a board other than the main one. Falls back to the KANBN_BOARD environment variable and

then to the defaultBoard option. See kanbn boards for the list of boards.

Move an existing task to a different column or position. The task 'updated' date will also be set.

Options:

Move a task interactively.

Move the task to this column in the index. If this option is not specified, the task will remain in its current column.

Move the task to a specific position in the target column. If this option is not specified, the task will be moved to the end of the target column.

Move the task to a position relative to its current position in the target column.

When specifying a negative value for N, the negative sign can be escaped with '/' or '\\' to prevent the value being recognised as an option. For example:

Move the task on a board other than the main one. If the task isn't on that board yet it is

added, with a notice - so pulling work onto a board is one command rather than two.

Refuse to move a task that isn't on the target board, instead of adding it.

The main board never adds implicitly: moving an untracked task there is an error either way.

Simple tasks - lines in a column that aren't task links - can be moved too, by title:

Move a simple task to another column. The title matches exactly, ignoring case, or slugified.

A real task with the same id always wins. Leave off -c to reposition it in its own column.

Move a simple task onto another board. A simple task is content in one board file rather than a

shared task file, so this moves the line: it leaves this board and joins the other one.

Boards can declare actions - rules that fire when a task changes, e.g. "when this enters In

Progress, assign it to me and tag it active". See docs/actions.md.

Run without firing any action rules. KANBN_NO_ACTIONS=1 does the same for a whole shell.

Add a comment to a task.

Options:

Add a comment interactively.

Set the comment author. If this option is left blank or omitted, the current user is used, and the comment has no author at all if there isn't one.

The current user comes from KANBN_USER or your git identity, canonicalised against the contributors list if the workspace has one - see kanbn contributors --help.

Set the comment text.

Target a board other than the main one. Falls back to the KANBN_BOARD environment variable and

then to the defaultBoard option. See kanbn boards for the list of boards.

Boards can declare actions - rules that fire when a task changes, e.g. "when this enters In

Progress, assign it to me and tag it active". See docs/actions.md.

Run without firing any action rules. KANBN_NO_ACTIONS=1 does the same for a whole shell.

Remove an existing task. This deletes the task file and its index entry. A partial id (a unique

prefix or part of the id) is resolved to the task it matches, and the confirmation prompt names it.

Options:

Only remove the task from the index. The task file will not be deleted.

Force remove the task without asking for confirmation.

Remove the task from that board. Combine this with --index to remove it from that board

only - boards own membership, so the task file and its entries on every other board are

untouched.

Task files are shared between boards, so deleting one while another board still references it is

refused. This removes the task from every board that references it, then deletes the file.

Remove a simple task - a line in a column that isn't a task link - by title. There is no file to

delete and nothing to archive, so --index and --all-boards don't apply.

Boards can declare actions - rules that fire when a task changes, e.g. "when this enters In

Progress, assign it to me and tag it active". See docs/actions.md.

Run without firing any action rules. KANBN_NO_ACTIONS=1 does the same for a whole shell.

Search all tasks in the index and show search results. If no filters are specified, this command will list all tracked tasks.

String search terms are treated as case-insensitive regular expressions.

Date filters match a single day, or a range if the option is repeated.

Numeric filters match a single value, or a range if the option is repeated.

Only tasks that match all of the filters will be returned.

Filters ignore hidden columns - use --column to exclude them.

See docs/filtering-and-sorting.md for a full description of the filter model.

Options:

Build search filters interactively.

Only show task ids in the output.

Output results in JSON format. If used with the --quiet option, this will return an array of task ids.

Find tasks that have an id containing "search term".

Find tasks that have a name containing "search term".

Find tasks that have a description containing "search term".

Find tasks that are in a specific column. This option can be repeated to find tasks in any one of multiple columns.

Find tasks that were created on a specific date. The time part of the date will be ignored, unless searching between multiple dates.

This option can be repeated - if multiple dates are specified, find tasks that were created between the earliest and latest dates.

The date can be in (almost) any format.

Find tasks that were updated on a specific date. The time part of the date will be ignored, unless searching between multiple dates.

This option can be repeated - if multiple dates are specified, find tasks that were updated between the earliest and latest dates.

The date can be in (almost) any format.

Find tasks that have a started date that matches the specified date. The time part of the date will be ignored, unless searching between multiple dates.

This option can be repeated - if multiple dates are specified, find tasks that were started between the earliest and latest dates.

The date can be in (almost) any format.

Find tasks that have a completed date that matches the specified date. The time part of the date will be ignored, unless searching between multiple dates.

This option can be repeated - if multiple dates are specified, find tasks that were completed between the earliest and latest dates.

The date can be in (almost) any format.

Find tasks that are due on a specific date. The time part of the date will be ignored, unless searching between multiple dates.

This option can be repeated - if multiple dates are specified, find tasks that are due between the earliest and latest dates.

The date can be in (almost) any format.

Find tasks that have a planned start date that matches the specified date. The time part of the date will be ignored, unless searching between multiple dates.

This option can be repeated - if multiple dates are specified, find tasks with a planned start date between the earliest and latest dates.

The date can be in (almost) any format.

Find tasks that have a planned finish date that matches the specified date. The time part of the date will be ignored, unless searching between multiple dates.

This option can be repeated - if multiple dates are specified, find tasks with a planned finish date between the earliest and latest dates.

The date can be in (almost) any format.

Find tasks assigned to a specific user. Use "^$" to find unassigned tasks, and @me for tasks assigned to you.

Find tasks with a specific calculated workload.

If multiple values are specified, find tasks with a workload between the lowest and highest inputs.

Find tasks with a specific progress value (between 0 and 1).

If multiple values are specified, find tasks with progress between the lowest and highest inputs.

Find tasks that are (or are not) overdue. A task is overdue if it has a due date in the past and

hasn't been completed. A task with no due date is never overdue.

Find tasks that do (or don't) have a started date in their metadata.

Find tasks that do (or don't) have a completed date in their metadata.

Find tasks that are (or aren't) in one of the board's startedColumns. If the board declares no

startedColumns, no task is in a started column.

Find tasks that are (or aren't) in one of the board's completedColumns.

Find tasks that have sub-tasks matching the search term.

Find tasks that have a specific number of sub-tasks.

If multiple counts are specified, find tasks with a number of sub-tasks between the lowest and highest inputs.

Find tasks that have tags matching the search term.

Find tasks that have a specific number of tags.

If multiple counts are specified, find tasks with a number of tags between the lowest and highest inputs.

Find tasks that have relations matching the search term.

Find tasks that have a specific number of relations.

If multiple counts are specified, find tasks with a number of relations between the lowest and highest inputs.

Find tasks that have comments matching the search term.

Find tasks that have a specific number of comments.

If multiple counts are specified, find tasks with a number of comments between the lowest and highest inputs.

Find tasks with a custom metadata field that matches the search filter.

The custom field must be declared in the customFields project option.

If the custom field is a string and multiple filters are specified, find tasks with a value that matches one of the inputs.

If the custom field is numeric and multiple filters are specified, find tasks with a value between the lowest and highest inputs.

If the custom field is a date and multiple filters are specified, find tasks with a value between the earliest and latest dates.

If the custom field is a boolean, use --<custom field name> to match true and --no-<custom field name> to match false.

Examples:

Find tasks assigned to exactly "Ana" that are in either the "Todo" or "In Progress" column.

Find tasks with the exact tag "Bug" that are due in July 2026.

Tags are matched against a newline-separated list, so anchoring on line breaks matches a whole tag.

List the ids of tasks that have sub-tasks but no progress yet.

List the ids of overdue tasks that nobody has picked up yet.

Target a board other than the main one. Falls back to the KANBN_BOARD environment variable and

then to the defaultBoard option. See kanbn boards for the list of boards.

Search every board in the workspace. A task on several boards appears once, annotated with the

board and column it occupies on each. Without this, the search is scoped to the target board.

Computed values are evaluated per board, so a task matches --in-started-column if it is in

a started column on any of them.

This can't be combined with --sprint: sprint numbers and names are relative to one board's

list, so there is no sensible answer across several.

Show status information for the current project.

Options:

Only show a count of tasks in each column, without loading all tracked tasks.

If used with the --untracked option, only show a list of untracked task filenames.

Output status information in JSON format.

Show a list of untracked task filenames. "Untracked" is workspace-scoped: a task is tracked if

any board references it, so this lists task files that are on no board at all.

When other boards track tasks that the target board doesn't, they're listed separately under

tasksOnOtherBoards, with the column each one occupies - the "what could I pull onto this

board" list.

Check for overdue tasks and include time remaining information in the output.

Show sprint workload for a specific sprint.

The sprint can be selected by number or name.

This option will be ignored if the --quiet option is set or if no sprint options are defined in the index.

Show task workloads for a specific date. The time part of the date will be ignored, unless searching between multiple dates.

This option can be repeated - if multiple dates are specified, show task workloads for tasks between the earliest and latest dates.

The date can be in (almost) any format.

This option will be ignored if the --quiet or --sprint options are set.

Target a board other than the main one. Falls back to the KANBN_BOARD environment variable and

then to the defaultBoard option. See kanbn boards for the list of boards.

Sort a column in the index. The "column" value is optional if sorting a column interactively.

Some task attributes can be optionally transformed using case-insensitive regular expressions.

If a filter is specified, the matched text will be used when sorting.

If the filter regular expression has numbered capturing groups, the value of the first group will be used.

If the filter regular expression has named capturing groups, the value of all named groups will be concatenated.

If there are multiple matches, their values will be concatenated.

See docs/filtering-and-sorting.md for a full description of the sorting model.

Options:

Sort a column interactively.

Save the column sort settings in the index file (as a columnSorting option). This means that any tasks added to the column will be automatically sorted.

If this option is not set, the column is sorted once and any saved sorting settings for the specified column will be removed.

Sort the column in ascending order. This is the default order. This option can be set after each sorting field. If this option is set before any sorting fields, all fields will be sorted in ascending order.

Sort the column in descending order instead of default ascending order. This option can be set after each sorting field. If this option is set before any sorting fields, all fields will be sorted in descending order.

Sort tasks by id.

Sort tasks by name.

Sort tasks by description.

Sort tasks by created date.

Sort tasks by updated date.

Sort tasks by started date.

Sort tasks by completed date.

Sort tasks by due date.

Sort tasks by planned start date.

Sort tasks by planned finish date.

Sort tasks by assigned user name.

Sort tasks by progress.

Sort tasks by sub-tasks.

Sort tasks by the number of sub-tasks.

Sort tasks by tags.

Sort tasks by the number of tags.

Sort tasks by relations.

Sort tasks by the number of relations.

Sort tasks by comments.

Sort task by the number of comments.

Sort tasks by workload.

Sort tasks by whether they are overdue. Ascending puts overdue tasks last.

Sort tasks by whether they have a started date in their metadata.

Sort tasks by whether they have a completed date in their metadata.

Sort tasks by whether they are in one of the board's startedColumns.

Sort tasks by whether they are in one of the board's completedColumns.

Sort tasks by a custom field value.

Examples:

Sort tasks in the "Todo" column first by created date in descending order, then by their name (filtered such that only numeric characters after the string "Task " are used) in ascending order, then by workload in ascending order

Sort tasks in the "Todo" column first by name, then by the number of tags, all in descending order

Sort tasks in the "Todo" column so that overdue tasks come first, then by due date in ascending order

Target a board other than the main one. Falls back to the KANBN_BOARD environment variable and

then to the defaultBoard option. See kanbn boards for the list of boards.

Start a new sprint.

Options:

Start a new sprint interactively.

Start a new sprint with the specified name.

Start a new sprint with the specified description.

Add a sprint from the context of another board. Sprints are workspace-level by default, so this

appends to the workspace list and says so. A board that declares its own sprints in its

front matter gets the sprint appended there instead, auto-named {Board name} Sprint {n} so

that two boards' sprints can't be confused.

A board with its own list can't see the workspace sprints at all - that's the cost of forking,

and it's why forking is a deliberate front-matter edit rather than a flag.

Show a burndown chart between a date range, or for a particular sprint.

If no dates or sprint identifiers are specified, show data for the current sprint.

If no sprints are defined, show data from the earliest created date to the current date.

Burndown data source:

When a task has a structured `History` section, burndown uses its lifecycle events (created, moved, progress, archived, restored) to reconstruct task activity over time.

For older tasks without history, burndown falls back to metadata/date inference (created/started/completed + startedColumns/completedColumns).

Options:

Output raw data instead of rendering a chart. The data will be returned in JSON format.

Show burndown data for the specified sprint. This option can be repeated to show burndown data for multiple sprints.

Show burndown data for the specified dates.

If only one date is provided, show burndown data from this date up to the present date.

If more than 2 dates are provided, show burndown data from the earliest to latest date.

This option will be ignored if a valid sprint number or name is specified.

Filter for tasks in a particular column. This option can be repeated to include multiple columns.

Filter for tasks that are assigned to a particular user.

Normalise dates. Task event times (history events or legacy created/started/completed dates) will be rounded down to the nearest day, hour, minute or second. This may cause task events to be grouped together.

If this option is set to a blank or unsupported value, the normalisation mode will be automatically selected based on the date range.

Chart a board other than the main one. Burndown measures work in flight, so a board that

declares no startedColumns has nothing to chart and says so rather than drawing an empty

chart.

Show a gantt chart for tracked tasks.

Tasks are ordered using `depends-on` relations when present. The chart prioritizes optional `plannedStart`/`plannedFinish` metadata when arranging bars, then falls back through `started`/`completed` dates, and finally uses workload-based best-effort scheduling when no timeline dates are available.

The rendered chart includes:

Dependency arrows (└─→) showing which tasks depend on others

A blocked indicator (⧗) showing tasks delayed by dependencies

Options:

Output raw data instead of rendering a chart. The data will be returned in JSON format.

Filter for tasks that are assigned to a particular user.

Filter for tasks in a particular column. This option can be repeated to include multiple columns.

Filter for tasks created within a specified date range.

If only one date is provided, show tasks created from this date up to the present date.

If more than one date is provided, show tasks created between the earliest and latest date.

Mock the current date used for the "now" line and single-date range filtering.

Target a board other than the main one. Falls back to the KANBN_BOARD environment variable and

then to the defaultBoard option. See kanbn boards for the list of boards.

Validate kanbn index file and all task files, and report any formatting errors.

If the files are valid, this also reports tasks whose started/completed dates don't match the column

they're in - which usually means the task was moved by hand or by a merge, rather than through kanbn.

It also lists any line in a column that isn't a task link. Those lines are kept in the board file and

ignored by every other command, so this is information rather than a problem - except for a line that

looks like a task link with a typo in it, or one naming a task file that exists, both of which mean a

task isn't being tracked when it probably should be.

Options:

Re-save the index and task files. This will ensure that all index column sorting settings are applied and that all tasks are formatted correctly.

Fill in missing started and completed dates for tasks that are sitting in a started or completed

column without one. Each date is taken from the task's history where the move was recorded,

falling back to the task's updated date and then its created date.

Tasks that have a completed date while sitting outside a completed column are reported but never

changed, because the date records something that actually happened. Use

kanbn edit "task-id" --unset completed to clear one deliberately.

Output validation errors in JSON format. When there is nothing to report beyond date drift this

is the bare list of drift entries; when there are warnings as well - or the workspace has more

than one board - it is an object with drift and warnings keys.

Target a board other than the main one. Falls back to the KANBN_BOARD environment variable and

then to the defaultBoard option. See kanbn boards for the list of boards.

Validate every board in the workspace and the tasks each of them references, rather than just

the target board.

In a workspace with more than one board, validate also reports multi-board warnings - a

workspace-scoped option in a board file, several boards stamping the same shared date, sprints out

of order, a task on no board at all, history naming a board that has been deleted, and markdown

files beside the boards that don't parse as one. These are warnings, not errors: each describes a

workspace that still works, just not the way its author probably meant it to.

Action rules are checked too. A rule that names an unknown event or verb, moves to a column that

doesn't exist, or writes a field Kanbn manages is an error - the same commands that would have

run it fail before writing anything. Rules that work but probably don't do what they look like -

two rules writing the same field on the same event, or @me where no user can be resolved - are

reported as warnings.

Move an existing task to the archive. The task's column will be stored in the task metadata.

Options:

Move a task to the archive. A partial id (a unique prefix or part of the id) asks for

confirmation before archiving the task it matched.

Don't ask for confirmation when a partial id is matched.

Show a list of archived task filenames.

Target a board other than the main one. Falls back to the KANBN_BOARD environment variable and

then to the defaultBoard option. See kanbn boards for the list of boards.

Boards can declare actions - rules that fire when a task changes, e.g. "when this enters In

Progress, assign it to me and tag it active". See docs/actions.md.

Run without firing any action rules. KANBN_NO_ACTIONS=1 does the same for a whole shell.

Restore an archived task from the archive.

Options:

Restore a task from the archive and place it in the task's original column.

Restore a task from the archive and place it in the specified column.

Restore the task to that board only. Without this, the task goes back to every board it was on

when it was archived, in the column it occupied on each. A board that has since been deleted is

reported and skipped rather than failing the restore.

Boards can declare actions - rules that fire when a task changes, e.g. "when this enters In

Progress, assign it to me and tag it active". See docs/actions.md.

Run without firing any action rules. KANBN_NO_ACTIONS=1 does the same for a whole shell.

Completely remove the Kanbn directory and all of the contents.

Make sure you have anything that you want to keep backed-up before running this.

Options:

Force delete without asking for confirmation.

Show a chronological listing of task events.

Options:

Output raw history data in JSON format.

Filter history to one or more sprints.

This option can be repeated to include multiple sprints.

Filter history by date.

If one date is provided, show history from this date up to the present date.

If two or more dates are provided, show history from the earliest to latest date.

Filter for tasks assigned to a specific user.

Filter for one or more task ids.

This option can be repeated.

Target a board other than the main one. Falls back to the KANBN_BOARD environment variable and

then to the defaultBoard option. See kanbn boards for the list of boards.

List the people who work on this workspace, and say which of them Kanbn thinks you are.

Contributors are an optional, workspace-scoped list declared in kanbn.yml / kanbn.json, or

in the main board's front matter:

contributors:

- gordon

- dave

- name: sam

displayName: Sam Vimes

email: sam@example.com

aliases:

- Samuel Vimes

- samv

colour: '#7c5cff'

A contributor can be a bare name or an object; only name is required, and it is the value

written into a task's assigned field or a comment's author.

Contributors are advisory. assigned and author stay free text and are never

validated against the list, never rejected and never rewritten - the list makes the common case one

keystroke instead of a retyped name, and makes the names a workspace uses discoverable.

Kanbn resolves "you" in this order, first match wins:

1. the KANBN_USER environment variable, used exactly as given

2. git config user.email matched against a contributor's email

3. git config user.name matched against a contributor's name, displayName or

aliases, ignoring case

4. git config user.name as-is

5. nobody

That value is what kanbn add --assigned and kanbn edit --assigned write when given no

value, what a comment's author defaults to, and what @me expands to in

kanbn find --assigned, kanbn burndown --assigned, kanbn gantt --assigned and

kanbn history --assigned.

Steps 2 and 3 are what canonicalise: on a machine whose git username is "Gordon Larrigan", a

workspace listing gordon with that name as an alias writes gordon into the task file.

With no contributors declared, this is exactly the git username Kanbn has always used.

Options:

Show how many tasks and comments each contributor appears in, and every name used in a task that

isn't a known contributor. This is how you adopt contributors in an existing workspace: it tells

you what to put in the list, and which spellings to add as aliases.

It is read-only. Nothing is rewritten - renaming "Gordon" to "gordon" across every task file is a

bulk mutation and isn't done here.

Output the contributor list, or the usage report, in JSON format.

Print a script that adds tab completion for kanbn to your shell. The shells supported are bash, zsh

and fish.

Commands, options, task ids, columns, boards, tags, assignees and sprints are completed. Task ids and

columns come from the board the command would target - so --board, KANBN_BOARD and the

defaultBoard option are all taken into account.

Options:

Add eval "$(kanbn completion bash)" to ~/.bashrc. bash doesn't complete values that contain

spaces, such as most column names - zsh and fish do.

Add eval "$(kanbn completion zsh)" to ~/.zshrc, after compinit - it does nothing before it.

Or save it as _kanbn in a directory on your $fpath:

Save it where fish looks for completions:

See docs/completion.md for more.