Your LifeOps in Obsidian

Obsidian reads a folder of files on your computer and on your phone, and the LifeOps plugin fills one of those folders with your own things. Each goal is a file, each open task is a file, each note is a file, each day you wrote on is a file, and your events, life areas and reminders are files beside them. Most of them are markdown, which is plain text with a few marks in it; the maps are Obsidian canvases and the five saved views are Obsidian bases. You read them in Obsidian, and you edit them there too.

The app is the source of truth and every file is a view of it. When you save a file, the plugin works out which fields you touched, sends those to the app, and then rewrites the file from the app's answer, so what you are looking at is what actually landed rather than what you typed. Two versions are never merged. When it cannot save what you typed, it says so in a notice, which is the small message Obsidian shows in the corner of the window. Where you drag the cards on a map, and anything you draw there yourself, stays yours and comes through every rewrite.

The plugin owns one folder, called LifeOps, and writes nowhere else in your vault. Your own notes beside it are left alone.

The plugin installs from inside Obsidian, the same way on a computer and on a phone, and each device gets its own vault. A vault the plugin writes belongs to the device it is on. The plugin on each device writes the whole LifeOps folder itself, so two devices writing one synced folder would fight over it. Keep the vault out of iCloud, Obsidian Sync, Dropbox and every other synced folder. Your LifeOps is what the devices share, and each vault is a view of it.

The plugin is not in Obsidian's community store, so it installs through BRAT, a plugin that is.

1. Make a vault for it, or use one you have, stored on the device. On a phone, when Obsidian offers to store the new vault in iCloud, say no.
2. In Obsidian's settings, open Community plugins and turn them on. Choose Browse, find BRAT, install it and enable it.
3. In BRAT's own settings, choose Add beta plugin and enter Cognizant-Coaching/obsidian-lifeops. BRAT fetches the plugin and keeps it current as new versions are released.
4. Back in Community plugins, enable LifeOps.

Then open Obsidian's settings and choose LifeOps. Two things to type, then a sign-in, are the whole of it.

Backend address

Where your LifeOps answers. It is the same address your phone app uses, and whoever set up your LifeOps gave it to you.

Token

The pass this vault uses to reach your LifeOps. Sign in below fills it in for you. The field shows dots rather than the token, since this screen gets read over your shoulder.

Folder

The folder in this vault the plugin owns. It starts as LifeOps, and it writes nowhere else.

Check every

Seconds between one check for changes and the next. It starts at 60, and five seconds is the shortest it will take.

Live updates

Holds a connection open so a change you make somewhere else shows up here within about a second. Where the platform gives the plugin no such connection, the timer above is the whole of it.

Sign in takes the username and password you use for the app itself, and fills in the token for you. There is no second account to make. The Test button, on the Test connection row, asks your LifeOps who the token belongs to and answers Connected as your name, which is the quickest way to tell a wrong address from a wrong password.

The first sync writes every file at once, which takes a moment on a full LifeOps. After that it asks for what changed, and for a short list of what still exists.

Goals, Tasks, Notes, Journal, Events, Areas and Maps are the folders, and every file of one kind is directly inside one of them. There is no folder per life area under any of them. Where a thing is filed is a property at the top of its own file: a task points at its life area and at its goal, a note points at its area, its goal and its event, and a goal and an event each point at their area. Repointing a task's or a note's links refiles it without moving the file, so the file keeps its place in the sidebar and its open tab. An event's area is shown rather than edited, and the app is where an event is refiled. Obsidian draws its own backlinks from those properties, so the backlinks panel on an area's file shows everything pointing at it.

A file is usually part yours to edit and part a view. A goal's fields and tasks save back while the list of what is filed under an area does not, and the difference is worth knowing before you tick a box that does nothing. A file you make yourself in one of these folders becomes nothing: the plugin knows its own files by a line it writes into them, so a file without one is left alone, with a notice saying it has no id the plugin recognises. New goals, notes, events and life areas are made in the app and reach the vault at the next sync. Three things you can make from the vault are a task, by typing a line under Tasks in a goal file or under Subtasks in a task file, a journal entry, by typing a block into a day's file, and a link between two goals, by drawing an arrow on a map. About.md in the LifeOps folder says all of this in your own words, and it is rewritten whenever your own words for something change.

Four kinds of property turn up across those files, and each reads the same way everywhere.

type

Which kind of file this is, in one word, which is goal, task, note, event, area or journal. The saved views ask for files by this word. It is written for you and there is no reason to type it.

kind

Your own word for the sort of thing it is, which is what the app shows on the thing itself. A goal's kind is one of your goal kinds, and a word that is not one of them stops the save. A note's kind and a task's kind are yours to word as you like.

Links

A property pointing at another file is written in full, as area: "[[LifeOps/Areas/Negotium]]". The quotes are there because the value starts with a bracket, and the whole path is there because Obsidian would not find a short one from inside another folder. Type a bare name instead and it is understood; type a name nothing answers to and nothing from that file is saved.

Dates

Every date reads 2026-09-17, year first. An empty date property means a date not set, and clearing one clears it in the app.

Each goal is a file under LifeOps/Goals, named by the goal. The block of lines between the two --- rules at the top says it is a goal, gives the kind of goal it is, its status and the two dates it runs between, and points area at the life area's own file. Typing over any of those saves the change. A word you use for a status, a kind or an area is the only word accepted: type something else and nothing at all from that file is saved, with a notice naming the word you used. Your own words for all three are listed in About.md.

The # line under the block and the file's name both hold the goal's name, and changing either one renames the goal. Renaming the file in Obsidian's sidebar is the usual gesture, so when the two disagree the file name is the one that wins. Point area at another life area and the goal is filed there, with its file where it was.

Summary under the title is the goal's own writing, the same words the goal's page shows in the app, and editing it saves back. When that writing holds something plain text cannot hold, such as a picture, a table or a video, the section is one line saying so and nothing else. The words are safe in the app, and the app is where that goal's summary is read and changed.

Under Tasks comes the goal's work, one line per task. A line reads like this:

- [ ] [[LifeOps/Tasks/Sed do eiusmod agenda]] [status:: Scheduled] [date:: 2026-09-17] ^t-bc6a3df5fcb8

Every open task is a file of its own, so the line links to that file and the words inside the brackets are its name. Ticking the box closes the task and unticking it opens it again, and a closed line drops below the open ones when the file is rewritten, so a line that moves after you tick it has done what you asked. A task you close has no file any more, so its line shows its words in place of the link. Retyping the words inside the brackets renames the task. The fields in double colons are the task's status, its date and its one-line note. The date and the note show only when they are set, and the status shows only when it is not the word the box already implies. The ^t- at the end of the line is the task's own id, written by the plugin, and it is what tells the app which task the line is.

A line you type yourself, with no id on the end, becomes a new task under this goal, and the rewrite turns it into a link to the file it just made. Indent it two spaces under another line and it becomes a subtask of that one. Deleting a line removes nothing: the line is back as soon as the file is saved, and the app is where a task is deleted. Meetings from your calendar show a 📅 before the id and are shown rather than edited, so a change you make to one of those lines goes nowhere and nothing on screen says so. Open tasks come first, in the app's order, and the last ten you closed follow them.

Notes and Files at the foot of the file show what is filed under the goal. The notes are links to their own files. The files are links to copies of whatever is attached to the goal, kept under LifeOps/Files in a folder named for the goal, so a PDF someone attached opens from here. Both sections are drawn every sync and save nothing, and an attachment the plugin could not fetch is left off the list rather than linked to nothing.

LifeOps/Tasks has one file per open task, flat, whatever life area or goal it belongs to. The file's name is the task, so renaming the file renames it. Its block at the top says it is a task, gives the status, the date and the kind of task it is, and points area at a life area, goal at a goal, and parent at the task this one is a step of. The status, the date, the kind, the area and the goal all save back, and emptying the date, the kind, the area or the goal clears it in the app. parent is shown rather than edited, and the app is where a task is made a step of another one. A status word you do not use is refused, and so is an empty status, since a task always wears one of yours.

Under the title comes the task's own writing, the same words the task's page holds in the app, and editing it saves back. Subtasks at the foot appears on a task that has steps, one line per step in the same form a goal file uses, and a line you type there with no id becomes a new step under this task.

Closing a task takes its file out of the folder. Tick the box on its line in a goal file, or type one of your closed words as the status here, and the file goes at the next sync. Afterwards it shows under Done that day in that day's journal file, on a day you wrote something on. A task your deferral hides until tomorrow leaves the folder the same way and is back when it is due.

A meeting from your calendar is a task here and gets a file like every other, marked readonly at the top because its words belong to the calendar it came from. What you type into one is never sent.

LifeOps/Notes has one file per note, flat, each named by the note's title. Renaming the file renames the note. Its block at the top gives the kind of note it is, its date and a one-line description, and points area, goal and event at whatever the note is filed under. Each of those saves back, and repointing one refiles the note. A note you never described has no description line at all. Everything under the block is the note itself, and editing it saves.

A note holding a picture shows the picture. The plugin fetches it, keeps it under LifeOps/Files in a folder named for the note, and points the note at that copy, so it draws in Obsidian instead of reading as a file that cannot be found.

That same note is read-only. Plain text cannot hold a picture, a table or a video, so a note with one of those is marked readonly at the top and starts with the line This note holds content markdown cannot carry. Edit it in the app. Its words are still there to read. What you type into it is never sent, and the app's own editor is where that note is changed.

LifeOps/Journal has one file per day you wrote something on, and a file is named 2026-09-11.md. That is the name Obsidian's own daily notes use, so a date anywhere in your vault links straight to the day it names. Each entry is a block under a heading giving the time in hours and minutes, then the life area and then the goal it is filed under, each of those when it has one, so an entry with neither is the time alone. The words under a heading are yours to edit and they save back. A new block with words under its heading becomes a new entry on that day, and a time in that heading puts it at that time. A heading with nothing under it posts nothing, since a block you are halfway through typing is not an entry yet.

Two things about a day file are a view rather than an edit. A heading's time is shown and read back only for a block that is new, so moving an entry to another hour is done in the app. And the Calendar and Done that day sections under your entries, which hold that day's meetings and the tasks you closed, are drawn every sync and save nothing. Both are sliced out of your task lists rather than read per day, so an old day can show fewer than it held.

Every day you have entries on gets a file, rather than a recent window of them. The first sync walks backwards a day at a time and stops after ninety empty days in a row, so a journal with no gap that long arrives whole however far back it goes, and that first walk takes a while. Days after that arrive as you write them. An entry with no words, such as a time you logged or a recording, shows its heading and the line _(no words)_ under it. A day whose last entry moves to another date takes its file with it, and a day whose last entry is deleted in the app keeps its file until something else on that day changes, which is the first of the two delays under What it does not cover.

LifeOps/Maps has a canvas for every life area with a goal still open in it, and one called Unfiled for the open goals with no area. Every goal still open in that area is a card, and opening a card opens the goal's own file. A goal you close drops off the map, and an area whose last open goal goes loses its canvas. Drag the cards wherever you want them. Where you put them is yours, and the plugin keeps it through every rewrite.

Draw an arrow from one goal to another and it becomes a link between those two goals in the app, in that direction, with whatever word you put on the arrow as its label. The browser shows it on both goals' pages, under Linked goals, so the picture you drew here is the app's own answer rather than a drawing beside it. Removing an arrow removes the link; changing its word changes the label. A goal linked to one in another area shows that other goal as a small card naming it and the area it belongs to.

Anything else you add to the canvas is yours and is kept through every rewrite: your sticky notes, your groups, and the arrows you draw between them. A goal that arrives new is placed under the ones already there rather than on top of them.

One command treats the two differently. Where you dragged the cards is remembered in the plugin's own settings rather than in the canvas, so Rebuild vault from the app draws them back where you left them. Your stickies and groups are only in the canvas file, which a rebuild throws away, so those go. Ordinary syncing keeps both.

LifeOps/Events has a file per event, flat. Renaming the file renames the event. Its block at the top gives the status and the days it runs between, including whether that end is a guess, and points area at a life area. The body under the block is the event's own writing and saves back.

The status takes one of the three words you choose between yourself, which are Maybe, Committed and Canceled. Active and Completed are read off the dates rather than chosen, so typing one of those two is refused and nothing is saved. An event whose writing holds a picture, a table or a video is marked readonly and saves nothing back, the way such a note does.

Under the body, Filed here shows what is filed under the event, the notes as links to their own files and the tasks as lines with no id on them. An event with nothing filed under it shows _(nothing filed here)_ instead. The whole section is a view, so ticking a task there does nothing and the task's own file is where a tick counts. It is also the slowest part of the vault to catch up: filing a note under an event reaches this list when the event itself next changes rather than straight away.

LifeOps/Areas has a file per life area. Three things about it save back: the name, which is the file's name, the status in the block at the top, and the description, which is everything above the first of the three headings under it. A heading of your own inside the description is safe, since the cut is made at those three and nowhere else. The area's parent and its colour are shown and are set in the app.

Under those come Goals, Open tasks and Notes, each a list of links to the files filed in this area. All three are a view, so an edit made in one of those lists saves nothing and the file that owns the thing is where the edit belongs. Take one of those three headings out and the whole file is refused until you put it back, so a description you changed in the same save waits with it. Obsidian's own backlinks panel answers the same question from the other side, and it shows the events filed here as well.

LifeOps/Reminders.md is one line per reminder, with a box to tick. Ticking one deals with it, the same as acknowledging it in the app, and changing the words changes them. Deleting a line does nothing and the line comes back, as everywhere else in the vault.

A line you type yourself is refused. A reminder needs a time, this file has no way to set one, and the notice says so and tells you to add it in the app. Because it is a refusal, nothing else in that save goes either, so take the typed line out and save again to let a tick or a reworded line through. The time a reminder is already due at reads as [at:: 9:15 AM Sep 17], and it is shown rather than edited, so rescheduling is done in the app too.

LifeOps/About.md is written out of your own words and saves nothing back. It holds your status words under their group headings, your kinds of goal, and your life areas with whatever you said each one covers, and those are the words the status, kind and area fields in the other files will accept. Under them comes a paragraph per folder saying what that folder holds and which half of it saves back, the saved views and the Files folder among them.

What you type into it is never saved back. The file is rewritten when your own words for something change, so an edit of yours stays on screen until then and goes when it does. Read it when a file refuses a status, a goal kind or an area you typed, since the word it wanted is listed there. An event's status is the exception, and its three words are in the Events section here rather than in that file.

Five views are written into a Views folder beside the others, called Tasks.base, Goals.base, Notes.base, Events.base and Journal.base. Each one is an Obsidian base, which is a saved view over the files in your vault: it asks for the files of one kind and draws them as a table you can sort, group and filter without typing anything. Opening one is how you read everything of a kind at once, which a flat folder of a hundred files does not do for you.

Each of the five asks a different question.

• Tasks shows every open task, grouped by life area, with its status, its goal and its date.
• Goals shows every goal, grouped by status, with its kind and its area.
• Notes shows every note, grouped by life area, with its kind and its date.
• Events shows every event, grouped by status, with the days it runs between.
• Journal shows every day with its date, and nothing groups it, since one file per day is already the calendar.

They are written once and then they are yours. Add a column, narrow a filter, change what a table is grouped by, or add a second view inside one of these files, and the change is still there after every sync. The plugin hands back whatever is on disk rather than drawing the view again. Delete one and it is written again as it started. Rebuild vault from the app is how you ask for all five starting views back.

Make as many of your own as you like. Obsidian's Create new base command makes one anywhere in the vault, and a base of yours reads the same files these do, since what a view asks for is the type property rather than the folder. Keep yours outside the LifeOps folder. The plugin leaves a file it does not recognise alone and says so in a notice every time that file is saved, so a base of your own in that folder would put a notice on screen every time you paused typing in it.

The plugin checks for changes when Obsidian starts, when you come back to the window, when you open a file under the LifeOps folder, and on the timer in its settings. With Live updates on, it also holds a connection open where the platform provides one, and then hears about a change made in your browser or on your phone within about a second. Each of those rounds is what this page calls a sync.

It sends a file up about a second and a half after your last keystroke in it, so a sentence you are still typing goes as one edit rather than as thirty. Only the fields you touched are sent. Files go up one at a time, and the plugin knows its own writing well enough that a file it just wrote is never sent back.

Every edit that gets sent ends with the file rewritten from the app's answer. That is what makes an id appear on the end of a task line you typed, and what puts your own spelling of a status back after you typed it another way. An edit the plugin never sends leaves the file exactly as you left it.

A refusal is a sentence rather than a silence. When something in the file cannot be honoured at all, such as a status word you do not use, nothing from that file is sent, a notice names the word that stopped it, and the file is left exactly as you typed it so you can fix it. An edit to a meeting's line is the quiet exception: that one line is dropped, the rest of the file goes, and nothing on screen says so. When your LifeOps refuses one write out of several, the notice names that write and repeats the answer your LifeOps gave, the rest of the batch stops rather than going ahead half-applied, and the file is rewritten so it shows what did land.

Two commands are in Obsidian's command palette, which opens with ⌘P on a Mac and Ctrl+P elsewhere unless you have changed the key. Both are listed under LifeOps. Sync now checks straight away, and answers LifeOps is up to date. Rebuild vault from the app throws away every file under the LifeOps folder and writes them all again from your LifeOps, which is the way back from a vault that has got into a state you do not trust. A rebuild keeps where you dragged the cards on a map and loses the stickies you drew there, so it is worth reading that section first.

Delete a goal file, a note file or any other file under the LifeOps folder and the app keeps the goal or the note. The plugin writes the file straight back and a notice says LifeOps files come back; archive it in the app to remove it. The same is true one line at a time: a task line, an entry block or a reminder line that you delete out of a file is back as soon as the file is saved.

This is deliberate. Deleting words out of a view is a common accident and destroying a record is not something a view should be able to do, so removal is a gesture you make in the app, on the page that owns the thing, and what you remove there disappears from the vault at the next sync. Notes › Putting one away covers archiving and deleting a note, which is the one you are most likely to want. One gesture in the vault does remove something, and it is on a map, where rubbing out an arrow deletes that link between the two goals.

Three things the app holds have no file in the vault, and the first is a week or a month. A week is an answer worked out over the days inside it rather than a thing you wrote, and Obsidian's own search over the journal files answers that kind of question, as does the Journal view. The photographs and videos on a journal entry are the second: the app keeps them and the vault leaves them out, so an entry that is only a recording shows its heading and the line _(no words)_ under it. The pictures inside a note and the files attached to a goal are a different matter, and the vault keeps a copy of each under LifeOps/Files. The third is the record of what changed, which is the machinery the plugin reads to keep up rather than something to edit.

Two deletions reach the vault later than the rest, and both are worth knowing so they do not read as a fault.

• A journal entry deleted in the app stays in that day's file until something else on that day changes, or until you run Rebuild vault from the app. A day is the one kind of file with no cheap way to ask the app what still exists.
• A task deleted in the app still has its file, and still shows on its goal's file, until the next sync, when the check that asks what still exists catches up. That check runs on every sync, so the gap is one check rather than an open-ended wait.

Obsidian's phone app runs the LifeOps plugin the way the desktop app does, with the same settings and the same files. The phone gets its own vault, made on the phone with iCloud storage turned off, and the plugin is installed into it with the same four steps as on a computer, then signed in. The plugin talks to your LifeOps from the phone directly, so the phone is up to date whether or not your computer is switched on, and the two vaults never need to see each other.

One difference is worth expecting. Live updates holds a connection open only where the platform allows it, which on a phone it does not, so a change you make elsewhere shows up at the next check rather than within a second. The timer in the settings is what decides that, and opening a file or returning to Obsidian checks as well.