Baalda Operator

Build a personalized Operator prompt that runs the user's Baalda vault on a recurring schedule.

Baalda ground rules (read once, obey throughout)

These are app invariants, not preferences. Breaking them corrupts note identity or the sync state, and the Operator runs unattended, so a broken rule compounds across every run.

1. Run from the vault root. The vault root is the folder the user opened in Baalda.
2. .context/ is off-limits. Baalda keeps its SQLite index, CRDT store and config.json there. Never read, write, walk or index it. Same for .git and attachments/.
3. Write files, don't shell out to move them. Creating and editing .md files with normal tools is fully supported: the watcher picks the change up in about 150ms and merges it as a CRDT operation, so an Operator edit and a human keystroke coexist instead of clobbering.
4. Never mv or rm a synced note. A note's identity is a doc_id, not its path. An external move reads as delete plus create: the note gets a new doc_id and its history, backlinks and share settings do not follow. The Operator moves and renames through move_note / move_folder on the Baalda MCP, or not at all.
5. Prefer [[wikilinks]] over relative paths so links survive a later move.

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 Baalda vault that has been set up. Print the current directory and check for both markers:

   pwd && ls -a | grep -E '^\.context$' || echo "no .context/ — not yet opened in Baalda"
   

   • .context/ present → this folder is a Baalda vault. Good.
   • .context/ absent → the folder has never been opened in Baalda. Say so, and continue only if the user confirms this is the right folder. Do not create .context/ yourself.

   Then confirm claude.md or CLAUDE.md exists at the cwd root. If neither exists, the vault has not been set up: point the user at /setup and stop.

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 register rather than a per-channel delta. If none, leave it as the vault's CLAUDE.md and say the voice rules came from there.
   • {{SIGNATURE_BG_COLOR}} ← any brand color hex found in whatever matched the voice-and-colors row, else #D2ECD0.
   • {{SIGNATURE_FG_COLOR}} ← #020309.

After Phase 0, summarise to the user in 4–6 short lines what you found. Format:

Discovered from your vault:

• Org: {{ORG_NAME}}
• Team: {{TEAM_MEMBERS}}
• Top-level folders: {count} ({list first 5})
• Operator path (proposed): {{OPERATOR_BASE_PATH}}
• Brand signature color (proposed): {{SIGNATURE_BG_COLOR}}

Anything to override? (Type the field name, or say "looks good" to continue.)

If the user wants overrides, accept them inline (one short follow-up) and update the cache. If "looks good", proceed straight to Phase 1.

Do not re-ask any of the above as standalone questions. They were inferred. Phase 1 is for things the vault genuinely cannot tell you.

---

Phase 1 — Ask only the gaps

These are the questions the vault cannot answer. Ask one at a time with AskUserQuestion.

Q1 — Cadence

AskUserQuestion with options:

• Hourly — every hour, max throughput. Best for active teams.
• Every 4 hours — balanced. Catches new transcripts/chat without spamming.
• Daily — one run per day. Best for solo or low-volume.
• Custom — user types a cron expression or phrase.

Save as {{CADENCE_HUMAN}} and {{CADENCE_TAG}}.

Q2 — Connectors (probe live, do not just ask)

Don't show the user a checklist of connectors and trust their answer. Probe what's actually wired up in this environment, then confirm.

Step 2a — Detect

Inspect the running session's available tools. Look for tool names matching these prefixes (any namespace — mcp__*, plain, or vendor-specific):

Category	Detection signal	Live probe (read-only)
Vault	Baalda MCP: list_vaults, list_folders, list_notes, read_note, create_note, update_note, append_note, move_note, move_folder, search_notes (any namespace)	Call list_vaults, then list_folders on the matching vault. Success = the vault appears and its folders come back.
Transcripts	fireflies_*, otter_*, granola_*, read_ai_*	Call the connector's "list recent" / "get transcripts" with a 1-item or 24h window. Success = ≥0 results, no auth error.
Chat	slack_*, teams_*, discord_*, telegram_*	Call the connector's "list channels" / "search users" / equivalent read-only call. Success = response, no auth error.
Community	circle_*, discourse_*	Call list_spaces / categories with per_page: 1. Success = response.

Run all detected probes in parallel in one batch. Narrate before the batch ("Probing 3 connectors live: vault, fireflies, slack…") and after ("Vault OK (13 folders). Fireflies OK. Slack auth error.").

For each connector:

• ✅ Found and probe succeeds → mark enabled. Capture the actual MCP/tool prefix as {{*_MCP_NAME}} and infer the product name (e.g. fireflies → Fireflies).
• ⚠️ Found but probe fails (auth error, 401, empty creds) → mark "wired but broken". Tell the user the exact error and ask whether to (a) skip this connector, (b) pause so they can fix the credentials and re-run the probe, or (c) include it anyway.
• ❌ Not found → mark disabled. Do not ask "do you want to add it?" — that's a separate setup task. The user can re-run /os-operator later after wiring a new MCP.

Step 2b — Confirm with the user

Show one summary block:

Connectors detected:

• ✅ Vault MCP — relay-mcp (13 folders)
• ✅ Transcripts — fireflies (last transcript: 2 hours ago)
• ✅ Chat — slack (12 channels visible)
• ❌ Community — none detected

Use these in the Operator? (yes / customize)

If the user says "customize", let them toggle individual entries off (but never on for something not detected — they need to wire that MCP first). If they say "yes" or just confirm, proceed.

Save

• {{TRANSCRIPT_PRODUCT_NAME}} and {{TRANSCRIPT_MCP_NAME}}
• {{CHAT_PRODUCT_NAME}} and {{CHAT_MCP_NAME}}
• {{COMMUNITY_PRODUCT_NAME}} and {{COMMUNITY_MCP_NAME}}
• {{VAULT_MCP_NAME}} (whatever the probe identified — default relay-mcp if ambiguous)

Probes are read-only by design. Never invoke a write/send tool during detection (no DMs, no posts, no file writes).

Q3 — Which Baalda vault (only if the Baalda MCP is wired)

The Baalda MCP can serve more than one vault, and the rendered Operator has to name the right one on every call. Call list_vaults and match against the cwd folder name.

• Exactly one vault, and it matches the cwd → use it, do not ask.
• Several vaults → AskUserQuestion listing them, defaulting to the one whose name or path matches the cwd.
• No match → tell the user the cwd is not a vault the MCP can see, and ask whether to continue local-file-only (the Operator then uses Read / Write instead of MCP calls, which works but loses move_note safety).

Save as {{VAULT_NAME}}.

Baalda addresses notes by vault plus a path from the vault root, so there is no root-folder-name quirk to work around and no {{ROOT_FOLDER_NAME}} to capture. The Baalda template does not use it.

Q4 — DM escalation recipient (only if chat connector is enabled)

When the Operator finds a community post or chat thread that needs human action, who receives the 1:1 escalation DM? One person only. No channels, no groups.

Default the picker to names in {{TEAM_MEMBERS}} so the user can pick rather than retype. Save as {{DM_RECIPIENT_NAME}}.

If no chat connector is enabled, skip this question. Set {{DM_RECIPIENT_NAME}} to the operator's own name from the operator-profile match in step 4 — the placeholder is referenced in a few sections that will be stripped during render anyway.

Q5 — Budgets

AskUserQuestion with options:

• Defaults — 50 reads, 30 writes, 20 transcripts, 5 DMs, 10 housekeeping fixes per run.
• Light — 25 / 15 / 10 / 3 / 5. Solo / low-volume.
• Heavy — 100 / 60 / 40 / 10 / 20. Large teams / daily cadence.
• Custom — user types overrides.

Save as {{BUDGET_READS}}, {{BUDGET_WRITES}}, {{BUDGET_TRANSCRIPTS}}, {{BUDGET_DMS}}, {{BUDGET_HOUSEKEEPING}}.

Q6 — Signature color (only if Phase 0 didn't infer one)

If step 4 already produced a brand color, skip this. Otherwise:

The Operator stamps every file it edits with a colored span. Pick a background color (default: #D2ECD0, soft mint green). Foreground default: #020309.

Save as {{SIGNATURE_BG_COLOR}} and {{SIGNATURE_FG_COLOR}}.

---

Phase 2 — Render

1. Read references/operator-prompt-template.md.
2. Read references/connector-fragments.md.
3. Replace every {{PLACEHOLDER}} with the captured value. For connector-specific placeholders ({{TRANSCRIPTS_BOOTSTRAP_LINE}}, {{CHAT_BOOTSTRAP_LINE}}, {{COMMUNITY_BOOTSTRAP_LINE}}, {{TRANSCRIPTS_STEP_BODY}}, {{COMMUNITY_STEP_BODY}}, {{CHAT_STEP_BODY}}, {{ENABLED_CONNECTORS_LINE}}, {{MCP_BLOCK}}):
   • Enabled connector → splice in the Enabled block from connector-fragments.md, then re-run placeholder substitution on any nested placeholders.
   • Disabled → drop the section header AND the placeholder. Strip remaining mentions of that connector's product name from Hard Rules, Failure Handling, and Report Schema.
4. Derive path-split values from {{OPERATOR_BASE_PATH}} and {{PROFILE_BASE_PATH_PATTERN}} so MCP examples are correct:
   • {{OPERATOR_TASK_LIST_PATH}} = {{OPERATOR_BASE_PATH}}task-list/Tasks.md
   • {{OPERATOR_TASK_LIST_FOLDER}} and {{OPERATOR_TASK_LIST_SUBPATH}}
   • {{OPERATOR_REPORT_PATH_PATTERN}} = {{OPERATOR_BASE_PATH}}Daily/{YYYY-MM-DD}-daily.md
   • {{PROFILE_DAILY_PATH_PATTERN}}, {{PROFILE_DAILY_FOLDER}}, {{PROFILE_DAILY_PATH_FORMAT}}, {{PROFILE_DAILY_PATH_EXAMPLE}}, {{PROFILE_DAILY_SUBPATH_EXAMPLE}}
5. Sanity pass: scan the rendered output for any {{...}} strings. If any remain, fix or flag to the user before saving.

Show the user a short preview (title, cadence line, team scope, the rendered MCP block) and ask one yes/no: "Save it?"

---

Phase 3 — Save

If yes:

• Use the Write tool against the local filesystem.
• Path: {{OPERATOR_BASE_PATH}}operator-prompt.md resolved relative to the cwd (the vault root). Strip the leading / from {{OPERATOR_BASE_PATH}} when resolving locally.
• Read it back to confirm content present.

If the file already exists, ask before overwriting.

---

Phase 4 — Schedule it (do not stop at "saved")

After the prompt is saved, immediately invoke the schedule skill via the Skill tool. Do not stop at "saved". Do not tell the user to run /schedule create themselves — wire the trigger now.

Map cadence → cron

Convert {{CADENCE_HUMAN}} into a cron expression for the schedule skill:

Cadence	Cron
Hourly	0 * * * *
Every 4 hours	0 */4 * * *
Daily	0 9 * * * (9am local; ask if they want a different hour)
Custom	use what the user typed

Build the trigger payload

The schedule skill creates a remote trigger that runs Claude Code on a cron. Hand it:

• Cron expression — from the table above.
• Working directory — the cwd (the vault root). The Operator agent must run inside the vault so its file ops resolve correctly.
• Prompt — a short instruction: "Run the Operator. Read and execute @{{OPERATOR_BASE_PATH}}operator-prompt.md exactly as written. One run = one report. Stop when done."
• Trigger name — {{OPERATOR_HANDLE}}-{{CADENCE_TAG}} (e.g. Vault-Operator-hourly).
• Description — "{{OPERATOR_NAME}} — {{CADENCE_HUMAN}}".

Invoke the schedule skill

Call the Skill tool with skill: "schedule" and pass the args described above. Let the schedule skill do its own confirmation flow with the user (timezone, confirm cron, etc.) — it owns that interaction.

If the schedule skill is not installed in the user's environment, fall back to a clear text instruction with the exact cron expression and prompt to paste. Do not pretend the trigger is wired when it isn't.

After the schedule skill returns

Tell the user, in one short paragraph:

Operator prompt saved to {{OPERATOR_BASE_PATH}}operator-prompt.md and scheduled {{CADENCE_HUMAN}} (cron {cron}). First run will fire on the next tick. Manage the trigger anytime with /schedule list or /schedule update.

Stop. Do not propose other follow-ups.

---

Hard rules for this skill

• Discovery first. Read Context/ and CLAUDE.md before asking anything. Never ask for a value the vault already contains.
• Local-first for vault content. Use Glob, Read, and Write against the local filesystem for everything except connector probes. Vault MCP is only used at runtime by the rendered Operator agent, OR briefly during Phase 1 Q2 as a live probe to confirm the MCP is wired and authenticated.
• Probe, don't ask. For Q2 (connectors), inspect available tools in the session and run a read-only probe per connector. Never ask the user "do you have Slack?" — detect it.
• Always finish by scheduling. Phase 4 is mandatory. Save → invoke the schedule skill in the same run. Do not stop at "saved" and tell the user to schedule it themselves.
• Never modify CLAUDE.md. The Operator owns that file at runtime, not the builder.
• Never mv or rm a synced note, at build time or in the rendered prompt. Moves and renames go through move_note / move_folder, or they become a flagged task for a human. A shell move silently costs the note its doc_id, its history and its share settings.
• Never touch .context/, .git, or attachments/ in discovery, render, or the rendered Operator's own file sweeps.
• Strip disabled connectors fully. Vault + Fireflies only? Slack and Circle should not appear anywhere in the rendered prompt.
• One sanity pass for {{ after render. Catch unfilled placeholders before saving.
• Default to defaults. Don't pester for individual budget fields when the user picked "Defaults".