Taskwarrior

Light documentation for the CLI task management program

Usage

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 runs delete 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 a started 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 task
  • task <filter> list: show list of current tasks. Note this implies status:pending filter to the results.
  • task <filter> done: set tasks matching <filter> to done
  • task [next]: next is the default command when calling task, 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 a status 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 with task status:completed all, whereas using task list will return zero results because it applies a pending filter first. Can also filter deleted tasks with status: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 priority
  • project:<name>: set the tasks assigned project, can be any string
    • Seems you can create subprojects by having the project name be <proj>.<subproj>
  • due:<date>: sets the task due date. Can be any date string YYYY-MM-DD or with included time YYYY-MM-DDTHH:MM:SS, or one of the date keywords like TODAY, 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 view
  • until:<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.)

Sources