/marketing-os-setup

name: marketing-os-setup
description: "Set up a Marketing OS: a markdown second brain that becomes the single source of truth every marketing skill reads, plus the routines that keep it current and a control-center dashboard on top. Interview-driven and idempotent, safe to re-run. Builds seven knowledge folders (Context, Channels, Campaigns, Offers, Analytics, Team, Intelligence) plus Routines, writes the Context layer that ends skills carrying their own stale copies of the ICP and offer and voice, scaffolds one folder per publishing surface, then offers to set up the routines via marketing-os-routines and to build the control center via marketing-os-dashboard. Walks five pillars in order: connectors, Context, structure, routines, dashboard. Use when the user says 'set up a marketing OS', 'build my marketing second brain', 'marketing os setup', 'install the marketing OS', 'I want a marketing operating system', 'give my marketing skills real context', or runs /marketing-os-setup."
disable-model-invocation: true

Marketing OS Setup

Build the user a Marketing OS. Not a folder of templates, a working operating layer: the intelligence in `Context/`, the routines that keep it current, and a dashboard that answers "what do I do today."

State the problem once

Every skill that carries its own copy of the ICP, the offer and the voice means updating one leaves the rest stale. This OS makes `Context/` authoritative so every skill inherits a change instead of drifting.

Say that in a sentence and move on. Do not pitch it further, and do not go looking for evidence: if the user wants their own duplication counted, they will ask.

The five pillars, in this order

Order matters. Do not skip ahead, and do not build the dashboard before there is data.

| Pillar | What happens | Reference | | --- | --- | --- | | 1. Connectors | Probe what is actually authenticated. Never present a checklist | `references/connectors.md` | | 2. Context | Interview and write the constitution. **The highest-value step** | `references/interview.md`, `references/context-templates.md` | | 3. Structure | Scaffold seven knowledge folders plus `Routines/`, and every folder index | `references/structure.md`, `references/folder-indexes.md` | | 4. Routines | Offer to set them up | `marketing-os-routines` owns the templates and the scheduling | | 5. Dashboard | Write the spec, then offer to build it | `marketing-os-dashboard` owns the build |

Read `references/conventions.md` before writing a single file. It carries the invariants, and breaking one means the result is not this OS.

Three rules that come before everything else

Stay inside the OS root

**Read and write only inside the OS root the user gave you.** Nothing else on the machine is in scope.

Do not list, glob, grep or read outside that root. Do not go looking for their other vaults, their skill folders, their home directory, or an example OS shipped with a plugin. **Do not start an exploration nobody asked for.** If you think something outside the root would help, name the one path you want and ask for it. Wait for a yes.

The only exceptions are the ones the user hands you: a path they name, a public property of theirs they point at, and the connectors they have authenticated.

Start from zero

**Run this as though you know nothing about the user or their business, because anything you appear to know, you guessed.**

Your context may hold a person's name, an email, a system username, a folder path, a git config, a connected account, or a company name. None of it was given to you for this. Treat all of it as absent: never echo it, never address the user by it, never put it inside a question, never pre-fill a field with it, and never ask them to confirm it.

**Naming it is worse than asking, not safer.** "I have you as Dana at Acme, confirm?" announces the guess and makes the user correct you about themselves. Both of these are the same failure:

| Wrong | Right | | --- | --- | | "Point me at your real Acme material" | "Point me at the material you want me to read" | | "I have you as Dana, dana@acme.co. Confirm?" | Do not raise it at all | | "Confirm your org name and timezone (Acme, GMT-3)" | "What is the business called, and what timezone should the routines run in?" |

**You are allowed to ask about the business.** What it is called, what it sells, who it serves, who this is being set up for, what timezone the routines run in. All of that is necessary and none of it is a guess. Ask open, and let them fill it.

The line: **the business is the subject and you learn it by asking. The person at the keyboard is not the subject at all.** `operator_name` and `operator_email` are optional keys that stay empty unless volunteered unprompted, and nothing downstream reads either one.

Everything in this OS comes from this user's own business

Other operating systems may sit on this machine: one belonging to whoever built this skill, a reference implementation, another company's vault. **None of that is a source, and none of it is yours to go find.**

An OS seeded from another business reads as finished, so nobody goes back to check it, and the user ends up publishing somebody else's strategy in their own name.

Before you read any file to populate this OS, it must pass all three:

1. The user named it, or it sits inside the OS root, or it is a public property the user owns. 2. It is about **their** business, not a template with real data left in it. 3. You can put it in a `source:` frontmatter field and the user would recognise it as theirs.

If something looks useful but fails one of those, **name it and ask** before reading a line of it. Discovering a vault is not the same as being handed one. When in doubt, interview: a thin file built from honest answers is the correct output, and a borrowed answer is a species of invention.

The same holds for the dashboard shell and the routine files this skill ships. They are deliberately business-agnostic. If