/marketing-os-routines

name: marketing-os-routines
description: "Create and manage the Marketing OS routines as scheduled tasks: ten of them in two groups: five operating routines (morning performance sweep, content pipeline sync, campaign sync, dashboard, monthly report) and five intelligence and review routines (market scan, customer intel, competitor radar, pipeline hygiene, quarterly report). Probes every connector first and reports exactly what each routine loses without it, so nothing gets scheduled against a dead integration. Gives the operator the schedule, the connector list, and the prompt to paste for each. Every routine is independent and none depends on another having run. Use when the user says 'register my marketing routines', 'schedule the marketing OS routines', 'set up marketing automation', 'which routines should I turn on', 'my routines are not running', 'marketing os routines', or runs /marketing-os-routines."
disable-model-invocation: true

Marketing OS Routines

Register the routines that keep a Marketing OS current, and audit the ones already running.

> [!important] A routine is a scheduled task > The two words mean the same thing here. `Routines/` holds ten prompt files; a routine only *runs* once there is a scheduled task firing it. Creating that task is this skill's whole job.

**This skill owns routines end to end**: the ten templates in `assets/`, authoring them into the OS, and creating the scheduled tasks. `marketing-os-setup` invokes it and never does any of that itself. Works either way: invoked from setup, or run on its own against an OS that already exists.

Run from the OS root, then branch on what is there:

| State | Do | | --- | --- | | No `Context/config.md` | The OS is not set up. Point the user at `marketing-os-setup` and stop | | `config.md` but no `Routines/` | **Fresh build.** Read the OS, propose a fitted set, write the files, then schedule | | `Routines/` exists, nothing scheduled | Skip authoring. Go to the connector probe and schedule what is there | | Routines already scheduled | **Audit mode** |

Never refuse to run because `Routines/` is missing. Writing it is the job.

**Stay inside that root.** Read and write only within it. Do not list, glob or read elsewhere on the machine, and do not go looking for other vaults or example OS folders. If something outside the root would help, name the one path and ask. **Start from zero on identity.** Every name, org and handle comes from `Context/config.md` or from the user in this conversation. Never from your context, the system username, the cwd folder name, a git config, or a connected account, and never echoed back as "confirm this?". If `config.md` does not name it, you do not know it: say the key is empty rather than filling it.

Two modes, detect which

**Install mode.** Nothing scheduled yet. Read the OS, propose the set, author the files, probe connectors, create the scheduled tasks, report what is degraded.

**Audit mode.** Routines already scheduled. Check whether they actually ran, and whether they wrote anything.

Detect by listing existing scheduled tasks whose names begin with the `routine_prefix` in `Context/config.md`, defaulting to `marketingos-`.

Install mode

1. Read the OS, then propose the set

**Never install ten files sight unseen.** The ten templates are a strong default, not a fixed set, and a routine writing to a folder this OS does not have is a routine that logs `not available` forever.

Read first, and read only what you need:

1. **The tree.** Which of the seven knowledge folders exist, and what is actually in each. 2. **`Context/config.md`.** The primary channel, the other channels, the timezone, the thresholds, the connector map. 3. **`Context/infrastructure.md`.** Which connectors are authenticated and what each gap costs. 4. **`Routines/CLAUDE.md`** if it exists, so you do not propose something already there.

Then **propose a set and let the user pick.** Put all ten templates from `assets/` on the table with a verdict each, plus anything this OS specifically needs that the ten do not cover:

| Verdict | When | | --- | --- | | **Write and schedule** | Its write target exists and at least one connector it needs is live | | **Write, schedule later** | Its target exists but its connectors are dead. The file is still worth having | | **Skip** | Nothing in this OS for it to write. Say which folder is missing | | **Propose new** | This OS has a surface or a folder the ten do not serve. Name it and say what it would write |

Show that as one list. **All ten get a verdict, which puts five to ten real options in front of the user in a single pass**, and that is what makes this fast rather than a questionnaire. Recommend a default, then wait. Never advance on a single suggestion.

**A "propose new" routine follows the same contract as the ten.** Read the rules for writing one in `assets/_register.md` before authoring it: independent, degrades, no instance literals, states its boundary, logs if it is brain-update. Model it on the closest of the ten rather than inventing a shape.

Then write the chosen files into `Routines/` flat, plus `_register.md` as `Routines/CLAUDE.md`, and **substitute every placeholder** from what you read in step 1. The `<angle bracket>` markers and their sources are mapped in `assets/_register.md`.

> **Then grep `Routines/` for `<`. A placeholder left unsubstituted ends up in a live scheduled task and nobody notices.**

2. Author the chosen files

Write them into `Routines/` flat, plus `_register.md` as `Routines/CLAUDE.md`.

Every routine file keeps its own `schedule:` and `category:` frontmatter and its **Set it up** block, then a divider. **Everything below that divider is the routine's prompt**, and the scheduled task points at the file rather than inlining it, so an edit takes effect on the next run.

Skip this step entirely when `Routines/` already holds the files.

3. Probe the connectors

One cheap read per connector, never a write.