Marketing Os Setup

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.

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:

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 you find a real company name, handle, price, metric or quote in either, that is a bug in the asset. Strip it, do not propagate it.

Before you start

Confirm the root. Offer concrete paths rather than asking an open question: alongside an existing second brain of theirs, nested inside it as a subfolder, a fresh folder in their documents, or a path they name. If they already have a second brain, prefer nesting over creating a rival root.

Offer options at every decision point. Where the interview asks the user to choose rather than to describe (which channels, which surfaces originate, solo or team, which offers form the ladder), put five to ten concrete candidates on the table and let them pick or correct. Reserve open questions for the things only they can supply: the enemy, the verbatim pain language, the binding constraint.

Confirm the primary channel. Exactly one publishing surface is role: primary-original and everything else repurposes from it. If they cannot name one, that is a strategy problem worth surfacing now rather than modelling around.

Idempotent. Safe to re-run. Never overwrite an authored Context/ file without asking. Re-running should fill gaps, not reset work.

Pillar 1: connectors

Probe, do not ask. Attempt a real call against each and record what actually works.

The OS degrades gracefully by design, so a missing connector is a documented limitation rather than a blocker. Write the result into Context/infrastructure.md with the degradation table from references/connectors.md, so every routine knows what it loses.

Do not stall setup waiting for authentication. Note the gaps and continue.

Pillar 2: Context, the one that matters

Use the exact paths in references/context-templates.md. They are not arbitrary: vault-aware skills resolve context by literal path, so a rename means those skills stop finding their context, which defeats the entire purpose.

One file per ICP segment, with its pain points inside it. Pain points are properties of a segment, not a category of their own, so there is no pain-points.md and no pain-points/ folder. If they name three buyer types, that is three files. If they cannot name one clearly, stop and fix that before writing anything else, because a vague ICP produces vague content forever.

Two rules while interviewing:

• Write what they say, not what sounds good. A vague ICP produces vague content forever. Push for specifics: who they are not, what they say verbatim, which pain they lead with.
• config.md is the only file a new operator rewrites end to end. Every instance literal a routine needs is a key there. If you later find a routine needing a value that is not in config.md, that is a bug in the routine, not a gap in the interview.

Pillar 3: structure

Scaffold from references/structure.md. Seven knowledge folders plus Routines/, each with its own CLAUDE.md from references/folder-indexes.md.

Root holds CLAUDE.md and folders. Nothing else. The exclusions are enumerated in references/structure.md, which is also the copy that ships into the OS as its own contract.

Apply the design test to every folder before you create it: it is either permanent context or a named routine writes to it. Never scaffold a folder they will not fill, because an empty folder with no routine teaches the operator that this OS is full of things to ignore.

Channels/ is the one genuinely per-business part. Ask which surfaces they actively produce for and scaffold only those, with strategy.md, voice.md, and pipeline/ plus published/. An email channel takes flows/ and broadcasts/ instead, because a trigger is what defines an email. Exactly one channel is role: primary-original.

Two questions that decide the shape:

• Solo or a team? Solo skips Team/ entirely. Ask, do not assume.
• Do they produce for their website? A blog or SEO makes the website a channel. Otherwise its pages belong to the offers they sell, as Offers/<offer>/landing.md.

Seed files, beyond Context and the folder indexes

Easy to miss, and the routines read or write every one of them. Create all of these:

Do not create Analytics/dashboard/control-center.html. That file belongs to marketing-os-dashboard.

Verify the install by resolving paths. Grep the routine files for backtick-quoted paths, substitute <primary_channel> from Context/config.md, and confirm each one either exists or is a declared write target of a routine. Anything left is a missing seed file.

Pillar 4: routines

You do not author or schedule the routines. marketing-os-routines owns them end to end, and it ships the ten templates, so there is one copy of each and one place a routine can be written.

Your job is one thing: ask whether they want the routines now.

The OS is built. Want me to set up the routines that keep it current, or leave that for later?

• Now → invoke marketing-os-routines via the Skill tool. It reads the OS you just built, proposes the set that fits it, writes the files, and creates the scheduled tasks. Do not install files yourself, do not substitute placeholders, and do not duplicate its connector probe.
• Later → say so plainly and give them the one command: /marketing-os-routines.

Recommend "now." An OS with no routines goes stale immediately and the whole design test rests on something writing to each folder. This is the one handoff worth pushing.

Tell it what you learned in the interview so it does not re-ask: the primary channel, the other channels, the timezone, which connectors came back live in Pillar 1, and whether Team/ exists.

Pillar 5: dashboard

You do not build the dashboard. marketing-os-dashboard owns it end to end, and it ships the shell, so there is exactly one copy of a 160KB file and one place the first build can happen.

Your job here is two things:

1. Write Analytics/dashboard/spec.md as the contract, with what you learned in the interview: which channels exist, which one originates, how many offers, solo or team, whether anything is time-boxed right now. The dashboard skill reads it so it does not have to re-ask.
2. Ask whether they want the dashboard now.

The OS is built. Want me to build the control center dashboard on top of it now, or leave that for when there is data in it?

• Now → invoke marketing-os-dashboard via the Skill tool. It runs its own first-build interview, renders all eleven pages, verifies, and asks before deploying anywhere. Let it do all of that: do not pre-empt its interview and do not copy a shell yourself.
• Later → stop at spec.md and give them the one command: /marketing-os-dashboard.

Recommend "later" when no analytics pull has produced real data yet, which on a fresh setup is always. Say why in one line: against an empty OS the page is placeholders, and a dashboard that opens empty on day one teaches the operator to ignore it. Better to schedule the sweep, let it run once, then build.

If they want it anyway, that is a fine choice and the dashboard skill has a seed mode for exactly this: a standing warning that no routine has run, and every empty panel naming the routine that will fill it. Hand off and let it handle that.

The rule that protects the whole thing

Empty is honest.

Do not fill Analytics/what-works.md with plausible marketing advice. Do not invent a metric to complete a table. Do not write a customer quote nobody said.

Every content skill reads what-works.md before drafting and cannot tell a placeholder from a finding. One invented pattern there degrades every future draft. An empty file that names the routine which will fill it is the correct output.

The same applies to numbers. A gap says "not pulled" with the date. A carried-over value says it was carried and when it was really measured.

Before you report, audit the OS for foreign content

One grep, and it catches the worst failure mode this skill has.

Search the finished OS for any company name, person, handle, domain, price or platform account that is not the user's. Start with the org name and operator name from Context/config.md: every proper noun in the OS should either be one of theirs, a tool they use, a competitor they named, or a customer they quoted with a source.

Anything else came from a template or from another business's records. Remove it and say so. A single leftover handle in a routine will end up in a live scheduled task and pull somebody else's numbers into their dashboard.

Then grep Routines/ for <. A placeholder left unsubstituted is the same class of bug.

What to tell the user at the end

1. What was created, by folder.
2. Which connectors are live and which routines are degraded as a result.
3. The three next actions, in order: authenticate the remaining connectors, run the morning performance sweep once by hand for a real baseline, then register routines one at a time as their connectors come online.
4. That the data layers are deliberately empty and roughly a month of runs is what makes the OS useful. The context layer is already useful today.

Do not oversell it. The honest framing is that the infrastructure is built once and the intelligence compounds from here.

Self-improvement

This skill is never finished. Improve it as you use it.

• When the user corrects how a pillar was run, update the relevant reference file (references/connectors.md, references/interview.md, references/context-templates.md, references/structure.md, references/folder-indexes.md, references/channel-templates.md, references/conventions.md) so the correction sticks. Do not just fix it for this run.
• When a correction is a hard rule ("always X", "never Y"), add it as a permanent rule here.
• When an interview answer reveals a business shape the tree does not cover, add a row to the adaptation table in references/structure.md rather than improvising the same fix next time.
• When a routine needs a value that is not a key in Context/config.md, that is a bug in the routine. Report it to marketing-os-routines rather than hardcoding the value.
• When the user says a built OS was genuinely good, save its Context/config.md shape and folder tree to references/examples/ as a model for future runs.
• Keep the skill small: when you add something, run the deletion test and cut anything that no longer changes behavior.