A marketing operating system, but it's not an app.

Build started April 2026 · Phase 1 (Core 5) complete · Chicago

Most marketing tools assume you want a dashboard. I don't. I want a workbench. Content Desk is a marketing operating system implemented as Claude Code slash commands. Five skills that move from story elicitation to publish, with a voice gate and a HIL gate at every step. Not a SaaS, not a CMS. Five commands typed into a terminal, each producing both content AND system training. The dual output is the point.

The problem

I write across six pillars (Build in Public, Seven Skill Proof, K-Shaped Market, Ops Veteran + AI, Tools + Frameworks, Client Work) for nine platforms (Substack, LinkedIn, X, Bluesky, Threads, Instagram, TikTok, Substack Notes, the publication site). Each platform has different format constraints. Each pillar has different positioning. Each piece needs to reinforce a 20-year throughline without sounding self-aware about it. None of it can sound like AI wrote it, even though most of it is drafted with AI assistance.

The naïve solution is a content calendar app. Calendar tells you what to write; it doesn't tell you whether the draft sounds like you. I don't need a calendar. I need a quality bar that runs before anything ships, and a system that gets smarter every time I publish.

The other failure mode is "use a generic LLM to draft everything." That produces volume, not voice. Voice is the only thing readers actually retain. A piece that sounds like everyone else's piece is a piece nobody remembers tomorrow, even if it ships on time, even if the calendar is full.

The design constraints

1. Story First, Strategy Second. Every entry point starts with a moment, not a thesis. My mind works through narrative. The system has to meet me there. Asking me "what's your strategic angle for this piece?" produces nothing. Asking me "tell me about a time when..." produces material.
2. The Pattern Is the Positioning. Every output must reinforce a single 20-year throughline: systems-builder-at-intersections. Know what story is already being told before claiming a new one. The piece that drifts from the pattern doesn't get published. It gets reworked.
3. Serve First, Publish Second. Voice gate + HIL gate before anything goes anywhere. I remain sovereign over every output. The system can draft; only I can publish. This is not a constraint to relax later. It is the brand.
4. Dual output. Every session produces (1) content AND (2) system training. A Founder's Desk piece about Career Desk is a piece for HumanOperators readers AND a bullet candidate for Career Desk resumes AND a story enriched in Open Brain for the next piece to draw on. If a session only produces content, the system isn't working.

The architecture

This is the part that makes Content Desk different from other "AI content systems." There is no app. There is no CMS. There is no dashboard. The architecture is:

• Five Claude Code slash commands at ~/.claude/skills/desk-*/SKILL.md
• Reference markdown files at ~/Documents/Claude/desk-assets/: the voice guidelines, content standard, writing companion, brand alignment, design system
• Open Brain (Supabase + pgvector + MCP): the qualitative memory layer, shared with Career Desk
• Content Desk wiki at ~/.desk/wiki/: every published piece archived with full tag set
• Career Desk bullet library at ~/.gstack/career-os/wiki/bullets/: receives achievement evidence flagged by /desk-archive

That's the entire system. No web UI. No database app. No scheduling tool. The interface is a terminal prompt. That's the right interface for craft work, the same way a writer's interface is a blank page and an editor's interface is a red pen.

The five skills

The Core 5, Phase 1, complete. They run the full Know → Position → Create → Voice-Check → Proof → Publish → Learn loop:

The five voice signatures

These aren't style suggestions. They're explicit moves the writer can deploy to make a piece land. Every piece picks at least one. The voice gate checks whether the chosen signature is actually doing work in the draft.

How a piece gets made

This is the meta loop in motion. A real example, end to end:

1. Trigger. I open a Claude Code session and type "I want to write about the Apify migration in Career Desk."
2. /desk-story activates. Coach Me asks: "Tell me about the moment you realized Apify wasn't going to work." I tell the story: the Cloudflare 403s, the version-build cache hell, the 6-hour ripout. It probes for specificity. It queries Open Brain for related Career Desk captures. It surfaces a related thought from three weeks ago about residential IPs being "the only honest signal."
3. /desk-write generates the draft. Platform: Founder's Desk on humanoperators.ai. Structure: scene (the moment of failure) → connection (residential IP as honest signal) → pivot (when to leave a tool) → insight (cost of cloud bot mitigation) → forward close.
4. /desk-voice runs the gate. Scores 11/15. Revise. Flags two issues: opening is too thesis-first, and one paragraph contains a banned phrase ("at the end of the day"). I revise. Re-scores 14/15. Ready.
5. /desk-publish posts. Canonical order: Substack first, then LinkedIn (with the Founder's Desk dispatch framing), then X (carousel cascade). Each platform action confirms before posting.
6. /desk-archive closes the loop. The piece archives to Content Desk wiki tagged P1 Build in Public · Founder's Desk · Signature 5 (Builder's Honesty) · Career Desk. Open Brain enriched with a new capture: "residential IP as honest signal." Career Desk bullet library gets a candidate flag. The Apify-to-local migration is achievement evidence for "led architecture migration that recovered scraper reliability from ~30% to ~95%."

One session. Two outputs. The piece for readers, the bullet for the next resume, the story enriched for the next piece. That's the dual output principle in motion.

Integration map

Content Desk doesn't run in isolation. It's wired into the rest of the ecosystem:

Tool surfaces: same backend, multiple front doors

The CLI is the primary interface, but not the only one. Slash commands work when I'm in a Claude Code session writing or planning. They don't work as well when I'm visually scanning what's drafted, what's in queue for which platform, or which pieces are blocked on the voice gate. So Content Desk has two GUI surfaces, both wired to the same skill backend:

Both surfaces read from and write to the same Content Desk wiki, the same publishing timeline, the same Open Brain captures. The slash commands are the lower-friction interface for solo terminal work. The browser surfaces are the lower-friction interface for visual review and queue management. Pick the front door that matches the work you're doing.

Phase 2 + Phase 3 (coming)

Phase 1 (Core 5) is the create-and-publish loop. Phase 2 adds the intelligence layer: research and positioning skills that run before /desk-story:

• /desk-brief: forcing questions before any content strategy. Who is this for? What one idea does this piece own?
• /desk-angle: generate 4 to 6 angles/hooks for the same core idea. Each labeled with which voice signature it uses. I pick the winner.
• /desk-position: CEO-mode challenge of the content strategy. Is this reinforcing the pattern or drifting?
• /desk-audience: audience intelligence before channel selection.
• /desk-retro: weekly content retro. What landed, what flopped, which signatures performed.

Phase 3 adds the platform layer: repurpose, intel scan, visual audit, real-browser proof, monitoring, learning, debug. Once Phase 1 is shipping reliably, Phase 2 unblocks the "before we write" work; Phase 3 turns one long-form piece into the full nine-platform cascade.

The build, week by week

What's built

What I'd do differently

• Skip the all-Phase planning doc. Phase 2 and Phase 3 are written out as if they're already designed. They're not. Phase 1 is real and shipping; Phase 2 will get redesigned once Phase 1 generates real data on what's missing. Documenting future phases this thoroughly creates the illusion of a roadmap when what exists is a live system + hypotheses.
• Build the publishing-timeline data structure first. /desk-archive logs to ~/.desk/log/publishing-timeline.jsonl but the schema took two iterations to get right. Should have specified it before writing /desk-publish, not after.
• The voice gate scores need calibration on real published pieces. The 15-point gate has a target distribution (most work scores 12-14; ones in production should be 14+). Without baseline calibration the scores are arbitrary. Need a backlog of 30+ scored real pieces before the gate scores mean anything.
• Don't ship the bullet-flagging logic until /desk-archive runs on 5+ real pieces. Career Desk bullet candidate flagging is conceptually simple but implementation-fragile. It assumes I write achievement-style sentences in published prose, which I sometimes don't. The first wave of flags will probably be noise.

What unlocked the speed

• Reference docs before code. Writing VOICE-GUIDELINES.md and CONTENT-STANDARD.md first meant the skills had a fixed reference point. The skills don't argue with the standard; they enforce it.
• Markdown all the way down. Skills are markdown. Wiki entries are markdown. Voice guidelines are markdown. Content standard is markdown. The system is grep-able, version-controllable, and agent-readable. No proprietary format to maintain.
• Open Brain in place before Content Desk. The semantic memory layer existed before /desk-story needed to query it. /desk-archive enriches a system that already knew how to receive captures.
• Same models as Career Desk. Sonnet for generation; Haiku for fast classification. No new model to learn, no new prompt scaffolding pattern. The only deltas between desks are the prompt content.
• Atelier-not-SaaS aesthetic locked early. Same as Career Desk. The reference is "engineering notebook." Slash commands fit that register. A web dashboard wouldn't.

Marketing OSClaude Code skillsVoice gateHILOpen BrainBuild in PublicBuilder's HonestyDual output