LifeOS — скилл

---
name: LifeOS
version: 1.5.43
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. 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).
disable-model-invocation: true
argument-hint: "[setup|interview|doctor|update|uninstall]"
allowed-tools: Read, Write, Edit, Bash, Glob, Grep
---

# LifeOS

The install + 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.

## How it ships

LifeOS is distributed as **one self-contained skill** — the `LifeOS/` directory is the *entire* distribution. Everything ships inside it: the orchestrator (`SKILL.md`, `Workflows/`, `Tools/`), the whole-system payload under `install/`, and the one-line bootstrap at `install/install.sh`. **Nothing ships outside the skill** — no release-root `install.sh`, no `.claude/` clone.

**The primary install is AI-native: give `INSTALL.md` (served at `ourlifeos.ai/install`) to your AI and say "install this."** LifeOS is AI-native, so the install is too — you hand the doc (or its link) to whatever harness you already use, and your AI installs LifeOS on your OS and harness, with permission at each step. It's the same document a human can read and follow. `INSTALL.md` opens with a capability gate, drives the install Tools (which run under `bun` on any OS, not a shell), wires integration per-harness (honest about what each gets), then runs Setup → Interview.

A terminal shortcut stays for Claude Code on macOS/Linux:

```
curl -fsSL https://ourlifeos.ai/install.sh | bash
```

Both are served from the skill's own single sources of truth — `INSTALL.md` at the skill root, `install/install.sh` for the shell path (which hands off to the agentic `/LifeOS setup`). Two versions coexist and mean different things: the frontmatter `version:` is this skill's own **component** line (bumped by the maintainer-side `BumpSkillVersions`, which does not ship in the release), while the **distribution** version — what a user means by "LifeOS 7.x" — is the GitHub release tag and the `LIFEOS_RELEASES/<version>/` parent dir. Never read the component line as the release number. The payload (skills, hooks, system prompt, Algorithm, docs, runtime tools) rides along under `install/` and is placed during setup, with permission.

## Workflow Routing

| Trigger | Target |
|---------|--------|
| `setup`, `/LifeOS setup`, "install LifeOS", "integrate into my harness" | `Workflows/Setup.md` |
| `interview`, "onboard me", "run the interview", TELOS capture | `Workflows/Interview.md` |
| `doctor`, "check my install", "what's broken", "what capabilities are live" | run `bun <configRoot>/LIFEOS/TOOLS/Doctor.ts` (see `INSTALL.md`) |
| `update`, "update LifeOS", after a version bump | `Workflows/Update.md` |
| `uninstall`, "remove LifeOS" | `Workflows/Uninstall.md` |

`doctor` is the one tool-backed route — it needs no workflow because `Doctor.ts` is self-describing: it prints the four capability states (live / broken / declined / stale) and the exact fix command for anything broken. Relay its table, offer the fix it names, and honor `decline` — a declined capability is a legitimate way to run LifeOS, never a defect to nag about.

Default flow (`/LifeOS setup`): **Setup phase** (system integration) → transitions into **Interview phase** (life onboarding). One continuous experience, two clearly-marked phases — setup is logistics, interview is meaning. Setup ALWAYS runs first; hooks must be wired before the interview seeds anything.