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
3. Resolve the private data directory:
   • $HOME/.life-os by default
   • LIFEOS_DATA_DIR if set
4. Read skill-index.yaml.
5. Read <data-dir>/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 <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.
6. Classify the user request or scheduled trigger.
7. Load only the subskills needed for that intent.
8. 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.
9. For setup/integration tasks, investigate existing runtime-owned systems with runtime-native discovery before proposing bridges, imports, migrations, schedules, or delivery routes.
10. 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.
11. 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.
12. 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.
13. Execute the selected playbook with runtime-native tools.
14. Record short coordination state in $LIFEOS_DATA_DIR/<skill-name>/data.json or config when useful.
15. Surface only actionable output.