| name | jd-task-manager |
| description | Manage tasks in Johnny.Decimal systems using the jdtodo.txt format — parsing, creating, completing, cancelling, and modifying tasks stored in todo.txt files at the 00.02 Tasks location. Use this skill when the user wants to manage their tasks, add a todo, complete a task, check what's due, review their task list, or says things like "show my tasks," "what's due today," "add a task," "mark that done," "what should I work on," "complete this task," "cancel that task," "show overdue tasks," "what's on my plate," "review my someday list," "show blocked tasks," or "what tasks are due this week." Also trigger when the user says "manage my todos," "update my task list," "process my tasks," or references todo.txt or jdtodo.txt.
|
Johnny.Decimal Task Manager
This skill manages tasks in Johnny.Decimal systems using the jdtodo.txt
plain-text format. It reads, creates, completes, cancels, and modifies tasks
stored in todo.txt files within 00.02 Tasks/ folders. It also handles
done.txt (completed and cancelled tasks) and someday.txt (deferred items).
Before processing, read references/jdtodo-spec.md for the complete jdtodo.txt
format specification.
1. Orientation: Discover the JD Environment
Before touching any files, build a mental map of the user's JD setup.
1.1 Locate the JD Root
The JD root folder is wherever the user's systems live. Common locations:
~/Library/Mobile Documents/com~apple~CloudDocs/JD/ (iCloud Drive)~/Documents/JD/~/JD/- A project-specific folder the user designates
If you don't know the root, ask the user. If the user says "show my tasks"
without further context, check the most common locations above. If you find
exactly one, confirm it. If you find multiple or none, ask.
1.2 Identify Systems
List the top-level folders under the JD root. Each folder whose name matches
the pattern [A-Z][0-9][0-9] * is a JD system (e.g., P10 Personal,
W20 Work, C40 Citywide).
If the user has a single system (no SYS prefix), treat the entire JD root as
one system.
1.3 Load Each System's JDex
For every system you'll work with, read the JDex file at:
SYS/00-09 */00 */00.00 *JDex*
The JDex is needed to validate JD codes on tasks and to display human-readable
descriptions alongside +AC.ID references. If the JDex is missing, you can
still manage tasks but cannot validate JD code references — flag this to the
user.
1.4 Locate Task Files
For each system, look for task files at:
SYS/00-09 */00 */00.02 Tasks*/todo.txt
SYS/00-09 */00 */00.02 Tasks*/done.txt
SYS/00-09 */00 */00.02 Tasks*/someday.txt
Legacy detection: If a file named 00.02 Tasks.md exists (instead of a
00.02 Tasks/ directory), this is the legacy markdown-checkbox format from the
system setup workflow. See §10 for migration guidance.
If no task files exist at all, offer to create the 00.02 Tasks/ directory
with an empty todo.txt.
2. Parse Tasks
Each line in todo.txt (and done.txt, someday.txt) is a task. Parse using
these rules from the jdtodo.txt specification.
2.1 Logical Lines
A task is one logical line. If a line ends with \ (backslash as the very last
character, no trailing whitespace), the next physical line is a continuation of
the current task's note. Gather all continuation lines before parsing.
Skip blank lines and any lines that are entirely whitespace.
2.2 Task States
Determine the task state from the line prefix:
| Prefix | State | File |
|---|
x YYYY-MM-DD | Complete | done.txt |
~ YYYY-MM-DD | Cancelled | done.txt |
(A) through (Z) | Incomplete (with priority) | todo.txt |
| Anything else | Incomplete (no priority) | todo.txt |
2.3 Priority and Dates
For incomplete tasks:
- If the line starts with
(X) where X is A–Z, extract the priority.
- After priority (or at line start if no priority), check for a date in
YYYY-MM-DD format — this is the creation date.
For complete/cancelled tasks:
- After the
x or ~ marker, the first date is the completion/cancellation
date.
- The second date (if present) is the creation date.
2.4 Contexts and Projects
Scan the task body (everything before --- if a note exists) for:
- Contexts: tokens matching
@non-whitespace (e.g., @phone, @laptop,
@waiting, @someday)
- Projects: tokens matching
+non-whitespace (e.g., +GarageSale,
+N42.12.05)
JD code detection regex for project tags:
\+([A-Z]\d{2}\.)?\d{2}\.\d{2}(\+[A-Za-z0-9]+)?
This matches +AC.ID, +SYS.AC.ID, +AC.ID+SUB, and +SYS.AC.ID+SUB.
2.5 Key:Value Extensions
Extract recognized key:value pairs from the task body:
| Key | Value format | Purpose |
|---|
due | YYYY-MM-DD or someday | Hard deadline |
before | YYYY-MM-DD or someday | Soft deadline |
t | YYYY-MM-DD or someday | Threshold / visibility gate (user deferral) |
after | YYYY-MM-DD or someday | Visibility gate (external constraint) |
id | Non-whitespace, no colons | Task identifier |
dep | Non-whitespace, no colons | Blocked by another task |
sup | Non-whitespace, no colons | Subtask of another task |
rec | [+]N[d|w|m|y|b] | Recurrence interval |
h | 1 | Hidden from default views |
pri | A–Z | Preserved priority (on completed tasks) |
Preserve any unrecognized key:value pairs when modifying tasks.
2.6 Notes
If the task body contains --- (space-hyphen-hyphen-hyphen-space), everything
after the first occurrence is the note. The note may span multiple physical lines
via \ continuation. Leading whitespace on continuation lines is trimmed.
Key:value pairs in the note are freeform text — do NOT parse them as task
metadata.
3. List and Filter Tasks
3.1 Default View
When the user asks to see their tasks without specific filters, show all
actionable tasks. A task is actionable if ALL of these are true:
- It is incomplete (not
x or ~)
- It is not hidden (
h:1 absent)
- Its threshold date has passed or is absent (
t: date ≤ today, or no t:)
- Its
after: date has passed or is absent (after: date ≤ today, or no
after:)
- It does not have
@someday context
- It does not have
due:someday
- All
dep: references point to completed tasks (or the referenced id: does
not exist in the active task list)
Tasks with unresolved dependencies are shown in a separate Blocked section
rather than hidden entirely.
3.2 Filter by Context
When the user specifies a context (e.g., "show me @phone tasks"), show only
tasks that have that context tag. Common filters:
@phone — calls to make@laptop — computer work@errands — out-of-house tasks@waiting — blocked on someone else@someday — not currently actionable@agenda — discuss at next meeting
3.3 Filter by Project or JD Code
When the user specifies a project or JD code:
+GarageSale — all tasks in that named project+N42.12.05 — all tasks referencing that JD ID+N42.12 — all tasks referencing any ID in that JD category
3.4 Filter by Priority
Show tasks at or above a given priority:
- "show priority A tasks" → only
(A) tasks
- "show high priority" →
(A) and (B) tasks
- "show all priorities" → all tasks grouped by priority
3.5 Filter by Date
- overdue: Tasks where
due: or before: date is before today
- due today: Tasks where
due: is today
- due this week: Tasks where
due: is within the next 7 days
- upcoming: Tasks where
due: is within the next 14 or 30 days
- no due date: Tasks with no
due: or before: tag
3.6 Dependency Resolution
Build the dependency graph from id:, dep:, and sup: tags:
- Index all tasks by their
id: value.
- For each task with
dep:X, check if id:X exists and is incomplete.
- If
id:X is incomplete, the task is blocked.
- If
id:X is complete (in done.txt) or doesn't exist, the dependency is
resolved.
Show blocked tasks in a separate section with the blocking task identified:
### Blocked
(B) Sort items into keep/sell/donate +GarageSale dep:garage-clean
↳ blocked by: (A) Clean out garage for sale [garage-clean]
For sup: relationships, show subtask grouping when listing by project:
### +GarageSale
(A) Clean out garage for sale id:garage-clean due:2026-05-01
├─ (B) Sort items into keep/sell/donate sup:garage-clean
├─ (B) Sweep and mop garage floor sup:garage-clean
└─ (C) Arrange sale items on tables sup:garage-clean dep:sort-items
3.7 Grouping
Default grouping is by priority. The user may request grouping by:
- System: Group tasks by JD system (for cross-system views)
- Project: Group by
+project or +AC.ID tags
- Context: Group by
@context tags
- Due date: Group into overdue / today / this week / later / no date
- Priority: Group by
(A), (B), (C), etc.
3.8 Cross-System View
When no system is specified and multiple systems have task files, merge all
tasks and show system context. Prefix each task's display with its system
code if it's identifiable from +SYS.AC.ID tags or from which system's
todo.txt it came from:
## All Systems — 15 active tasks
### Priority A
[P10] (A) Submit quarterly tax estimate +N42.13.02 @laptop due:2026-04-15
[W20] (A) Respond to P0 incident follow-up +G24.21.05 @work due:2026-02-10
### Priority B
[P10] (B) Schedule dentist for Hannah +H11.25.01 @phone before:2026-03-01
3.9 JD Code Enrichment
When displaying tasks with JD code project tags, look up the code in the
system's JDex and show the ID description:
(A) Submit quarterly tax estimate +N42.13.02 @laptop due:2026-04-15
↳ N42.13.02 = Tax returns & estimates
This helps the user understand the JD cross-reference without leaving the task
view.
4. Add Tasks
4.1 Constructing a Task Line
Build a well-formed jdtodo.txt line from user input. The minimum requirement is
a task description — everything else is optional. The line format is:
[(priority)] [creation-date] description [@contexts] [+projects] [key:values] [ --- note]
4.2 Creation Date
Always add today's date as the creation date on new tasks.
4.3 Priority
If the user specifies a priority, add it. If they don't mention priority, do not
add one — unprioritized tasks are valid. Only ask about priority if the task
sounds urgent or time-sensitive and the user didn't specify.
4.4 JD Code Integration
When the user mentions a JD location or the task clearly relates to a JD ID:
- Add the appropriate
+AC.ID or +SYS.AC.ID project tag.
- Validate the code against the JDex. If the code doesn't exist, warn the
user and ask whether to use it anyway or choose a different ID.
- If the user describes a domain but doesn't specify a JD code (e.g., "add a
task about insurance"), suggest relevant IDs from the JDex.
4.5 Contexts
If the task description implies a context, suggest it:
- Phone calls →
@phone
- Computer work →
@laptop
- Errands or physical locations →
@errands
- Waiting on someone →
@waiting
- Meeting discussion items →
@agenda
Add suggested contexts only if the user confirms or if the mapping is obvious
(e.g., "call the dentist" clearly gets @phone).
4.6 Dates
When the user mentions a deadline or timing:
- "by Friday" / "due next week" → convert to
due:YYYY-MM-DD
- "before the party" → ask for a specific date, then use
before:YYYY-MM-DD
- "not until June" / "after surgery" → convert to
after:YYYY-MM-DD or
t:YYYY-MM-DD
- "someday" / "eventually" → use
due:someday or @someday
Use due: for hard deadlines, before: for soft targets, t: for user
deferrals, and after: for external constraints. When in doubt, ask which
semantic the user intends.
4.7 Relationships
If the task is part of a project that has existing tasks with id: tags:
- Show the existing task graph for that project.
- Offer to set
sup: (subtask) or dep: (blocked by) links.
- If the new task should be identifiable by other tasks, suggest an
id: —
keep it short and descriptive (e.g., id:post-signs).
4.8 Notes
If the user provides additional context beyond the task description, add it as
a note after ---. For multi-line notes, use \ continuation:
(B) 2026-02-09 Schedule vet appointment @phone --- Last checkup was October. \
Needs rabies booster.
4.9 Recurrence
If the task repeats:
- "every 3 days" →
rec:3d
- "weekly" →
rec:1w
- "monthly on the 1st" →
rec:+1m (strict, anchored to date)
- "every 2 weeks" →
rec:2w
- "every business day" →
rec:1b
Use strict mode (+ prefix) when the task is calendar-anchored (rent, reports).
Use non-strict when the interval from last completion matters (watering plants).
4.10 Which File
- New tasks go in
todo.txt by default.
- Tasks with
@someday or due:someday may optionally go in someday.txt if
the user has a separate someday file. Ask the user their preference if both
options are available.
4.11 Confirm Before Writing
Before adding the task, show the user the complete formatted line:
Adding to P10 todo.txt:
(B) 2026-02-09 Schedule vet appointment for Max +N42.25.01 @phone before:2026-03-01 --- Last checkup was October. Needs rabies booster.
Proceed after confirmation, or adjust based on feedback.
5. Complete and Cancel Tasks
5.1 Identifying the Task
When the user says "complete the insurance task" or "mark that done," identify
the target task:
- Search active tasks for keyword matches in the description.
- If the user references a JD code,
id:, project, or context, use those
to narrow the search.
- If exactly one task matches, confirm it with the user.
- If multiple tasks match, present the candidates and ask which one(s).
- If no tasks match, say so and offer to list tasks for the user to choose.
5.2 Completing a Task
To mark a task complete:
- Strip the
(X) priority from the line start (if present).
- Prepend
x YYYY-MM-DD using today's date as the completion date.
- If the task had a priority, add
pri:X to the end of the task body
(before any --- note).
- Preserve all other content: description, contexts, projects, key:value
pairs, and notes.
Before completion:
(A) 2026-02-01 Call Goodwill +GarageSale @phone due:2026-02-15
After completion:
x 2026-02-09 2026-02-01 Call Goodwill +GarageSale @phone due:2026-02-15 pri:A
5.3 Cancelling a Task
To cancel a task:
- Strip the
(X) priority (if present).
- Prepend
~ YYYY-MM-DD using today's date as the cancellation date.
- If the task had a priority, add
pri:X.
- Ask the user for a cancellation reason and append it as a note.
Before cancellation:
(B) 2026-02-01 Order extra tables +GarageSale
After cancellation:
~ 2026-02-09 2026-02-01 Order extra tables +GarageSale pri:B --- Lauren has enough tables.
5.4 Handle Recurrence
When completing a task that has a rec: tag:
- Complete the original task as described in §5.2.
- Create a new incomplete task with the same description, projects, contexts,
key:value pairs (except
pri: — restore the original priority), and notes.
- Shift date fields forward by the recurrence interval:
Non-strict (no + prefix, e.g., rec:3d): Calculate from today's date
(the completion date).
Strict (+ prefix, e.g., rec:+1m): Calculate from the original due:
date.
- Shift all date fields:
due:, t:, before:, after:. Preserve the gap
between t: and due: (if t: was 15 days before due:, the new t:
should be 15 days before the new due:).
- Set the creation date on the new task to today (the completion date).
Example — non-strict:
# Original (completed today, Feb 12):
x 2026-02-12 2026-02-09 Water all houseplants @home rec:3d due:2026-02-09 → done.txt
# New task:
(B) 2026-02-12 Water all houseplants @home rec:3d due:2026-02-15 → todo.txt
Example — strict:
# Original (completed today, Feb 1):
x 2026-02-01 2026-01-01 Pay rent rec:+1m due:2026-02-01 → done.txt
# New task (based on original due date, not completion date):
2026-02-01 Pay rent rec:+1m due:2026-03-01 → todo.txt
5.5 Move to done.txt
After completing or cancelling a task:
- Remove the task line (and any
\ continuation lines) from todo.txt.
- Append the completed/cancelled line to
done.txt.
- If
done.txt does not exist, create it.
- If the task was recurring, the new occurrence stays in
todo.txt.
5.6 Batch Completion
When completing multiple tasks at once, present a confirmation table:
Complete these tasks?
| # | Task | Status |
|---|------|--------|
| 1 | Call Goodwill +GarageSale @phone | → done.txt |
| 2 | Water houseplants @home rec:3d | → done.txt + new occurrence |
| 3 | File insurance claim +N42.11.03 | → done.txt |
Proceed with all 3? [y/n/select specific]
6. Modify Tasks
6.1 Change Priority
Update or add (X) at the start of the task line. If the task already has a
priority, replace it. If it has no priority, insert before the creation date
(or before the description if no creation date).
6.2 Add or Change Dates
Add or modify due:, before:, t:, after: tags. If the tag already
exists, replace its value. If new, append to the task body (before ---).
6.3 Add Contexts or Projects
Append @context or +project tags to the task body. Check for duplicates
before adding.
6.4 Add or Update Notes
- If the task has no note, add
--- followed by the note text.
- If the task already has a note, append to it (add a
\ continuation if
needed for multiline).
6.5 Set Up Relationships
Add id:, dep:, or sup: tags to the task body:
- When adding
id:, verify the identifier is unique within the file.
- When adding
dep:, verify the referenced id: exists.
- When adding
sup:, verify the referenced id: exists.
6.6 Move to Someday
To defer a task indefinitely:
- Add
@someday or change due: to due:someday.
- If the user has a separate
someday.txt, offer to move the task there.
- Remove
t: and after: dates if present (they're superseded by someday
status).
6.7 Reactivate from Someday
To bring a task back from someday:
- Remove
@someday context and due:someday (if present).
- If the task is in
someday.txt, move it to todo.txt.
- Ask the user for a new due date or leave undated.
7. Review Mode
Review mode is a guided walkthrough for periodic task maintenance — typically
weekly.
7.1 Someday Review
Present each task in someday.txt (or tasks with @someday/due:someday in
todo.txt):
For each task, offer:
- Keep: Leave as someday.
- Activate: Move to
todo.txt, set a due date, remove @someday.
- Cancel: Mark cancelled with reason, move to
done.txt.
7.2 Deferred Tasks
Show tasks whose t: or after: date has passed — these are now actionable
but may have been overlooked:
These tasks are now actionable:
(B) Renew car registration +N42.12.01 t:2026-06-01 due:2026-06-30
↳ Threshold date passed (was deferred until Jun 1)
Also show tasks with t: or after: dates in the next 7 days — coming up
soon.
7.3 Stale Tasks
Identify incomplete tasks that may be stale:
- Created more than 30 days ago with no due date and no recent modification
- No priority set
- Not part of an active project
For each stale task, offer: keep as-is, set a due date, move to someday, or
cancel.
7.4 Dependency Check
Show tasks whose blocking dependencies have been resolved since the last
review — these are newly actionable:
Newly unblocked:
(B) Post signs around neighborhood +GarageSale dep:plan-sale
↳ plan-sale was completed on 2026-02-05
7.5 Overdue Summary
Present all tasks past their due: date, sorted by how overdue:
Overdue tasks:
(A) Respond to P0 follow-up +G24.21.05 due:2026-02-10 [9 days overdue]
(B) Review tuition bill +V06.31.02 due:2026-02-28 [past due]
For each, offer: complete (if done), reschedule (set new due date), or cancel.
8. JD Integration
8.1 Cross-Referencing with JDex
When a task uses +AC.ID or +SYS.AC.ID project tags:
- Look up the code in the relevant system's JDex.
- If found, display the JDex description alongside the task when showing
task lists.
- If not found, warn the user: "JD code +N42.12.05 is not in the JDex.
Create the ID, or use a different code?"
8.2 Context from JD System
When displaying tasks, enrich JD code references:
(A) Clean out garage for sale +N42.12.05 due:2026-05-01
↳ N42.12.05 = Garage maintenance (in P10 Personal)
This is informational — it helps the user remember what the JD code refers to
without switching context.
8.3 Task Extraction Compatibility
The inbox processor skill (§4 of jd-inbox-processor) extracts tasks in
markdown-checkbox format and appends them to 00.02 Tasks. When both skills
are in use:
- If the task file is
todo.txt (jdtodo.txt format), extracted tasks should
be written in jdtodo.txt format instead of markdown checkboxes.
- The jdtodo.txt format is preferred when a
todo.txt file exists.
- If only
00.02 Tasks.md exists (legacy format), the inbox processor's
format is compatible until migration (see §10).
8.4 Multi-System Tasks
A single todo.txt may reference multiple systems via +SYS.AC.ID tags.
Alternatively, each system may have its own todo.txt. Handle both approaches:
- Single file: All tasks in one
todo.txt, system identified by project
tags.
- Per-system files: Separate
todo.txt per system, merged for cross-system
views.
When displaying cross-system views, avoid duplicate id: confusion by
mentally namespacing — if two systems both have an id:plan, show the system
context to disambiguate.
9. Interaction Principles
9.1 When to Ask vs. When to Act
- Act without asking: Listing tasks, showing filtered views, resolving
dependency graphs, enriching JD code references. These are read-only and
safe.
- Confirm before acting: Completing tasks, cancelling tasks, moving tasks
between files (todo.txt ↔ done.txt ↔ someday.txt), modifying tasks the user
has specifically identified. Present the change and get a "yes."
- Always ask: Deleting task lines (prefer moving to done.txt — never
truly delete without explicit user confirmation), modifying tasks that the
user hasn't specifically identified, creating task files or directories.
9.2 Task Identification
When the user refers to a task by description ("the insurance one," "that
garage sale task"), use these signals to identify it:
- Keywords in the task description
- JD codes or project tags mentioned by the user
- Context tags (
@phone, @laptop)
- Priority level
- Recency — if the user just added or discussed a task, it's likely the
one they mean
If ambiguous, present the top 2–3 candidates:
I found 2 tasks matching "insurance":
- (A) Call insurance company about claim +N42.11.03 @phone
- (C) Research new homeowner's insurance quotes +N42.11.03 @laptop
Which one?
9.3 Format Preservation
When modifying todo.txt:
- Preserve all existing formatting, whitespace, and ordering.
- Append new tasks at the end of the file.
- Do not re-sort the file unless the user explicitly asks.
- When removing a completed task, remove the exact line(s) including any
\
continuation lines.
- Preserve blank lines and any comment-like lines (though jdtodo.txt doesn't
formally define comments, users may have them).
10. Error Handling
10.1 Task File Missing
If todo.txt doesn't exist at the expected location:
- Check if a
00.02 Tasks/ directory exists. If so, create todo.txt in it.
- If only
00.02 Tasks.md exists (flat file), see §10.2.
- If nothing exists, offer to create the
00.02 Tasks/ directory with an
empty todo.txt.
10.2 Legacy Format Migration
If 00.02 Tasks.md exists with markdown-checkbox tasks:
- [ ] Call the insurance company
- [x] File the tax return
- [ ] Schedule dentist appointment
Offer to migrate to jdtodo.txt format:
- Convert
- [ ] description → YYYY-MM-DD description (using today's date
as creation date, since the original has none).
- Convert
- [x] description → x YYYY-MM-DD description (using today as
completion date).
- Extract any JD references, contexts, or dates from the markdown text and
convert to proper tags.
- Write the converted tasks to
00.02 Tasks/todo.txt (completed to
done.txt).
- Rename
00.02 Tasks.md to 00.02 Tasks.md.bak (do not delete).
Always confirm the migration plan with the user before executing.
10.3 Invalid JD Codes
If a task references a +AC.ID that isn't in the JDex:
- When listing: Show the task but flag the invalid reference.
- When adding: Warn before writing and offer alternatives.
- Do not block operations on tasks with invalid codes — they may be
intentional placeholders.
10.4 Circular Dependencies
If dep: chains form a cycle (A depends on B, B depends on A):
- Warn the user about the cycle.
- Show which tasks are involved.
- Suggest removing one of the dependencies to break the cycle.
- Do not modify anything automatically.
10.5 Duplicate Task IDs
If multiple tasks in the same file have the same id: value:
- Warn the user when the duplicate is detected.
- Show both tasks with the duplicate ID.
- Suggest renaming one of them.
10.6 File Write Errors
If writing to a file fails (permissions, disk full, etc.):
- Report the error clearly.
- Do not attempt to modify the original file again.
- Show the user the change that was attempted so they can apply it manually.
11. Post-Action Summary
After any write operation (add, complete, cancel, modify), present a summary:
Task update complete.
P10 Personal: 12 active, 3 overdue
Completed: 2 tasks (moved to done.txt)
Recurring: 1 new occurrence generated
Added: 1 new task
W20 Work: 5 active, 1 overdue
Completed: 1 task (moved to done.txt)
For review sessions, provide a more detailed summary:
Weekly review complete.
Someday: 3 reviewed → 1 activated, 1 cancelled, 1 kept
Deferred: 2 tasks now actionable
Stale: 1 task moved to someday
Overdue: 3 tasks rescheduled
Newly unblocked: 1 task
Quick Reference: Task File Locations
SYS/00-09 System/00 System management/00.02 Tasks/
├── todo.txt # Active and deferred tasks
├── done.txt # Completed and cancelled tasks
└── someday.txt # @someday items (optional)
Quick Reference: Task States
| State | Line prefix | Stored in |
|---|
| Incomplete | (none, or (A)) | todo.txt |
| Complete | x YYYY-MM-DD | done.txt |
| Cancelled | ~ YYYY-MM-DD | done.txt |
| Someday | @someday or due:someday | someday.txt (optional) or todo.txt |
| Hidden | h:1 | todo.txt (excluded from views) |
Quick Reference: Date Tags
| Tag | Meaning | Visibility effect |
|---|
due:YYYY-MM-DD | Hard deadline | Overdue highlighting |
before:YYYY-MM-DD | Soft deadline | Same as due: for display |
t:YYYY-MM-DD | Don't show until | Hidden before date |
after:YYYY-MM-DD | Can't start until | Hidden before date |
due:someday | Indefinite | Hidden from default views |
