What Belongs in a Task Note? A Practical Structure for Obsidian

When a checkbox starts asking for office space

A checkbox is excellent at holding one small instruction:

- [ ] Repair machine

In the moment, this seems absolutely sufficient. But as so often we get interrupted and it is only when we return after a week or two when reality strikes.

Which machine? What is broken? Which spare part do I need? Has it been ordered? Who is waiting for the repair? Where did I put the manual? And why does the rear wheel now make a sound normally associated with distressed wildlife?

At some point, a task needs more than a line. It needs a place of its own.

In my previous article on checkboxes and task notes I argued that both have their place. A checkbox minimizes friction. A task note preserves the structure, context and relationships that no longer fit reliably into one line.

But once a task becomes a note, a new problem appears: What should the note contain?

After more than ten years of managing projects, my answer is not “everything.” That would merely replace task chaos with YAML-flavoured bureaucracy. A useful task note contains the information required to understand, organize, perform and later reconstruct the work—and no more.

The easiest way to build one is in layers:

The title identifies the action.
Properties make the task filterable and connect it to the rest of the system.
The note body supports the actual work.

Together, these layers form something like a small digital twin of the task: a written representation of its current state, its relationships and the changes it is meant to produce.

Here are some guidelines I use to make the most out of task notes.

1. Give the task an active title

The title should say what will be done and, where possible, what will be changed.

Compare these:

Bike
Bike repair
Repair the rear brake on the touring bike

The first is an object, the second is a topic wearing work clothes, the third now; that is a task.

I therefore prefer titles built from a verb and an object:

Draft the Task Note article
Repair the rear brake
Review the gateway test results
Remove the obsolete project files

The title should be understandable outside its original context. A note called Ask Sebastian may make perfect sense today, while Sebastian, the question and the reason are still floating around in working memory. Six months later, it reads like a message left by a particularly unhelpful roommate.

I usually keep people names out of the title and store the responsible person or stakeholders in properties. People and responsibilities change; the work itself often does not. If the title cannot carry enough context without turning into a minor novel, add a short description property.

I also prefer a human-readable filename over an opaque identifier. A UUID may be useful when software needs a permanent unique key, but it makes the file harder to recognize outside the tool that interprets it. A descriptive Markdown filename remains useful in search results, file explorers, links and whatever tool replaces today’s favourite plugin.

2. Use properties for information you want to query

In Obsidian, properties are stored as YAML at the top of a Markdown file. They are readable by both humans and software, and they allow tools such as Bases, TaskNotes or Dataview to filter, sort and group tasks.

That makes properties the right place for structured information you want to ask questions about later:

Which tasks are active?
What am I waiting for?
Which tasks belong to this project?
What does this person owe me?
Which deadline is approaching?
How much time did I spend on this customer task?

The important distinction is this:

Properties are for filtering and automation.
Links are for relationships and navigation.
The body is for thinking and working.

A linked property can do both of the first two jobs. For example, project: "[[PRJT - Website]]" lets me query the relationship while also navigating to the project note.

This does not mean that every conceivable property belongs in every task. I use a small core and add the rest only when they earn their keep.

Define the task: goal, deliverable and description

A task should express more than activity; it should also express the change the activity is supposed to produce.

Useful properties include:

goal: why the work is being done, sometimes even SMART;
deliverables or object_created: what the task must produce;
description: the context needed to understand the task.

These fields prevent a common project-management failure: completing the stated activity without achieving the intended result.

Discuss the website may be performed successfully by sitting in a room and producing warm air. Decide which pages belong in the new navigation and document the result has an outcome that can actually be checked.

I do not always need all three fields. If the title already explains the action and outcome, repeating it in YAML adds ceremony, not clarity. I add a goal, deliverable or description when it resolves an ambiguity the title cannot.

Record the state: status, priority and urgency

The status property tells me where the task is in its lifecycle. My recurring statuses are:

ToDo: accepted into the backlog;
active: started, but not necessarily on my desk right now;
actively being worked on: the task currently receiving attention;
waiting: progress depends on an external input;
DONE: completed;
cancelled: deliberately abandoned.

The distinction between active and actively being worked on may look suspiciously precise until twenty active tasks all claim to be the one you are working on. One describes an open workstream; the other describes present attention.

I often link a status to its own note:

status: "[[waiting]]"

This lets me find all tasks with that status and document what the status actually means in the same status file. Shared definitions matter in projects. Assumptions are inexpensive right up to the moment they become defects.

Assumptions kill…projects [§ Anderson 2017].

I use priority and urgency only for larger tasks. Priority describes relative importance; urgency describes how quickly something demands attention. Both let me easily find the One Thing I have to concentrate on [§ The One Thing (Book)]. A task can be important without being urgent, or urgent without deserving much of your life. Email has built an industry around demonstrating the second category.

Record time: actual dates, planned dates and duration

Dates answer different questions, so I keep their meanings separate:

date_planned_start or scheduled: when work is intended to begin;
date_start: when work actually began;
date_planned_end or deadline: when it should be finished;
date_end or completed: when it was actually finished;
duration: how long active work took.

Planned and actual dates are not interchangeable. Their difference tells me something about the quality of the plan, delays in the process and the realism of future estimates. Both are also important for reporting purposes. Good Stakeholders often want to know the differences between planned an actual dates and where they come from. Many projects are for learning how a new process can be established as much as for establishing it. This metric helps to identify hiccups and where they come from.

For customer work billed by time, duration is also less philosophical: it tells me what belongs on the invoice.

Add the tiny date that prevents tasks from disappearing

The most useful property in my system may also be the least glamorous:

check: 2026-09-03

The check date tells me when to review the task if nothing else has happened.

I introduced it while managing increasingly complex projects. At some point, I was waiting for so many inputs from so many people that I felt as if I were running the project blind. Successful delivery depended less on management than on remembering every open loop at exactly the right moment—a strategy otherwise known as “hope.”

The check date changed that. If someone promises a drawing next Tuesday, I set the task to waiting and add a check date for Wednesday. If the drawing arrives, wonderful. If it does not, the task returns to my attention without requiring me to rehearse the entire project in my head every morning and reducing that pesky cognitive load [§ Schacter 2002, § Yassine 2003,§ Masicampo 2011, § Foer 2012].

A deadline says when the result is due. A check date says when I need to look again.

3. Connect the task to the objects around it

Tasks do not exist in a vacuum. They belong to projects, affect objects, require tools, involve people and depend on other work. Without those relationships, a vault full of task notes becomes a pile of index cards thrown down a staircase.

Project and context

I have a soft rule that every task belongs to a project or an ongoing operation.

project:
  - "[[PRJT - Nosy Science]]"

Projects represent larger, temporary changes. For recurring areas of private or professional life, I use operations such as [[OPS - Household]] or [[OPS - Nosy Science]]. A task may belong to more than one project; e. g. when internal organization and customer-facing delivery overlap.

A context property adds a topic or domain such as budgeting, battery storage or marketing. I use it when the project alone does not provide enough orientation.

Dependencies: blocked AND and blocked OR

Work has an order. I can drive a car after it has been repaired. I can publish an article after it has been written. I can install a machine after it has arrived, although project schedules occasionally like to explore alternative interpretations of causality.

I distinguish two kinds of blockers:

blocked_and: all linked tasks must be completed before this task can proceed;
blocked_or: any one of the linked tasks is sufficient.

blocked_and:
  - "[[Research the evidence]]"
  - "[[Create the article image]]"

blocked_or:
  - "[[Receive supplier offer A]]"
  - "[[Receive supplier offer B]]"

The names borrow from logical AND and OR gates. They make the dependency explicit instead of hiding it in prose and hoping Future Me performs formal logic before coffee.

For hierarchies, I may also use subTasks to link a larger task to its component tasks.

People: responsible, team and stakeholders

These properties describe different relationships:

responsible: the one person accountable for moving the task forward;
team: the people doing the work together;
stakeholders: people or groups whose support is needed or who should be informed [§ Freeman 1983].

I prefer one responsible person. If everyone is responsible, no one is, and if two are responsible unwanted questions appear.
Organization, even between two people, requires overhead and should therefore be eliminated if it isn’t strictly necessary.
In my work I learned the hard way that if one person is responsible for the delivirables, the expectations are clear and so many issues can be avoided.

Linking task notes to people is especially valuable before meetings. I can open a person’s note and find every task for which I am waiting on their input. The same works when I meet them unexpectedly and would otherwise remember the important question three minutes after they leave.

Requirements and tools

Use requirements for constraints that materially shape the work. If a bottle of water must be carried up a mountain while hopping on one leg, you can be damn sure that I will list that requirement.

Use tools for equipment, software or resources that are special enough to matter. I do not list my computer for every knowledge-work task, just as a carpenter probably does not document their hammer. I list tools when availability, selection, calibration or later traceability matters; such as that CNC machine in the workshop or the shared car.

The objects the task changes

In Object-Oriented Project Management (O3PM), an action changes one or more objects. It can create, modify or remove them. Task properties can make those effects explicit:

object_created or deliverables: an article, decision, drawing or purchased car that was created through the task;
object_modified: a repaired machine, edited document or cleaned room;
object_destroyed: a retired file, discarded component or sold car;
important_links: related objects that are useful during the work but are not themselves changed.

This is where the task note becomes more than a reminder. It becomes part of the object’s history. A completed repair task linked to a machine tells me what was changed, when, why and by whom. The task note is not only a digital twin of the work; it becomes an entry in the object’s CV.

4. Use the body for doing the work

Properties organize the task. The body helps complete it.

I normally divide the body into three sections: Info, Activities and Notes. On completion, I add Results where useful.

Info: what must be visible at a glance

The Info section contains useful context that does not need to be queried:

a link I will need while working;
background information;
an explanation unfit for the description property;
a short record of the current situation.

I prefer bullets because this is operational information, not the opening chapter of a novel.

Activities: the next executable steps

Under Activities, I keep the steps required to complete the task:

## Activities

- [x] Inspect the brake pads
- [ ] Identify the correct replacement pads
- [ ] Order the parts
- [ ] Replace and test the brake pads

The right level of detail depends on familiarity. A routine task with a known procedure may need no checklist at all. Novel or complex work benefits from smaller steps because written actions can be reviewed, reduce the burden on working memory and make it easier to recognize the next opportunity to act [§ Gollwitzer 2006; § Masicampo 2011]. Checklists and defined processes can also reduce omissions and variation, especially in work where mistakes matter [§ Brady 2006; § Qayyum 2019; § Fellers 2023].

And yes, checking off progress feels good. The careful version of that claim is not that every checkbox dispenses a medically measured droplet of dopamine. Research does, however, connect perceived progress and goal attainment with motivation and reward-related processes [§ Amabile 2011; § Schultz 2016; § Westbrook 2016]. So although the checkbox may not be pharmacology, it is still a satisfying little square.

The purpose is not to atomize work until move hand toward screwdriver becomes a task. Write down the steps that reduce uncertainty, protect quality or make resumption easier. Stop when the next action is obvious.

Notes: a place where thinking can happen

Complicated tasks generate observations, questions, partial ideas and dead ends. The Notes section gives them somewhere to live besides my head.

Writing is thinking [§ Connor 2018].

Writing is part of thinking, not merely a transcript produced afterward. By developing the approach inside the task note, I can inspect my reasoning, resume it later and leave enough context for someone else—or Future Me, who tends to be a colleague with suspiciously poor onboarding—to understand what happened.

Results: record what changed

When I close a substantial task, I add a short result:

Document completed and sent to the customer.
Installation successful; requirement R-14 remains open.
Measured material thickness: 3.2 mm.

Important results such as formal decisions deserve their own notes so they can be linked and reused. Minor results can remain in the task. Either way, completion should record the outcome, not merely the comforting fact that somebody clicked DONE.

A complete example

The resulting task note might look like this:

title: Write and publish the task-note structure article
---
type: task
status: "[[waiting]]"
project:
  - "[[PRJT - Nosy Science]]"
goal:
  - Publish a useful guide to structuring task notes
deliverables:
  - "[[@ Article - The Contents of Task Notes]]"
priority: high
date_start: 2026-08-30 08:30:00
date_planned_end: 2026-09-02
check: 2026-09-01
responsible:
  - "[[@ Jan]]"
blocked_and:
  - "[[Verify the scientific sources]]"
stakeholders:
  - "[[Chief Paw Officer]"
---
## Info

- Follow the earlier article on checkboxes versus task notes.
- Keep the examples useful for Obsidian users without making the method plugin-dependent.

## Activities

- [x] Develop the structure
- [x] Draft the article
- [ ] Verify citations
- [ ] Add the article image
- [ ] Publish on Nosy Science

## Notes

- Emphasize the check date and explicit deliverables.
- A task note should be layered. 
- A task note should not have a mandatory form.

## Results

-

Your version can be much smaller. In fact, it usually should be.

The rule that prevents the system from becoming the work

Not every task needs every property. Not every task needs a note.

If I am responsible for nearly every task in my personal vault, I can omit responsible and treat myself as the default. If a task has no meaningful deadline, I do not invent one to make the YAML feel complete. If Buy toothpaste fits comfortably in a checkbox, creating a dedicated note with stakeholder mapping and an object lifecycle would be less project management than performance art.

I promote a checkbox to a task note when the work needs one or more of the following:

a state worth tracking;
context I will need again;
a defined goal or deliverable;
dependencies or relationships;
several non-obvious steps;
a result or history worth preserving.

If you like to know more about the differences check out @ Article – Rules for Task Note Creation.

Start with the title, status, project and next actions. Add other properties when they answer a real question or prevent a real failure. Skip them if they are only decorative.

A good task note is not the one with the most complete schema. It is the one that makes the work easier to understand, easier to resume and harder to lose.

A task system should support your work. It should not become a project on its own.

Sources

Key	Citation
§ AitSahlia 1995	AitSahlia, F., Johnson, E., & Will, P. (1995). Is concurrent engineering always a sensible proposition?. IEEE Transactions on Engineering Management, 42(2), 166-170.
§ Amabile 2011	Amabile, T., & Kramer, S. (2011). The progress principle: Using small wins to ignite joy, engagement, and creativity at work. Harvard Business Press.
§ Anderson 2017	Anderson, R. C., & Shifrin, Z. (2017). The meaning of words in context. Theoretical issues in reading comprehension, 331-348.
§ Benn 2014	Benn, Y., Webb, T. L., Chang, B. P., Sun, Y. H., Wilkinson, I. D., & Farrow, T. F. (2014). The neural basis of monitoring goal progress. Frontiers in Human Neuroscience, 8, 688.
§ Brady 2006	Brady, J. E., & Allen, T. T. (2006). Six Sigma literature: a review and agenda for future research. Quality and reliability engineering International, 22(3), 335-367.
§ Connor 2018	Connor, T. (2018, July 16). Amazon’s flipped meetings: How Jeff Bezos bans PowerPoint and promotes thoughtful narratives instead. Medium. https://medium.com/swlh/amazons-flipped-meetings-5395ac86f193
§ Fellers 2023	Fellers, C., Miyatsu, T., & Storm, B. C. (2023). Remembering what to do when the time comes: The effects of offloading in a complex prospective memory task. Journal of experimental psychology. Applied, 29(3), 631–644. https://doi.org/10.1037/xap0000449
§ Foer 2012	Foer, J. (2012). Moonwalking with Einstein: The art and science of remembering everything. Penguin.
§ Gollwitzer 2006	Gollwitzer, P. M., & Sheeran, P. (2006). Implementation intentions and goal achievement: A meta‐analysis of effects and processes. Advances in experimental social psychology, 38, 69-119.
§ The One Thing (Book)	Keller, G., & Papasan, J. (2013). The ONE thing: The surprisingly simple truth behind extraordinary results. Bard Press.
§ Kim 2021	Kim, S., Yang, J. W., Lim, J., Lee, S., Ihm, J., & Park, J. (2021). The impact of writing on academic performance for medical students. BMC Medical Education, 21(1), 1-8.
§ Masicampo 2011	Masicampo, E. J., & Baumeister, R. F. (2011). Consider it done! Plan making can eliminate the cognitive effects of unfulfilled goals. Journal of personality and social psychology, 101(4), 667.
§ Qayyum 2019	Qayyum, M. A., & Smith, D. (2019). Improving the task understanding for knowledge creation in assessments. Journal of Information & Knowledge Management, 18(04), 1950041.
§ Ramayah 2006	Ramayah, T. (2006). Interface characteristics, perceived ease of use and intention to use an online library in Malaysia. Information development, 22(2), 123-133.
§ Sands 2023	Sands, L. P., Jiang, A., Liebenow, B., DiMarco, E., Laxton, A. W., Tatter, S. B., … & Kishida, K. T. (2023). Subsecond fluctuations in extracellular dopamine encode reward and punishment prediction errors in humans. Science advances, 9(48), eadi4927.
§ Schacter 2002	Schacter, D. L. (2002). The seven sins of memory: How the mind forgets and remembers. HMH.
§ Schultz 2016	Schultz, W. (2016). Dopamine reward prediction error coding. Dialogues in clinical neuroscience, 18(1), 23-32.
§ Westbrook 2016	Westbrook, A., & Braver, T. S. (2016). Dopamine does double duty in motivating cognitive effort. Neuron, 89(4), 695-710.
§ Yassine 2003	Yassine, A., & Braha, D. (2003). Complex concurrent engineering and the design structure matrix method. Concurrent Engineering, 11(3), 165-176.