lifeos

drive a lifeos vault through the lifeos cli. it's config-aware, reading your real para folder names, periodic-note formats and section headers from your plugin / aino settings, and headless, working directly on the vault folder without obsidian running. query results match what you see in the app.

intent

use this skill when you need to read, query or edit your lifeos vault from the command line. reach for it when the user asks about their tasks or 待办; periodic notes (daily/weekly/monthly/quarterly/yearly review or 日记/周记/月记/季记/年记); theme notes / para (projects/areas/resources/archives or 项目/领域/资源/归档/主题); tags / theme tags or 标签/主题标签; the lifeos ai wiki / .AI.md topic synthesis pages or 整理主题 / 更新 ai wiki; or wants to find, search, capture a thought, or check/update what's on their plate in their lifeos vault. the skill is config-aware and headless, working without obsidian running.

inputs

vault location

• auto-detected from current directory if running inside the vault.
• resolution order: vault=<path> parameter, $LIFEOS_VAULT env var, walk up from cwd for .obsidian/ or .lifeos/, last vault opened by aino.
• pass vault=<path> only when targeting a different vault than your current directory.

cli setup

• requires node.js and npm.
• runs via npx -y @life-os/cli (no global install needed; -y skips the install prompt).
• fetch the published package on first use with npx -y @life-os/cli config to confirm vault and settings.

vault structure and settings

• the cli reads your configured para folder names, periodic-note formats, section headers and templates from your plugin / aino settings.
• template variables like {{snapshot:Project}}, {{if weekday}}, {{date}} are resolved by the shared engine that powers the plugin and aino.
• ai wiki maintenance requires understanding the scope and schema from references/ai-wiki.md (bundled in .agents/skills/lifeos/).

external data (optional, context-dependent)

• theme tags (e.g. #工作, #健康) must already exist in your vault or be created with theme:create before tagging tasks or captures with them.
• queries inherit the user's local timezone for time-relative filters like due=today.

edge cases and constraints

• index-backed commands (tasks, search type=file|tag) rebuild the index per run (about 1 second on a 5k-note vault).
• search type=content scans note bodies (about 0.5 seconds) and can be slow on very large vaults.
• rate limits: none built-in; performance limits are machine-dependent.
• auth: none required; the cli reads your local vault directly.
• writes require explicit path= or ref= to prevent accidental overwrites (never guesses a note from a loose name).
• empty result sets return zero items with no error; check for Exists: no before creating missing daily notes.
• network timeouts: not applicable (local filesystem only).
• auth expiry: not applicable (local filesystem only).

procedure

step 1: confirm vault and settings

input: user asks to work with their lifeos vault. output: vault path, para folders, periodic-note format, effective settings.

run npx -y @life-os/cli config. this is mandatory first. if the cli can't find a vault, ask the user for the path and run with vault=<path>.

step 2: interpret the request as either periodic or theme

input: user's request (e.g. "what's on my plate today", "update the quarterly goals", "find notes on X topic"). output: determination of whether to query periodic notes (time-organised) or theme notes (subject-organised).

periodic notes are organised by time (yearly, quarterly, monthly, weekly, daily); use them for goals, tasks and daily records. theme notes are organised by subject via para (project, area, resource, archive) or custom tags; use them for topics. the two stay linked via theme tags. if the user mentions a day/week/month/quarter/year or "what's on my plate", work in periodic notes. if they mention a project, area, resource or named topic, work in theme notes.

step 3: query tasks (if working with periodic notes or task-related requests)

input: optional filters: tag=, keyword=, due=today|week|overdue, limit=, done|todo|all, date=YYYY-MM-DD for another day, --json for parsing. output: list of tasks with format [ ]/[x] <text> (due … !priority #tags) , <file>:<line>.

run npx -y @life-os/cli tasks [todo|done|all] with any filters. default filters to open tasks (todo); pass done or all to widen. due= queries hide completed tasks by default. note the <file>:<line> reference for later actions (e.g. toggling a task done).

step 4: query theme notes or search (if working with subject-organised content)

input: search query, type (file, tag, content), optional case flag for content, limit=, --json for parsing. output: list of matching files or tags with path:line + snippet (for content type).

run npx -y @life-os/cli search query=<text> type=file|tag|content limit=<n>. default type is file. use case for case-sensitive content search. never write blind: search first to get the exact path or tag, then act.

step 5: read a note to understand its current state

input: file name or full path. output: note content.

run npx -y @life-os/cli read file=<name> or read path=<p>. use this before editing to avoid overwriting unintended content. for periodic notes, run npx -y @life-os/cli <period> (e.g. daily, weekly) to check the path and whether the note exists, then npx -y @life-os/cli <period>:read to print it.

step 6: create or append to a periodic note

input: period (daily, weekly, monthly, quarterly, yearly), optional date (e.g. date=2025-05-30), optional section header (e.g. section="日常记录"), optional content, overwrite flag if replacing. output: resolved path, echoed after append or create.

for a daily note: run npx -y @life-os/cli daily to confirm the path, then npx -y @life-os/cli daily:append section="日常记录" content="- HH:mm #tag 内容". if the note doesn't exist, :append auto-creates it from the configured template. use section= to append into the right record heading, not the file tail. the section is created only if absent. pass date=YYYY-MM-DD to target another day.

for a missing daily note: run npx -y @life-os/cli daily:create to create it from the configured template (renders {{snapshot:Project}}, {{if weekday}}, etc.). no manual template rendering needed.

step 7: create a theme note (project, area, resource, archive, or custom theme)

input: para type (project, area, resource, archive, or theme), theme tag (e.g. tag="项目/季度OKR"), file path (e.g. path="1. 项目/季度OKR/季度OKR.md"), optional overwrite flag. output: created note with template rendered and theme tag injected into frontmatter.

run npx -y @life-os/cli theme:create type=<t> tag=<tag> path=<p>. read config first to get the real para folder names. the tag is injected into frontmatter so the theme index collects it. convention is <paraDir>/<name>/<name>.md (folder + same-named index note). pass overwrite to replace an existing note.

step 8: capture a thought into the daily note (journaling)

input: optional time (use current time from environment), optional tags (reuse existing ones from search type=tag), entry text. output: entry logged in the daily record section, resolved path echoed.

run npx -y @life-os/cli daily:append section="日常记录" content="- HH:mm #tag 内容". format as - HH:mm #tag 内容 by default. reuse existing tags (1 to 3 unless the entry needs more) rather than inventing fine-grained ones; get them via npx -y @life-os/cli search type=tag keyword=<x>. polish the user's words lightly while keeping facts, stance, emotion and first-person voice; add no judgments or advice they didn't make. when they say 原文/逐字/原样/摘抄 or paste a quote, keep it exact and only tidy markdown.

step 9: toggle a task done or back to todo

input: task reference in format <file>:<line> (from a prior tasks query result). output: task marked done or undone.

run npx -y @life-os/cli task done ref="<file>:<line>" or task todo ref="<file>:<line>". use the exact reference from the earlier tasks query result; never guess or construct a reference manually.

step 10: append to an arbitrary note

input: file path, optional section header, content. output: content appended, resolved path echoed.

run npx -y @life-os/cli append path=<p> section=<h> content=<t>. if section= is provided, the content is appended at the end of that heading (creates the section only if absent). without section=, appends to the file tail.

step 11: create a plain (non-templated) note

input: file path, optional content, optional overwrite flag. output: created note.

run npx -y @life-os/cli create path=<p> [content=]. this does not render a template (unlike <period>:create or theme:create). pass overwrite to replace an existing note. use for arbitrary notes outside the structured periodic / para system.

step 12: upgrade the skill files

input: user upgrades @life-os/cli npm package. output: skill files in .agents/skills/lifeos/ synced with the new cli version.

run npx -y @life-os/cli skill install after upgrading @life-os/cli. it copies the bundled SKILL.md and references from the npm package into your vault's .agents/skills/lifeos/ directory , no manual download or git clone.

decision points

if the user mentions a specific day/week/month/quarter/year or "what's on my plate today":

• work in periodic notes. query tasks due=<period> or run <period>:read to see the current state. use <period>:append to add entries.

else if the user mentions a project, area, resource, topic name or custom theme tag:

• work in theme notes. search with search query=<name> type=file or search type=tag keyword=<name> to find the note, then read path=<p> to open it. use theme:create to set up a new theme note, or append path=<p> to add content to an existing one.

if the vault path is ambiguous or the cli can't auto-detect it:

• ask the user for the vault path and pass vault=<path> to all commands.

if a periodic note doesn't exist and the user wants to read or append to it:

• confirm with <period> (e.g. daily) first , it echoes Exists: no. then either run <period>:create to create it from the template, or let <period>:append auto-create it. do not create a stray note manually.

if a search or task query returns zero results:

• the item does not exist in the vault. suggest the user create it (e.g. with theme:create) or check spelling / tags. don't guess or invent alternatives.

if the user wants to capture a thought or task into their daily note:

• always use daily:append with the section="日常记录" (or your vault's configured record header). never append to the file tail or the wrong section. use the current time from the environment (user is in their local timezone). reuse existing tags rather than inventing new ones.

if the user says 原文/逐字/原样/摘抄 or pastes a quote:

• keep the text exact and only tidy markdown. do not lightly polish or rephrase.

if the user asks to update or maintain the ai wiki (.AI.md topic pages, central index, changelog):

• follow the rules in references/ai-wiki.md (bundled in .agents/skills/lifeos/). it covers source scope, page schema, ingest, query and lint flows, and the concrete cli recipes that touch 7 索引/7. AI Wiki 索引.md and 7 索引/AI Wiki 变更日志.md.

if the cli can't find a note even after searching:

• don't assume it's safe to create a new one. ask the user first or search again with different keywords / filters.

if a write would overwrite an existing note:

• the cli errors with "A note already exists…" unless overwrite is passed. respect this guard. always confirm with the user before adding overwrite.

output contract

task queries

• format: [ ]/[x] <text> (due … !priority #tags) , <file>:<line>, one per line.
• the <file>:<line> is the stable reference for task done|todo.
• use --json to get structured output for parsing.

search results

• type=file: list of file paths matching the query.
• type=tag: list of tags matching the query.
• type=content: list of path:line + matching snippet, up to limit=<n>.
• use --json for structured output.

read output

• note content printed to stdout, unmodified.

period path queries

• format: <resolved-path> and Exists: yes|no.
• the path respects your vault's configured periodic-note format.

append / create / task toggle

• success: resolved path echoed (for append / create) or no output (for task toggle).
• error: human-readable message, non-zero exit code (e.g. file-not-found, already-exists, invalid reference).

config output

• vault path, para folders (with user's real names, e.g. 1. 项目), periodic-note format, section headers, effective settings.

ai wiki maintenance

• commands touch 7 索引/7. AI Wiki 索引.md (central index), 7 索引/AI Wiki 变更日志.md (changelog), and .AI.md sibling files next to topic notes.
• follow references/ai-wiki.md for ingest, query and lint recipes.

outcome signal

• tasks query: you see today's open tasks formatted as [ ] <text> (due … !priority #tags) , <file>:<line>, matching what appears in the plugin/aino.
• search result: you get matching file paths, tags or content snippets with line numbers, ready to read or edit.
• read: you see the full note content, confirming it's the right target before editing.
• append / create: the cli echoes the resolved path, confirming where the entry landed. for auto-created periodic notes, the note is created from the configured template with variables resolved (no manual template work needed).
• task toggle: the task is marked done or undone; re-query tasks to verify the change.
• capture to daily note: the entry lands in the correct section of today's daily note (or another specified date), timestamped and tagged, ready to resurface under the matching theme note via the tag.
• theme note creation: the note is created with the template rendered, the theme tag injected into frontmatter, and the file placed at the path you specified (convention: <paraDir>/<name>/<name>.md), so the theme index collects it.
• config confirmed: vault path, para folders, periodic-note format and section headers match your plugin/aino settings, so all queries and writes are accurate.
• errors are explicit: if something fails (file not found, already exists, invalid reference), the cli prints a human-readable message and exits non-zero.