# Life Os > Portable personal advisor OS umbrella skill. Use when the user asks for a pulse, briefing, current context, what to focus on, what to look at now, or the next action. - **Type:** Skill - **Install:** `agentstack add skill-djangonavarro220-agentic-life-os-life-os` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [djangonavarro220](https://agentstack.voostack.com/s/djangonavarro220) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [djangonavarro220](https://github.com/djangonavarro220) - **Source:** https://github.com/djangonavarro220/agentic-life-os/tree/main/skills/life-os ## Install ```sh agentstack add skill-djangonavarro220-agentic-life-os-life-os ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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 `/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. 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//data.json` or config when useful. 15. 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: ```text 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: ```text 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: ```text 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: ```bash 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: ```text 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. 2. Load the matching routine subskill from `skill-index.yaml`. 3. For heartbeat-style routines, read the capability inventory and active watch targets, then dynamically load only the runtime/domain skills needed for this run. 4. Execute the playbook with runtime-native tools. 5. Record useful tracking state only when the user/runtime policy allows it, using Life OS private state or runtime-native state as appropriate. 6. 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](https://github.com/djangonavarro220) - **Source:** [djangonavarro220/agentic-life-os](https://github.com/djangonavarro220/agentic-life-os) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-djangonavarro220-agentic-life-os-life-os - Seller: https://agentstack.voostack.com/s/djangonavarro220 - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.