Task files are standard Markdown, with a couple of extra wrinkles. The idea
is to have multiple small files for tracking projects, rather than one big
file encompassing everything. It also keeps task files human readable and
human editable.

Individual tasks use an expanded form of the GitHub style of task list:

    - [ ] open, this task is outstanding
    - [/] in progress, this task is partially complete
    - [X] complete, this task has been finished
    - [#] cancelled, this task has been abandoned
    - [<] blocked, this task needs more input

Tasks can span multiple lines as long as the continuation is indented to match:

    - [ ] Lorem ipsum dolor sit amet,
          consectetur adipisicing elit.

Markdown emphasis is used to indicate prioritisation (normal, medium, high).
It can be placed on individual tasks, or on a header to spread the
prioritisation to every task under that header.

    # Stuff to do
    - [ ] _a medium importance task_
    - [ ] normal priority task

    # **High importance tasks**
    - [ ] automatically high priority

To give a task a deadline, put @YYYY-MM-DD (or @YYYY-MM-DD/3d) at the end.
Tasks become "imminent" when the date is near (two weeks by default, or
specified with the /modifier which can use d=days or w=weeks), which raises
the priority above normal but below medium and high. Overdue tasks have the
highest prioritisation.

Add @after to files, sections, or individual tasks to hide tasks inside until
all other tasks are complete, or include optional filename(s) to wait for a
subset. Prioritisation does not stop the task being ignored.

    # First
    - [ ] do the thing

    # Later @after
    - [ ] **do this last**

To write about @after or deadlines without them being parsed, use backticks
(`@after`) or a backslash (\@after).

For sequential work where each individual task in the file can only be done
after the previous tasks are complete, add @queue and output is limited to the
next available most important task.

    @queue
    - [ ] backup production database
    - [ ] run migration to add audit columns
    - [ ] backfill audit data from logs

To separate logical blocks of a single file so that each group of tasks will
only be shown when previous groups are complete, use @phase on the headers.

    # Red @phase
    - [ ] add/amend tests to assert desired behaviour
    - [ ] prove new tests fail
    # Green @phase
    - [ ] update code to implement desired behaviour
    - [ ] prove tests pass

Context around tasks, such as detailed decision notes and designs can be
included in the document without showing in the task list. To include a
short note in the summary, use special fence blocks:

    # Tasks
    Explanatory text. Only seen when editing the task file.

    ```whatnext
    Extra context you might need to understand the task description.
    ```

    - [ ] do the thing

Files can be excluded from search results by either adding "@notnext" to a
line by itself anywhere in the file:

    # Task template
    @notnext

    - [ ] first task
    - [ ] second task

...or by adding it to the `.whatnext` file in the project root:

    ignore = [
        'README.md',
        'docs/usage.md',
    ]
