SOPs

Public vs Internal Writing

The Split Is Audience, Not Format

The two properties look similar (markdown, headings, short paragraphs) but the reader is not the same person.

Public — themarketingshow.com. Anyone with Claude Code, not on James’s machine. The post has to teach from zero. Real paths, repo names, PII, CRM IDs, and infrastructure specifics cannot leak out. Voice has warmth and some personal color, but the reader is there to learn, not to listen to a story.
Internal — tms-internal. James, on his own machine, with the full context of the stack already loaded. Reference prose: direct, clipped, skip preamble. Can say “the script lives at ~/apps/cc/recipes/redact-image.py” because that path is real and useful. A year-from-now James should recognize the page within ten seconds of landing on it.

What Goes Where

Topic	Public	Internal
A new capability Claude can perform	the concept and the prompt a reader would use	the tool name, real path, args, dependencies, failure modes
A procedure	when the reader might run it themselves	the checklist James follows, with real machine names
Infrastructure state (machines, VPS, DNS)	never	yes, with pointers not secrets
Credentials or tokens	never	pointers only, never actual values
A client or customer example	fictionalize names, cities, contact IDs	real names and IDs fine
Voice and style guide	the published voice profile at `~/apps/james-voice/`	editorial and working rules
Incident writeup or debugging log	never	yes, as precedent for future decisions

What NEVER Leaves The Wiki

These stay internal no matter how useful they would be in a blog post. The firewall matters more than the post.

Real repo names, file paths, subdomain hostnames, dev server ports
Machine names, IP addresses, VPS details, SSH aliases
API keys, OAuth tokens, webhook URLs — even partially
Real CRM contact IDs, phone numbers, email addresses, customer names
The specific phrasing of internal automation prompts, scheduler entries, or workflow logic that would give a competitor a free copy of the playbook

Content on themarketingshow.com is already governed by two matching SOPs in that repo’s CLAUDE.md:

No PII in Published Content — replace real names, never publish real contact info
No Infrastructure Details in Published Content — no real repos, domains, IPs, paths, or config values

If a draft sits in the middle (e.g., referencing a “self-hosted Supabase endpoint” without the actual hostname), that is fine. The test is whether the reader could use what is written to access, probe, or clone James’s infrastructure.

When The Same Topic Belongs In Both

Some capabilities are worth the public writeup AND the internal writeup. When that happens, write them as two separate pages, not one page syndicated. The audience-shaped edits are not cosmetic.

Public version leads with the outcome and the prompt, allows one sentence of personal color, then shows the how a reader would reproduce it. No real paths, no repo names. Featured image shows the result, not the terminal. The internal page can link to the public post to note it has been externalized. The public post does not link back to the wiki.

Internal version is reference prose. Tool name, where it lives on the machine, args, dependencies, failure modes, related SOPs. No narrative, no personal setup. If the reader (future James) wanted narrative, they would read the blog post.

Voice Shift

Public — blog voice. Consult ~/apps/james-voice/voice-profile.md. “So” and “okay” transitions, “super” as the intensifier, a personal hook at the top, warm close. But lean, not padded. One sentence of setup, not three paragraphs.
Internal — wiki voice. Plainer. No “so,” no “right?” No building to a point. Open with the substance. Reads like James explaining something to himself a month from now.

Full wiki voice guide is in the meta-SOP: Adding a Page to tms-internal, section “Writing voice.”

The “Where Does This Belong” Test

Three questions, in order. Stop at the first “yes” or “no” that answers it.

Would publishing this leak PII, infrastructure, credentials, or client detail? If yes, internal only. Stop.
Would a reader without my setup get value? If no, internal only. Stop.
Would I still want a private working copy with the real paths? If yes, write both — two pages, not one.

Stub Notes — Open Questions

This SOP is a starting point. Add to it as the distinction sharpens.

Footer convention for cross-referenced pages. If a capability has both an internal page and a public post, the internal page should link out (“published externally at ”) so future James knows the concept has been externalized. Need a consistent footer snippet.
How-we-do-it process docs. Some of what TMS does (the Facebook post to blog post pipeline, the video to article pipeline) is private choreography and some of it is teachable publicly. Probably both, with different framing. Worth a dedicated SOP once the pattern is clearer.
Build-note style. Internal pages tend to accumulate “Precedent” sections that capture incidents. Those should probably not bleed into public blog posts even when the general lesson is transferable. Write the lesson fresh for the blog, do not paste in the internal precedent.

Adding a Page to tms-internal — voice guide and page anatomy for the wiki
~/apps/james-voice/voice-profile.md — published blog voice master reference
~/apps/themarketingshow/CLAUDE.md — the content rules that enforce this at publish time