Life Os

Life OS

Use this skill as the stable entrypoint for Agentic Life OS.

Mission

Act as a portable helper and coordination layer that makes the active runtime more useful. Life OS is not the new owner of the user's life data. The product is the agent behavior: knowing what to inspect, where each source of truth lives, what to ignore, when to ask, when to write private coordination state, and how to surface useful output without turning the user's life into one giant prompt blob or duplicated database.

The agent operates the system. The user should see clear decisions, questions, and outcomes, not a pile of commands to run manually. Helper scripts are for deterministic state mechanics and validation; the agent uses them, interprets the result, and continues the workflow.

The heartbeat vision is a dynamic heartbeat, not a fixed watchdog. Life OS should keep a capability inventory of runtime skills, tools, adapters, sources, and active watch targets. Life OS decides what deserves attention; runtime adapters execute access. Do not hard-code a universal list of checks into the heartbeat when the runtime can discover capabilities and load the relevant skill on demand.

Operating model

1. Detect the current runtime and conversation mode.
2. If the task touches runtime behavior, load the matching runtime adapter:

• runtimes/hermes.md for Hermes
• runtimes/openclaw.md for OpenClaw

1. Resolve the private data directory:

• $HOME/.life-os by default
• LIFEOS_DATA_DIR if set

1. Read skill-index.yaml.
2. Read /config.json if it exists.

• Read runtime_inventory as the capability inventory: skill sources, tool sources, capabilities, and watch targets.
• If the inventory is missing or stale during setup, run npm run lifeos -- discover-runtime --runtime before proposing runtime changes.
• Use npm run lifeos -- define-heartbeat to identify the single main heartbeat. If none exists, record the quiet-heartbeat creation template and ask before creating a runtime cron.
• Use npm run lifeos -- propose-watch-targets only for extra watches the user wants to review; do not turn Life OS into a cron-inventory manager.

1. Classify the user request or scheduled trigger.
2. Load only the subskills needed for that intent.
3. If durable context is needed, use configured source pointers and access instructions. Prefer the user's existing runtime-native memory, notes, canonicals, wiki, or external systems.
4. For setup/integration tasks, investigate existing runtime-owned systems with runtime-native discovery before proposing bridges, imports, migrations, schedules, or delivery routes.
5. Run the semantic doctor. If required setup decisions are missing, tell the user the installation is not complete, show the setup checklist, inspect the active runtime for the next pending item, then propose completing the install. Save approved answers in the owning skill data file before claiming the install is complete. Setup must ask for and save an autonomy mode before completion; present the choices in plain human language first, with technical values in parentheses. Recommend safe-internal by default unless the user chooses approval-first, trusted-local, or allow-all.
6. Treat setup as revisable. If a later run discovers a better source, new memory/context system, changed delivery route, missing pointer, or obsolete runtime capability, load system-improvement and propose a setup update instead of silently continuing with stale pointers.
7. Decide and record where each source of truth lives. The LLM chooses per setup and stores that decision in config so future runs remember it.
8. Execute the selected playbook with runtime-native tools.
9. Record short coordination state in $LIFEOS_DATA_DIR//data.json or config when useful.
10. Surface only actionable output.

Semantic setup is revisable: self-improvement reviews should actively inspect available sources and capabilities, compare them against saved setup, then ask before changing the map.

Hermes and OpenClaw are first-class supported runtimes. Runtime-specific install, visibility, scheduling, delivery, and global-registration instructions must be documented for both before a workflow is considered complete. Do not add a Hermes-only step without either adding the OpenClaw equivalent or explicitly marking it as not supported yet.

Intent router

Use this routing by default:

• User asks for current context, immediate focus, a next action, or a catch-up -> load context-now.
• User asks to capture, review, prioritize, or update tasks -> load tasks-todo.
• User asks about symptoms, habits, sleep, exercise, medication notes, or care preparation -> load health-trends.
• User asks about spending signals, subscriptions, renewals, savings goals, or finance anomalies -> load finance-checkup.
• User asks about home, vehicle, appliance, warranty, insurance, or maintenance obligations -> load household-maintenance.
• User asks about identity documents, permits, contracts, certificates, domains, or other expirations -> load documents-renewals.
• User asks about trips, reservations, packing, itineraries, travel risks, or travel follow-ups -> load travel-planning.
• User asks whether to buy something, compare options, defer a purchase, or track post-purchase follow-up -> load purchase-decisions.
• User asks about courses, books, practice, study plans, learning notes, or skill-building projects -> load learning-projects.
• User asks about achievements, portfolio evidence, CV/interview material, opportunities, or professional narrative -> load work-portfolio.
• User asks about accounts, backups, devices, 2FA, domains, abandoned services, privacy, or security hygiene -> load digital-hygiene.
• User asks to record or review an important decision, options, tradeoffs, assumptions, or outcomes -> load decision-journal.
• User asks how Life OS itself is working, asks for a retrospective/sprint review, or mentions new reusable skills/templates/routine tuning -> load system-improvement.
• Scheduled frequent check or a quiet watch request -> load routines-heartbeat.
• Scheduled daily briefing, pulse, or proactive daily synthesis -> load routines-pulse.
• User mentions someone, a promise, relationship maintenance, or “remind me to follow up” -> load people-followups.
• Install/setup/repair/check -> load core-install or core-doctor.
• Mail/calendar/runtime integration details -> load the matching integrations-* skill and runtime docs lazily.

Do not load every subskill just because Life OS was invoked. That is prompt sludge.

Ownership model

Default: real user data stays where it already lives, or in the runtime/external source the LLM chooses during setup. Life OS stores the map, not the territory.

Horizontal source decisions live in global config because many skills need them:

tasks -> runtime task system
memory/context -> runtime memory or notes
calendar -> runtime calendar tool
cron_records -> runtime cron output history
review_cron_install_policy -> review meeting crons installed/reused, or explicit manual-only/disabled opt-out
knowledge/context -> optional runtime-native or external source pointers

Domain-specific source decisions live in the owning skill data file:

birthdays -> calendar tool, if owned by events-reminders or people-contacts
purchase history -> configured shopping or notes source, if owned by purchase-decisions
health signals -> configured health notes source, if owned by health-trends

A reference can include how to access the source, which runtime/tool owns it, which adapter to load, and short instructions needed for future runs. It should not include the actual full birthdays, tasks, contacts, memories, chats, or credentials.

Life OS should adapt to the user's existing knowledge setup. Do not impose a new structure or migrate memory/notes/wiki/canonicals just to match Life OS. Store pointers and instructions for how to access each source. Prefer runtime-native curated context over raw archives.

Life OS private skill state may store:

• source decisions and access instructions
• knowledge/context source pointers and retrieval notes
• pointer to the last pulse, review, or system-improvement summary
• pointer to cron/job run records
• last time a source was checked
• suppression windows such as “do not alert again until X”
• pointers to task lists or memory sources
• silence/noise preferences
• calculated priority scores
• caches and result snapshots, kept until the user or runtime policy clears them
• dated folders or dated records for persistent internal state and caches
• Life-OS-specific preferences
• technical state for a skill
• notes created explicitly inside Life OS

If a new horizontal core source has no obvious place, record the pointer in global config. If a new domain has no obvious place, prefer the runtime's own memory/notes/tasks/calendar/contact system and record the domain pointer in that skill's data file. Store real domain data in Life OS only when it is explicitly a Life OS preference, technical state, or Life OS-created note.

When moving from one runtime to another, the LLM should attempt a careful migration/reconnection of references: inspect old pointers, find the closest new runtime source, propose a mapping, and ask before changing or copying anything.

Decision policy

Safe to do autonomously:

• read Life OS repo files and private Life OS state
• run doctor/lint checks
• write Life OS private tracking state
• summarize already-available runtime state
• propose task priorities
• mark an internal routine run as recorded

Ask before:

• contacting people
• changing external calendar/mail state
• creating, deleting, disabling, or rescheduling runtime crons
• changing runtime config
• migrating, bulk-converting, moving, deleting, or publishing a user's existing knowledge store
• globally registering subskills
• deleting private state
• publishing, pushing, or rewriting public history
• broad migrations or refactors

Output contract

Prefer compact, decision-oriented output:

Now:
- Focus: ...
- Waiting on: ...
- Risks: ...
- Suggested next action: ...

For scheduled routines, silence is valid when nothing changed. Do not manufacture noise to prove the system is alive.

Deterministic helper

Use the repo helper only for boring state mechanics, not for reasoning:

python3 scripts/lifeos.py install --runtime 
python3 scripts/lifeos.py doctor
python3 scripts/lifeos.py config

The helper owns file layout and basic config containers. It does not decide what matters, generate the briefing, create runtime crons, configure delivery routes, store credentials, mutate runtime memory/vault/mail/calendar systems, or own semantic run history.

Privacy boundary

Do not store these in the public repo:

• secrets or tokens
• runtime delivery targets
• private chat IDs
• raw logs, transcripts, screenshots, or audio
• private data files

In Life OS private state, prefer pointers and operational state, but caches/result snapshots may include text when that is needed for the skill to function. Keep them organized by dated folders or dated records. Default retention is persistent: do not auto-delete private state, caches, source decisions, or pointers unless the user or runtime policy explicitly says to clear them. Never store credentials or secrets.

Subskill loading

Subskills live under:

skills/life-os/skills//SKILL.md

Default: subskills are reached through the umbrella skill, not globally registered. If the user wants a subskill globally visible, treat that as a runtime adapter decision and ask before changing runtime skill visibility.

Routine execution

For scheduled or manual routines:

1. Run doctor if install state is uncertain.

• If setup_completion.status is incomplete, do not keep discussing Life OS as if it were fully installed. Present the checklist and ask whether to complete setup after runtime discovery.

1. Load the matching routine subskill from skill-index.yaml.
2. For heartbeat-style routines, read the capability inventory and active watch targets, then dynamically load only the runtime/domain skills needed for this run.
3. Execute the playbook with runtime-native tools.
4. Record useful tracking state only when the user/runtime policy allows it, using Life OS private state or runtime-native state as appropriate.
5. Surface only actionable output to the user.

Review meetings and cadence

Prefer human-sized routine names over raw timer names:

• daily briefing: short same-day focus note
• quiet heartbeat: frequent low-noise change detector
• weekly review: guided meeting for due weekly review items
• monthly reset: guided meeting for slow-moving cleanup and due monthly items
• quarterly reset: guided meeting for strategic or structural review items

A larger routine is a container for due review items, not a fixed checklist. Each review item may have its own cadence: daily, weekly, every two weeks, monthly, quarterly, manual only, or only when a watched source changes.

When several review items are due at once, prefer a guided meeting: ask one focused question, wait for the answer, update private meeting state, then continue. If the user pauses or stops answering, record the in-progress meeting so context-now can resurface it later.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: djangonavarro220
• Source: djangonavarro220/agentic-life-os
• License: MIT

Install and usage instructions live in the source repository linked above.