/LifeOS

name: LifeOS
metadata:
  short-description: "Installs, onboards, updates, diagnoses, and uninstalls LifeOS, and reports bugs or features to the project, across supported harnesses."
version: 1.6.13
evals:
  deterministic:
    - command: "bun skills/LifeOS/Tools/PulseHealth.ts audit"
      falsifier: "the command exits nonzero when a Pulse check that ran fails (schema tool, provenance of the USER template copies, or the service's /healthz); a check that cannot run prints NOT RUN instead of passing"
description: Install and onboard a user into LifeOS — the Life Operating System (current state → ideal state via TELOS + the Algorithm). The agentic installer detects your OS + harness, wires hooks with permission, scaffolds your USER tree, pulls in sources you provide, and runs the TELOS / current→ideal interview that seeds your Pulse dashboard. USE WHEN install LifeOS, set up LifeOS, lifeos setup, lifeos-setup, lifeos interview, onboard me, run the interview, integrate LifeOS into my harness, update LifeOS, uninstall LifeOS, first-time setup, lifeos doctor, check my install, what capabilities are broken, pulse setup, set up pulse, install pulse, audit pulse setup, is Pulse healthy, report a LifeOS bug, file an issue upstream, report this to the project, contribute this fix, open a PR to LifeOS, suggest a feature, ask the LifeOS project. NOT FOR building or cutting a LifeOS release (private release tooling), editing TELOS after onboarding (use Telos / Interview), or LifeOS system maintenance (use the private maintenance skill).
argument-hint: "[setup|interview|doctor|update|uninstall|report]"

LifeOS

> **This is the INSTALLED copy of the LifeOS skill, not the distribution root.** > Its `install/` directory holds only bootstrap files. To update, follow `Intents/Update.md`: it first runs > `bash <configRoot>/skills/LifeOS/install/install.sh` to fetch the full release skill. Only then run > the payload tools — OverlaySystem, InstallHooks, and ScaffoldUser — which need that full payload. > Run every tool by its full path: `bun <configRoot>/skills/LifeOS/Tools/<Tool>.ts`.

The install and onboarding surface for **LifeOS**, the Life Operating System. One command takes a stranger on any harness from nothing to a working, personalized install whose Pulse dashboard already shows their current state vs ideal state, without making them adopt a whole new harness.

Ideal State

• A stranger on any supported OS and harness ends with a working, personalized install: Core placed after one consent, every enhancement they did not decline, identity placeholders gone, the `lifeos` launch command wired, and Pulse showing their own current and ideal state.
• Every change to the user's machine was shown before it happened and is reversible: settings and shell rc are backed up first, updates and uninstalls move or back up instead of deleting, and nothing the user authored is overwritten.
• Setup completes and its hooks and integration are in place before the Interview writes anything.
• Nothing changes without an explicit yes, during the install and afterwards, unless the user turned on the opt-in `automode` component (`Intents/Setup.md` step 7), which ships off and needs a clear yes.
• Every "installed", "updated" or "removed" claim rests on the evidence the intent names, and a capability the user declined is reported as declined, never as broken.
• Feedback sent upstream is redacted, reproducible and posted only on the user's own yes.

Intent Routing

| Intent | Trigger | File | |--------|---------|------| | **Setup** | `setup`, `/LifeOS setup`, "install LifeOS", "integrate into my harness" | `Intents/Setup.md` | | **Interview** | `interview`, "onboard me", "run the interview", TELOS capture | `Intents/Interview.md` | | **Doctor** | `doctor`, "check my install", "what's broken", "what capabilities are live" | run `bun <configRoot>/LIFEOS/TOOLS/Doctor.ts` (`Intents/Setup.md` step 9.6) | | **Pulse** | "set up pulse", "pulse setup", "audit pulse setup", "is Pulse healthy" | `Intents/Setup.md` step 8.6: `bun Tools/PulseHealth.ts audit` reports Pulse health read-only | | **Update** | `update`, "update LifeOS", after a version bump | `Intents/Update.md` | | **Uninstall** | `uninstall`, "remove LifeOS" | `Intents/Uninstall.md` | | **Report** | `report`, "report this bug", "file an issue", "contribute this fix", "open a PR", "suggest this to the project", "ask the LifeOS project" | `Intents/Report.md` |

| File | Read when | |------|-----------| | `INSTALL.md` | the AI-native install document (served at `ourlifeos.ai/install`; host is `install_host` in `<configRoot>/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/LifeOS/Config.md`): capability gate, prerequisites, release fetch, `DetectEnv`, harness integration, the support table and the install rules; everything after the fetch is `Intents/Setup.md` | | `Workflows/Update.md` | an install from before 2026-10-08 whose Update step re-reads this path: a signpost that sends the agent to `Intents/Update.md` | | `GETTING-STARTED.md` | after the install: the optional external tools (codex, Interceptor, cf, Fish Audio, gh, and smaller ones), what each powers and how to prove it is live | | `References/HermesSidecar.md` | the user said yes to the Hermes sidecar offer in Setup step 9.5: the pinned install, its own device-code login, the evidence-based guard check and the two disclosures to make | | `install/` | the whole-system payload (skills, hooks, system prompt, Algorithm, docs, runtime tools, placed during setup with permission) and the bootstrap `install/install.sh` (served as `ourlifeos.ai/install.sh`); data the install Tools read and place, never edited by hand. The `LifeOS/` directory is the entire distribution: no release-root `install.sh`, no `.claude/` clone |

`doctor` is the one tool-backed route: `Doctor.ts` prints each capability's state and the fix for anything broken. Relay it and honor `decline` (Setup step 9.6).

Data & Config

`<configRoot>` is the harnes