Marketing Os Newsletter

Marketing OS Newsletter

Write one edition, in the operator's voice, from what the OS already knows. Then put it back in the OS.

This skill carries no context of its own. No ICP file, no offer summary, no voice guide, no example folder. Every one of those exists once in the OS and this skill reads it there. That is the whole point: the original newsletter skill shipped ten reference files and six of them were copies that went stale the moment the business changed. A price baked into a skill is wrong within days.

Run from the OS root. Stay inside that root. Read and write only within it, and do not go looking for other vaults on the machine. Start from zero on identity. Every name, handle, price and number comes from the OS or from the user in this conversation, never from your context, the system username or the folder name. If the OS does not name it, you do not know it.

First, check the OS is there

The read map

Read these before drafting, and read them from the OS every run. Full contract in references/os-contract.md.

Precedence when they disagree. The real sends in broadcasts/ beat the structure framework, which beats the swipe file, which beats the voice register. A living example outranks a rule written about it.

Read only what the edition needs. A repurpose of a published video does not need the background file. Do not load the whole OS.

The four properties this skill exists to hold

Every gate below is one of these. They are the reason a gated process beats a one-shot draft, and cutting any of them collapses the quality.

1. The insight comes from the operator, not from you. If you generate the substance, the edition is generic and anyone could send it. You supply structure, options and craft.
2. Human in the loop, one gate at a time. Never write the edition before the gates are cleared.
3. Options at every gate. Three to five real choices beat one draft to correct. Correcting is slow, choosing is fast.
4. Ground it in real examples. The broadcasts/ folder is the ground truth and it grows every time this skill runs.

Before Gate 0: fan out to load the OS

Launch these readers in one batch, before you ask the operator anything. Reading the OS serially, or skimming three files and starting the gates, is what produces generic options at Gate 0 and a draft that could have come from any skill. The gates are only as good as what is behind them.

Plus, once a source is chosen, a sixth agent that reads the source itself end to end: the published asset in full including its performance block and repurpose tree, or the values doc, or the community thread.

Each agent returns findings, not a summary of its reading. Its final text is its return value.

Do not start the gates until every reader has returned. An option built on a file nobody read is the failure this step prevents.

The effort floor

Floors, not targets. A run that skimmed two files and wrote a competent-sounding draft has failed.

If a floor cannot be met, say which and why before the gates start. "The broadcasts folder holds two sends so the style ground truth is thin" is honest and useful. Quietly proceeding on two is not.

The gates

Seven, in order. Each one presents options, then stops. Full prompts and option shapes in references/gates.md.

Never skip a gate to save time. The process is the product. A 20 minute gated run produces an edition worth sending; a one-shot draft produces something that reads like every other AI newsletter and gets deleted.

If the user says "just write it", write it, and say once which gates you assumed. Their call, not yours. Do not argue twice.

Gate 0 sources

Offer these, in this order, and lead with whichever the OS is richest in:

1. A published pillar asset. Channels/youtube/published/*.md. The OS names the only original channel in Channels/{primary}/strategy.md and everything else repurposes from it, so this is the default. Read the asset, its angle, its performance block and its repurpose tree, and check whether the newsletter child already exists before proposing one.
2. The values and beliefs doc. Deep questions answered out loud, one a day. This is the source that keeps editions non-generic because nothing in it is researchable. If the OS has no home for it yet, say so: it belongs in Context/personal-brand/ per the OS routing table, and this skill cannot invent it.
3. A community post, a member win, or a customer quote. Route through Intelligence/research/voice-of-customer.md for anything verbatim.
4. A raw idea the operator brings.

For a campaign send, read Campaigns/{campaign}/brief.md and carry campaign: into the frontmatter. The send still lives in Channels/newsletter/broadcasts/, never inside the campaign folder.

Writing rules

Never write a price. Read it from Offers/{offer}/offer.md, which holds the live table with effective dates. Context/config.md also carries one and the two can disagree. When they do: use the offer file, tell the user which key in config is stale, and offer to fix config, because a price that exists in two versions is a bug against the OS contract and not something to work around silently. Never carry a price forward from an old send in broadcasts/.

Never write a metric you did not read. Subscriber counts, member counts, review counts and revenue figures all move. Pull from Analytics/metrics.md with its pulled date, and if the row says not available, say not available. A number without a date and a source does not go in the edition.

Never invent proof. A member name, a result, a testimonial or a quote comes from Offers/{offer}/proof/ or Intelligence/research/voice-of-customer.md, verbatim, with its source. If the folder is empty, the edition ships without proof. An invented testimonial is the worst failure available here because it will be read as real and then repeated.

Never use em dashes. Periods, commas, colons, or restructure the sentence. Same for the rest of the generic-AI tells listed in the voice register.

One story, one lesson, one call to action. Length and mechanics come from Channels/newsletter/strategy.md and the real sends, not from a number in this file.

Read Analytics/what-works.md before Gate 3 and honour what it licenses. It separates findings from untested beliefs on purpose. Do not quote an open question as though it were measured, and do not lean an edition on a pattern the file says the numbers contradict.

On approval, write it into the OS

This is the half the original skill did not do. Nothing here is optional.

1. File the edition. Channels/newsletter/broadcasts/YYYY-MM-DD-<slug>.md. Frontmatter and body shape in references/os-contract.md. It carries type, date, channel, status, stage, source, pain, two or more specific tags, and campaign when it belongs to one. Entity names are wikilinks woven into sentences, never a bullet list of references.
2. Append the shipped subject line to Intelligence/research/swipe/subject-lines.md with its date. The swipe file is how the next run gets better, and it only grows if this step happens.
3. Update the parent. If the source was a published pillar, add this edition to that asset's ## Repurpose tree as a wikilink. A cascade nobody records looks like a cascade that never ran.
4. Log it. Intelligence/logs/YYYY-MM-DD.md, naming the file written and the specific change. This is a hybrid: it produces a deliverable and it changes what the OS knows, so it logs the knowledge change only.

Never ask permission to save. Write to the right file and report what was saved.

Sending is not your job. You file the edition. Pushing it to the email platform is a separate step the operator or a routine does, and this skill never sends.

If something you expect is missing

A missing file is a finding, not a failure. The OS may be young or mid-edit and a run must still complete.

Create only the files this skill owns: the broadcast, the swipe append, the parent's tree line, the log.

Then render the one-pager. Always

Every run closes by rendering an HTML page. Not "if asked".

This is the plugin's convention and it is the reason instant-ui sits in this plugin at all. The filed broadcast is the machine artifact: the carousel skill reads it, the routines read it, and it stays markdown because markdown is what the OS stores. Nobody should have to read raw markdown to review an edition before it sends.

Invoke the instant-ui skill with the edition and this output path:

Analytics/dashboard/runs/YYYY-MM-DD-newsletter-<slug>.html

That is the same folder every routine writes its run report into. Create the folder if it does not exist.

The page carries the subject line and preview text, the edition body laid out as it will read, the gate decisions in one compact block, the offer facts used with their sources, and the paths written. Set the edition body in the reading width the register implies, because the point of the page is to judge whether it reads well, and a full-bleed wall of text cannot be judged.

Never build the page yourself and never hardcode a colour. instant-ui owns the design language and its tokens trace to Context/brand/brand-kit.md.

Record the page path in the broadcast file.

The run is not complete until the page exists. If instant-ui is unavailable, say so plainly, note it in the log line, and never hand-roll a page.

Self-improvement

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

• When the user corrects how a gate ran, update references/gates.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 to the writing rules above.
• When an edition lands well, the example belongs in the OS, not in this skill. It is already in broadcasts/. If it is a genuine model, note why in Intelligence/research/swipe/. Never start a local examples folder here, because that is how the duplication this skill removed comes back.
• When a read path in the map turns out wrong, fix the map and references/os-contract.md together.
• Keep the skill small: when you add something, run the deletion test and cut anything that no longer changes behaviour.

Files