Operator-stack series · Repo 1 of 3

A content-generation Claude worker, ICM-structured, fork-ready.

Dispatched a brief, produces prose in a configurable voice. Three Markdown files declare the architecture; one file holds the voice you write in. MIT licensed.

View on GitHub Five-minute setup

What it is

Accepts a brief. Produces prose in your configured voice.

A working Claude worker that does one thing. You give it a brief, it reads the voice configuration you've defined in reference/voice.md, and it produces prose matching those rules. Fork the repo, edit one markdown file, drop a brief in briefs/, dispatch with one prompt.

Brief-driven

Every dispatch starts with a six-section brief at briefs/<date>-<slug>.md. The brief is the contract. The worker reads it, produces, verifies against its own success criteria, hands back.

Voice-configurable

The voice lives in reference/voice.md. Three or four paragraphs of your rules — tone, rhythm, vocabulary, what you sound like, what you don't. Edit once; the worker reads it every dispatch.

Dispatch-ready

The orchestrator-worker boundary is enforced in the architecture, not the prompts. The worker doesn't pick its own work. The brief is the only context. No speculative loading. No scope extension.

A dispatch trigger looks like this# In a fresh Claude session, after opening the repo folder: > Read the brief at briefs/2026-05-14-focusblock-launch.md and execute. # That's the entire dispatch. The worker handles the rest: # 1. Reads STATUS.md (first read) # 2. Reads the brief (the contract) # 3. Reads reference/voice.md (how to sound) # 4. Runs the pre-flight checklist (5 items, grep-able) # 5. Produces the artifact # 6. Self-verifies against the brief's success criteria # 7. Updates STATUS.md (last write)

Why this one

Five architectural choices this starter enforces.

There are other Claude-worker starter kits. The differentiators below are the reasons this one exists. Each is enforced by the architecture, not by a README that hopes you'll remember.

  1. ICM rigor

    The three always-relevant files — CLAUDE.md, CONTEXT.md, STATUS.md — plus identity, rules, examples, and reference. Not "a CLAUDE.md and hope." Structural, named, enforced.

  2. 60-30-10 layer separation

    Infrastructure / Orchestration / AI, in the corrected definition. AI is the 10%; the other 90% lives in scripts, files, and declarative rules outside Claude. Most kits make Claude the whole stack. This one keeps it in its lane.

  3. Brief-as-contract dispatch

    Clean role boundary between orchestrator and worker. The worker is meant to be called, not driven free-form. The brief is durable, audit-trail-friendly, and complete-or-refused — no "I'll do my best with what's missing."

  4. Pages-ready landing

    The repo IS its own marketing surface. Push it, enable GitHub Pages from the /docs folder, and a public URL goes live in sixty seconds. The page you're reading now is that file.

  5. Tied to a real article series

    The architecture is documented in the operator-AI series, starting with "I burned 800,000 tokens on one daily routine." Read the article, then the code. The two reinforce each other.

Sample output

One brief, one post.

The repo ships with one worked example. A six-section brief asks for a 600-800 word product-launch post for a focus-timer app called FocusBlock. The worker reads the brief, reads the default voice configuration, and produces the post. Both the brief and the full output are in the repo.

Excerpt from the produced post

Brief: briefs/2026-05-14-example.md · Output: examples.md · Voice: default

Most productivity apps optimize for willpower. FocusBlock optimizes for scheduling.

FocusBlock is generally available today. It is a focus-timer and a deep-work scheduler, available on macOS, Windows, and Linux. The thing it does differently is small, and it took us longer than we wanted to admit before we built it: it puts the focus session on your calendar, not on you.

Most apps that promise to help you focus operate on willpower. They nag. They gamify streaks. They lock you out of sites you visit when you're tired. The model is: you are weak at 2pm, and the app is the muscle.

This works for about three weeks. Then the streak breaks, the nag becomes background noise, the lockout gets disabled at the first urgent ping. The user goes back to whatever they were doing before. The conclusion most apps draw is that the user needed more discipline. The conclusion we drew is that willpower was the wrong layer.

Full 650-word output, including all three section headings and the worker's self-verification table, is in examples.md.

In production

Real-user receipts.

This repo is a fresh release. Real-user receipts go in the block below once operators who fork it ship work with it.

Receipts pending.

Forked this repo and shipped real work with it? Open an issue with a one-paragraph note on what you built and how the dispatch shape held up. Selected receipts will be quoted here verbatim, with consent.

Get started

Five minutes from fork to first dispatch.

  1. Fork the repo

    Click Fork on the GitHub page, or clone directly: git clone https://github.com/NFTYoginis/your-content-worker.git

  2. Open the folder in a Claude session

    Either Claude Code in the terminal, or a Claude Project with the folder uploaded. The worker reads CLAUDE.md as its entry point.

  3. Edit reference/voice.md

    The repo ships with a working default voice so the example dispatches as-is. Replace the default with your own voice rules — tone, rhythm, vocabulary, what you sound like, what you don't. Three or four paragraphs.

  4. Write your first brief

    Copy briefs/_BRIEF-TEMPLATE.md to briefs/<today>-<slug>.md. Fill the six sections. Keep it on one screen.

  5. Dispatch

    Paste this into the Claude session: Read the brief at briefs/<your-filename>.md and execute. The worker takes it from there.

Questions

What you'll want to know.

Do I need Claude Code, or does this work in a Claude Project?

Both work. The worker's contract is in Markdown files; any Claude session that can read and write files in the repo folder is sufficient. Claude Code in the terminal is the smoothest experience because the worker can write its own STATUS.md updates and question files directly. A Claude Project works too — you'll just need to paste status updates back yourself.

What's the difference between this and other ICM starter kits?

Three things, in order of importance. First, the architecture enforces the orchestrator-worker boundary — most kits collapse both roles into one session and burn tokens accordingly. Second, the 60-30-10 layer framework is restated correctly (Infrastructure / Orchestration / AI), not as a context-budget split. Third, every repo ships with a Pages-ready landing page; push to GitHub, enable Pages from /docs, public URL in sixty seconds.

Why is the voice file separate from the worker code?

Because voice is the configurable part. The worker's job — read brief, read voice, produce prose — doesn't change when your brand voice changes. Keeping the voice in reference/voice.md means you can fork once and re-skin the worker for different brands, different audiences, or different campaigns without touching anything in rules.md or identity.md.

What does the worker refuse to do?

Five named refusal gates in rules.md, each with verbatim refusal language. The big ones: empty voice configuration, missing brief preconditions, claims the brief doesn't ground, high-harm domains without explicit authorization, and impersonation of named third parties without consent confirmation. When a gate fires, the worker writes a question file at briefs/questions/<slug>-question.md and stops. It does not "do its best."

Why six sections in the brief? Why not free-form?

The six sections are: what to produce, audience, format and constraints, voice override or default, success criteria, refusal context. Free-form briefs put the worker in the position of guessing what the operator meant. Guessing is the most expensive bug in this kind of architecture — it produces output that's plausibly close to what was wanted but materially wrong. Six sections is the smallest contract that closes the guessing space.

Can I add more worker types to the same repo?

You can. The cleaner pattern is one worker per repo, because each worker has different reference material and different refusal gates. The operator-stack series follows this: your-content-worker for prose, your-design-worker for visual assets, your-animation-worker for voice-to-video. Same architecture, three repos. One orchestrator dispatches to all three.

What if the worker starts narrating its own thinking?

That's the orchestrator-worker boundary leaking. The worker's job is to produce the artifact and update STATUS, not to monologue. If you see narration, the brief is probably under-specified — the worker is filling the gap with prose about what it might do, instead of producing what was asked for. Tighten the brief; re-read rules.md with the worker.

Is this affiliated with Anthropic or Claude?

No. This is an independent project demonstrating one way to structure a Claude-based content worker. Claude is the model the worker runs on; the architecture and the opinions are this repo's.

The series

One of three.

This repo is the first in a three-repo operator-stack series, each demonstrating the same architecture in a different domain.

your-content-worker — this one. Brief in, prose out.

your-design-worker — coming next. Brief in, images and HTML previews out.

your-animation-worker — after that. Brief in, voice-to-video MP4 out, via Remotion.

The architecture is documented in Article 1 of the operator-AI series: I burned 800,000 tokens on one daily routine. Here's the architecture that killed it. Read the article for the receipts and the four mistakes that produced the number; read this repo for the code that runs the fix.