LifeOS

CommunityPopular

danielmiessler

LifeOS

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).

Overview

Publisher	danielmiessler
Repository	`LifeOS`
Skill name	`LifeOS`
Stars	19K
Forks	2.5K
Bundled files	24
License	MIT
Links	Skill source Repository Homepage

Markdown instructions
A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.
Works with any LLM
AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.
24 bundled files
Scripts, templates, and references the model can read while it works. Files are read-only and never executed.
Open source
Published by danielmiessler on GitHub. Read the source before you install it.

Installation

Install the LifeOS AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

Open the app and go to Plugins → Skills.
Choose "Install from GitHub".
Paste the skill folder URL below and confirm.
Enable the skill in any chat where you want it available.

Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills

git clone --depth 1 https://github.com/danielmiessler/LifeOS.git /tmp/LifeOS
mkdir -p .claude/skills
cp -r /tmp/LifeOS/LifeOS/install/skills/LifeOS .claude/skills/LifeOS

Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable LifeOS in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads LifeOS on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so LifeOS is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

Loaded only when it is needed
The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.
Switch models mid-chat
Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

LifeOS

This is the INSTALLED copy of the LifeOS skill, not the distribution root. Its install/ directory holds only bootstrap files; the whole-system payload lived in the release artifact you installed FROM and is now deployed across ~/.claude. Statements below about the skill being self-contained describe that release artifact, not this directory. Run the setup and deploy tools from ~/.claude, not from here — relative paths do not resolve in this copy.

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.

The two phases

Setup (logistics, first). Detect OS + harness → scan for conflicts and surface them → install prerequisites → overlay the system templates → scaffold the USER tree + link it → trust-gated hook install (show the exact change, back up settings.json, wait for yes) → activate the identity imports → verify with two evidence classes. Adapts to OS (macOS/Linux/Windows) and harness (Claude Code / Hermes / Cursor / OpenClaw).

Interview (meaning, second). Name the DA → principal identity → TELOS current state → TELOS ideal state → pull in external sources the user provides (existing notes, configs, exports) to enrich USER context → seed Pulse. By the end, the config tree is populated and Pulse shows real data, not empty scaffolding.

Hard rules

Setup before Interview, always. Hooks/integration land before any onboarding write.
Additive, never clobbering. install.sh touches only the LifeOS skill dir; setup writes are existsSync-guarded. Never overwrite or rm a populated dir or a foreign file.
Permission before mutation. Hook install shows the exact change (file count + settings entries) and backs up settings.json first. Nothing changes without an explicit yes.
Config root keeps its canonical name. The user tree lives under the config dir and is linked into the harness tree; "LifeOS" is the brand, the resolved config path does not rename (renaming it breaks the identity @-imports).
Dev-tree refusal. The hook install refuses to run inside the LifeOS source repo (detected via dev-tree markers — the private maintenance skill present, or a recognized source-repo git remote). Never mutate the author's live system.

Gotchas

The frontmatter version: is the COMPONENT line, not the release. Claude Code ignores it; the maintainer-side BumpSkillVersions (not shipped) maintains it at the source repo. The DISTRIBUTION version is the tag + LIFEOS_RELEASES/<version>/ + the install.sh fetch.
install.sh is non-destructive by design. It installs only the LifeOS skill and backs up only a prior LifeOS skill — never the user's other skills, hooks, or config. The whole point is "bolt on, don't take over."
Hooks are installed imperatively, with permission. A bare skill cannot auto-wire hooks; the setup workflow writes them into the user's harness explicitly, after showing what changes.
Config is .toml, never .yaml. LifeosConfig.ts reads TOML; the legacy .yaml template was retired 2026-06-19.
Cross-platform is solved at setup time, not statically. The setup conversation detects the OS + harness and tailors hook commands and paths — don't assume macOS.

Examples

"install LifeOS" → install.sh drops the skill, then /LifeOS setup runs: detect env, surface conflicts, wire hooks with permission, scaffold the USER tree, then roll into the interview.
"run the lifeos interview" → Interview workflow: capture TELOS + current/ideal state, pull in the user's sources, seed Pulse.
"lifeos doctor" → run Doctor.ts, relay the capability table, offer the fix command for anything broken.
"update LifeOS" → Update workflow: idempotent re-overlay after a version bump, non-destructive.

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the LifeOS AI skill do?

Why use LifeOS on TypingMind?

Because you install it once and use it with any model. LifeOS is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install LifeOS in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/danielmiessler/LifeOS/tree/main/LifeOS/install/skills/LifeOS. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use LifeOS?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with LifeOS?

As many as you like. As long as a model supports skills, you can use LifeOS with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the LifeOS AI skill free?

Yes. It is published on GitHub by danielmiessler under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Mem Setup

thedotmack

CommunityPopular

This skill should be used when the user asks to "set up claude-mem", "pair claude-mem", "connect cmem", "add my cmem key", "set up cloud sync in Cowork", or provides cmem.ai Connect values (sync…

Wizard

Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar…

Deployment Patterns

Flujos de trabajo de despliegue, patrones de pipeline CI/CD, contenedorización Docker, health checks, estrategias de rollback y listas de verificación de preparación para producción de aplicaciones…

Docker Patterns

Patrones de Docker y Docker Compose para desarrollo local, seguridad de contenedores, networking, estrategias de volúmenes y orquestación de múltiples servicios.

Overview

Installation

Install in TypingMind

Install in another agent

Use it in TypingMind

Works with any AI model

Skill instructions

LifeOS

How it ships

Workflow Routing

The two phases

Hard rules

Gotchas

Examples

Bundled files

Frequently asked questions

Related AI Skills

Set up your own AI workspace now