/os-operator

name: os-operator
description: Build and schedule a personalized Operator prompt that runs the user's second brain on a recurring cadence. The skill is invoked from inside the vault folder locally — it reads `Context/` and `CLAUDE.md` first to infer org, team, brand voice, and paths, then asks ONLY the gaps it can't determine (cadence, connectors, DM recipient, budgets, signature). Fills `references/operator-prompt-template.md`, writes the rendered prompt locally, then invokes the `schedule` skill to wire up the recurring trigger automatically. Template is a generic version of a battle-tested vault Operator spec — cadence awareness, freshness, daily-as-state, idle-timeout protection, principles, hard rules, failure handling, report schema. Use when the user says "set up the operator", "build my operator prompt", "operate my second brain", "schedule my OS", "os operator", "vault operator", or runs /os-operator.
disable-model-invocation: true

OS Operator

Build a personalized Operator prompt that runs the user's second brain on a recurring schedule. The Operator is a fully autonomous maintenance agent — one session = one run, no questions, no confirmations, executes and reports.

This skill does **four** jobs, in order:

1. **Discover** what the vault already knows. Read `Context/` and `CLAUDE.md` silently — extract org name, team scope, brand voice, vault folders, runtime conventions. 2. **Ask only the gaps.** Cadence, connectors, DM recipient, budgets, signature. Don't re-ask anything Phase 0 already pulled out of the vault. 3. **Render and save** the personalized prompt locally. 4. **Schedule it.** Hand off to the `schedule` skill (via the `Skill` tool) so the trigger is wired before the run ends — the user does not need to manually run `/schedule create`.

Reference files

• `references/operator-prompt-template.md` — the parameterized prompt. ~400 lines, preserves every critical rule from the source spec.
• `references/connector-fragments.md` — spliceable body blocks per connector (transcripts, chat, community).

Read both before generating output.

---

Phase 0 — Silent discovery (no questions, no MCP calls)

The user invokes this skill **from inside their vault folder locally**. Everything here is filesystem-only. Do NOT call any `vault_*` MCP tools — the Vault MCP only matters at *runtime* when the rendered Operator agent runs.

1. **Verify the cwd is a vault.** `claude.md` or `CLAUDE.md` must exist at the cwd root. If neither exists, ask the user to `cd` into their vault and re-run. Do not proceed. 2. **List top-level folders.** `Glob` pattern `*/` at cwd. Cache the result as `{{VAULT_FOLDERS}}` (one folder name per line). 3. **Read `CLAUDE.md`.** Pull conventions: signature style, em-dash rule, voice rules, folder routing, any explicit operator paths, `os-mode` (professional vs business). 4. **Find the curated layer, then read it by subject.** Do not assume it is called `Context/`.

Resolve it: the folder named in `CLAUDE.md`'s routing table as holding identity, brand or strategy; else a top-level folder from `{{VAULT_FOLDERS}}` named `Context`, `About`, `Me`, `Identity`, `Personal`, `Brand` or similar; else the folder whose files actually carry that content. Cache it as `{{CONTEXT_ROOT}}`.

Then `Glob` `{{CONTEXT_ROOT}}/**/*.md` and read what is there. **Match on subject, not on filename**, because the same content sits at a different path in every vault:

| Looking for | Common homes | | --- | --- | | Operator profile: name, role, focus | `me.md`, `operator.md`, `personal-brand/background.md` | | Org name, mission, products, locations | `business.md`, `organization.md`, `company.md` | | Team member full names, roles, who handles what | `team.md`, or one file per person under a `Team/` role folder | | Voice, and any hex colors that could seed the signature | `brand.md`, `voice.md`, `personal-brand/voice.md`, `brand/brand-kit.md` | | Current focus, OKRs, the funnel or workstream map | `strategy.md` | | Who the audience is | `icp.md`, or one file per segment under `icp/` | | External people to be aware of, outside team scope | `stakeholders.md` |

A row with no match is a gap, not an error: note it and carry on. A row matched by several files reads all of them. **Never write to this layer**, it is human-owned. 5. **Cache inferred values:**

• `{{ORG_NAME}}` ← from whichever file matched the org row in step 4 (title heading or `name:` frontmatter). If none, fall back to the cwd folder name.
• `{{TEAM_MEMBERS}}` ← comma-separated full names from whatever matched the team row: one file, or one file per person. If solo (`os-mode: professional`), use the operator's own name from the operator-profile match.
• `{{EXAMPLE_TEAM_MEMBER}}` ← first name in `{{TEAM_MEMBERS}}`.
• `{{OPERATOR_NAME}}` (default) ← `{{ORG_NAME}} Vault Operator`.
• `{{OPERATOR_HANDLE}}` ← slugified, e.g. `Vault-Operator`.
• `{{OPERATOR_BASE_PATH}}` ← `/Team/{{ORG_NAME}}/Profiles/Vault-Operator/` if `Team/` is one of the discovered top-level folders, else `/{{ORG_NAME}}/Vault-Operator/`.
• `{{PROFILE_BASE_PATH_PATTERN}}` ← `/Team/{{ORG_NAME}}/Profiles/{Name}/` if applicable.
• `{{BRIEFING_FOLDER}}` ← **the vault's own dated-log convention, discovered not assumed.** Resolve in order: a top-level folder from `{{VAULT_FOLDERS}}` already holding `YYYY-MM-DD.md` files; else the folder `CLAUDE.md`'s routing table names for daily logs or run logs; else a folder named `Daily`, `Journal`, `Logs` or similar. If none exists, ask the user where the briefing should go before writing anything, and never invent a new root folder: some vaults forbid one by rule.
• `{{BRIEFING_SUBPATH_PATTERN}}` ← the path within that folder, matching whatever date format the existing files use.
• `{{BRIEFING_PATH_PATTERN}}` ← the two joined, for display in the prompt.
• `{{VOICE_FILE}}` ← the path that matched the voice row in step 4. If several matched, the master r