core-install

core-install

Mandatory integrity contract

Before acting, load and follow ../../references/data-integrity.md. Its provenance, missing-value, correction-history, defensive-write, backup, and recovery rules are mandatory for this subskill.

Install Agentic Life OS private state and make the umbrella skill visible to the current runtime. Install is a conversation and inspection workflow, not a blind script. Life OS is a helper over the runtime: it records where things live and how to access them, rather than becoming the owner of calendars, tasks, memory, crons, vaults, or delivery.

Trigger

Use when the user asks to install, set up, register, enable, connect, or try Agentic Life OS in Hermes, OpenClaw, or another agent runtime.

Principle

The helper may create private Life OS state files. The LLM owns the install decision flow:

• detect the active runtime
• check whether the skill is already visible
• discover existing runtime-owned systems
• explain bridge/import/migration choices
• ask before changing runtime-owned config, crons, delivery, skills, or memory

Do not add helper-script heuristics for runtime discovery. Runtime installations differ too much, and a script guessing paths is how you build a brittle little monster.

Procedure

1. Detect the current runtime from command availability, session context, repo docs, and user request.
2. Load only the matching runtime adapter for the active runtime:
   • shared runtime adapter: ../../runtimes/<runtime>.md
   • core-install adapter: runtimes/<runtime>.md
3. Do not load both Hermes and OpenClaw adapters for a single install. Keep runtime-specific instructions in those Markdown files, not inline here.
4. Check whether the umbrella life-os skill is already visible to that runtime.
5. If it is visible, do not re-register it. Run only private state install/doctor from the repo checkout.
6. If it is not visible, ask the user which registration scope and install mode they want using the runtime adapter:
   • symlink for live development
   • copy for a static snapshot
   • profile/workspace/agent/shared scope depending on runtime
7. Before proposing any integration, investigate runtime-owned systems with native runtime commands or docs:
   • tasks or background-task ledger
   • crons, schedules, heartbeat, reminders, hooks, standing orders
   • memory and vault/secrets systems
   • delivery routes and messaging channels
   • tools, sandboxing, model/provider config
   • profiles, agents, workspaces, or channel bindings
8. Present options before changing anything:
   • leave the runtime system alone and only read it when relevant
   • record a pointer/reference and bridge through runtime-native tools
   • import selected pointers, access notes, or Life-OS-specific state into config
   • migrate/reconnect references when moving between runtimes, using runtime-native stores for real data where possible
9. Ask approval before creating any bridge, import, migration, cron, delivery route, global skill registration, config edit, or destructive change.
10. Run private state install and doctor.
11. If doctor.semantic_health.complete is false, ask the next pending setup question from python3 scripts/lifeos.py next-question. The install must ask for the autonomy mode in plain human language, not just technical names; recommend safe-internal if the user is unsure.
12. Save each approved answer with python3 scripts/lifeos.py answer <key> '<answer or runtime pointer>' --kind <reuse_existing|manual_only|propose_change|disabled|custom>.
13. Autonomy modes are install-wide policy:

• approval-first: ask before every write or external/runtime change.
• safe-internal: default; allow read-only inspection and Life OS private tracking writes, ask before external/runtime/destructive/public changes.
• trusted-local: allow clearly scoped reversible local maintenance, still ask before external/destructive/public/account changes.
• allow-all: proceed only within the explicit saved policy and runtime safety layer; still escalate dangerous, credential, legal, destructive, or external-contact actions.

1. Review meeting crons are part of setup completion. Either create/reuse the approved runtime cron jobs for review meetings, or save the user's explicit manual-only/disabled opt-out. Do not claim setup complete while this is undecided.
2. Repeat doctor -> next-question -> ask -> answer until semantic health is complete, or until the user explicitly stops setup.
3. Use python3 scripts/lifeos.py plan to show runtime cron templates and remaining steps without creating jobs.
4. Verify with runtime-native skill visibility commands and lifeos.py doctor.