Waiting

A task that’s blocked on someone else isn’t the same as a task you’re working on. Putting both in your main planning views inflates your sense of load — you see ten “open” things when really seven are “waiting on a reply” and three are actually yours to do.

Pensum’s Waiting view is the dedicated home for that other category. Tasks live there until the blocker clears, then flip back to active in one keystroke.

The waiting status

A task is “waiting” when its checkbox is [w] instead of the usual [ ]:

- [w] Hear back from legal on Q3 contract template
- [w] Acme to confirm pricing call slot
- [w] Reply from Maria on the staging deploy

The [w] status is non-standard markdown, but Pensum’s parser treats it as a first-class task state alongside active ([ ]), in-progress ([/]), cancelled ([-]), and complete ([x]).

Why it’s excluded from Today / Inbox / Forecast

Pensum’s planning presets (Today, Inbox, Forecast, By Project, Calendar) all filter to open statuses — [ ] and [/] by default. Waiting tasks are deliberately excluded so they don’t clutter your active work surface.

This is the whole point of having a separate status: the moment you flag something as waiting, it stops counting against your active load.

The Waiting view

Open it via Pensum: Open Waiting view in the command palette.

The view lists every [w] task in your vault, grouped by project (or “no project” for floating waits). For each task you can see:

• The description
• The project (if any) and source file
• How long it’s been in waiting status (read off the file’s modified time as a rough proxy)

Working the list

The standard task interactions all work here:

• Click a task → opens the edit modal (good for adding a note about who you’re waiting on)
• Right-click → quick actions
• v → start multi-select; bulk operations apply to the whole selection
• c (Complete shortcut) → in this view, completing means flipping the status back to active ([ ]). The semantic is “the wait is over, this is mine again.” If the task is actually done, use x to mark complete the normal way or just check the box.

Bulk follow-up

Multi-select (v to toggle rows, Shift+J/K to extend, * to select all) plus a single keystroke lets you batch chase-ups: hit v on the four contracts you’re waiting on, then Esc / right-click → Open source — go down the list pinging owners.

Marking a task as waiting

Three ways:

1. From any list view — right-click a task → Mark as waiting on…. Toggles to [w]. Right-clicking a [w] task shows Mark as active instead.
2. Editor command — put your cursor on a task line and run Pensum: Mark cursor task as waiting. Bind a hotkey if you use this a lot. Re-running on a [w] line flips it back to active.
3. Hand-edit the markdown — change - [ ] to - [w] and save. The status is parsed on next scan.

Weekly review fit

The weekly review surfaces waiting tasks as one of its five zones. The review is where you decide: am I still actually waiting on this, or has the person dropped the ball and I should follow up, change the plan, or just close the loop?

See Weekly Review for the full digest.

Status in MCP

Agents can read and write waiting state via:

• plan.waiting — list every [w] task
• plan.set_status with status: "w" — mark a task as waiting
• plan.set_status with status: " " — flip a waiting task back to active

The plan.weekly_review digest includes waiting tasks under the waiting key.

See MCP server for the rest.

When not to use waiting

Don’t conflate “I’m not working on this right now” with “I’m blocked on someone else.” The first is just an open task you haven’t gotten to — those belong in your normal active flow. Waiting status is specifically for external dependencies you’ve already kicked off: an email sent, a request submitted, a call scheduled. If you haven’t yet asked the person, you don’t have a waiting task — you have an active task called “ask X about Y.”

The discipline pays off: a healthy [w] list is a list of things you can follow up on. A bloated one tells you exactly where to apply pressure.