Taskwarrior
Light documentation for the CLI task management programUsage
Commands
The general command structure looks as follows:
task <filter> <command> [<modifications> | <args>]
A <filter>
is something that matches one or more tasks, such as a single task ID, a +<tag>
, a metadata attribute, etc. A <command>
is an action to be taken on the group of tasks within the filter, such as list
, show
, modify
, etc. When modify
is used, the <modifcations>
are the key: value
pairs of new attribute values. The <misc>
accounts for arbitrary arguments to certain commands e.g. task show report.list.filter
. A few concrete examples of basic commands include:
task 1 delete
: filters out task 1 and runsdelete
command to remove the task.task 2 modify priority:H, due:TOMORROW, status:pending
: filters out task 2, runs modify command, and accepts three property modifications to the task.task +tag status:started modify priority:H due:TODAY
: this command uses a compound filter to select all tasks with the+tag
tag and have astarted
status, and changes their priority to high and sets their due date to today.
This command structure is easy to remember and extremely flexible, making it simple to perform most changes to your task list. The following list gives a few concrete <command>
keywords and their descriptions:
task add <attr> <description>
: adds a tasktask <filter> list
: show list of current tasks. Note this impliesstatus:pending
filter to the results.task <filter> done
: set tasks matching<filter>
to donetask [next]
: next is the default command when callingtask
, shows tasks by what show be done “next” (i.e. those with greatest urgency)task <filter> start
: applies a “start” date to a task, making it active. Note that this is not astatus
attribute, but rather its own separate attribute. Active tasks get a bump in urgency, as they’re essentially a step above “pending” tasks. Note that by default Taskwarrior just records this tart time as a static attribute; there’s no actual time tracking capabilities. However, there are hooks that can be linked to Timewarrior, which can track the time spent on a task from start to stop. This is outside the scope of this guide, but worth looking into.task <filter> stop
: opposite of above, stops a tasks and removes it from being active.task <filter> all
: apply filter to all tasks recorded by the system. A common usage would be to see completed tasks withtask status:completed all
, whereas usingtask list
will return zero results because it applies apending
filter first. Can also filter deleted tasks withstatus:deleted
.
Attributes
As has been mentioned above, tasks can have a number of attributes. Here are the categories and their respective options:
priority:[L,M,H]
: sets low, medium, or high priorityproject:<name>
: set the tasks assigned project, can be any string- Seems you can create subprojects by having the project name be
<proj>.<subproj>
- Seems you can create subprojects by having the project name be
due:<date>
: sets the task due date. Can be any date stringYYYY-MM-DD
or with included timeYYYY-MM-DDTHH:MM:SS
, or one of the date keywords likeTODAY
,TOMORROW
, etc.scheduled:<date>
: sets a scheduled date, i.e. when the task is to be worked on (not necessaily due). Once scheduled date has passed, that task is considered “ready”.wait:<date>
: set a date before which the task is hidden from viewuntil:<date>
: set the last date the task should be looked at, and destroy the task after the date passes.status:<status>
: sets current status of task. Can be- pending: task’s typical “in-between” state, not deleted or completed
- deleted: deleted task
- completed: removed from pending state, task is done
- waiting: a “hidden pending” task, waiting out of view until
wait
date reached - recurring: essentially a template task from which child tasks are cloned according to recurrence specified
Syncing tasks
According to the official Taskwarrior documentation, a Taskserver is recommended for syncing tasks across machines. This makes sense; there’s some complexity behind merging tasks when machines’ task data don’t quite line up properly, and this would be especially important when multiple people are working on the same task database at the same time.
For me, however, I know I’ll be the only person managing my tasks, and going through the hassle of setting up a taskserver doesn’t really make sense when I can just sync my taskwarrior files to Nextcloud Every time I work with tasks on my desktop, my task data will be synced up to all my other devices. By the time I’d be switching to another machine everything should already be synced; no merges ever need to happen, and it’s totally okay that the “last commit wins”. This assumes that the Nextcloud syncing process stays slightly faster than the time it takes me to switch machines. (This could be an issue if I were to start making changes on one of my machines before I allowed Nextcloud to sync up, but over the last 6+ months of this setup I’ve never had a conflict.)