Most Claude Code content production tutorials show the chat window and call it a day. That works for a single post. It collapses the moment a real production calendar is in play, with multiple brands, multiple voice systems, and dozens of pieces shipping every week.

Claude Code is the upgrade. Same model, different surface. It runs from the terminal, reads from files, writes to files, and loads custom skills that carry brand voice and structural rules without re-explaining them in every prompt. For long-form content production, that combination changes the math entirely.

This is the actual setup RZLT uses. Step by step. No filler.

What Claude Code is and why it changes content production

Claude Code is Anthropic's command-line tool for agentic work. Where the Claude chat interface is built for one conversation at a time, Claude Code is built for sessions that touch real files in a real project folder. It can read a brief, write a draft, edit a file in place, run bash commands, check the output against quality gates, and loop until the result clears the gate.

For Claude Code content production, three capabilities matter:

1. File-aware writing. Claude Code reads your existing skill files, brand guidelines, and reference articles from disk every session. The voice never has to be re-explained.

2. Bash execution. Scripts that count em-dashes, audit keyword placement, validate docx output, or post drafts to a CMS run in the same session as the writing.

3. Skill loading. Custom skill files trigger automatically based on the task. Ask for a B2B SaaS listicle and the SaaS skill loads. Ask for a TrustSwap blog post and the TrustSwap skill loads.

Step 1: Install Claude Code

Requirements: Node.js 18 or higher, an Anthropic API key or Claude Pro subscription, and a terminal you are comfortable using.

npm install -g @anthropic-ai/claude-code

npm install -g @anthropic-ai/claude-code

Confirm install:

claude-code --version

claude-code --version

That is the entire install. No Docker, no virtual environment, no platform configuration.

Step 2: Set up the project folder

Claude Code works inside whatever folder you point it at. For content production, the folder structure matters because it tells Claude where to find skills, briefs, and reference material.

The structure RZLT uses:

rzlt-content/
├── .claude/
│   └── skills/
│       ├── rzlt-blog-article/
│       │   └── SKILL.md
│       ├── trustswap-seo-article/
│       │   └── SKILL.md
│       ├── no-chill-sonnet/
│       │   └── SKILL.md
│       └── seo-article-writer/
│           └── SKILL.md
├── briefs/
├── drafts/
└── reference

rzlt-content/
├── .claude/
│   └── skills/
│       ├── rzlt-blog-article/
│       │   └── SKILL.md
│       ├── trustswap-seo-article/
│       │   └── SKILL.md
│       ├── no-chill-sonnet/
│       │   └── SKILL.md
│       └── seo-article-writer/
│           └── SKILL.md
├── briefs/
├── drafts/
└── reference

The .claude/skills/ folder is the important one. Anything dropped in there with a valid SKILL.md file gets loaded automatically. The briefs/, drafts/, and reference/ folders are for working files. Naming does not matter to Claude Code, only to the writer.

Step 3: Write the first skill

A skill is a markdown file with two parts: frontmatter that tells Claude when to use the skill, and instructions that tell Claude how to write when the skill is active.

Minimum viable skill structure:

---
name: rzlt-blog-article
description: Use this skill when writing a blog article for the RZLT blog at rzlt.io. Triggers on any request to write, draft, or create a long-form post for RZLT.
---

# RZLT Blog Voice

Write in short declarative paragraphs. Argument-led prose. Second-person address when appropriate.

## Banned constructions
- No em dashes anywhere. Zero tolerance.
- No "it's not X, it's Y" negations.
- No "we don't" or "we're not" first-person negations.
- No "In today's fast-paced world."
- No "In conclusion."

## Structural rules
- H1 is the article title. Sentence case.
- One key stat per H2 maximum, hyperlinked to the primary source.
- Internal links to 2-3 other RZLT blog posts when relevant.
- Closing section names the principle underneath the argument.

## Quality gates
Before finalizing, run:
- grep for em-dash character in the draft
- keyword placement check across H1, intro, body, closing
- link verification on every external citation

---
name: rzlt-blog-article
description: Use this skill when writing a blog article for the RZLT blog at rzlt.io. Triggers on any request to write, draft, or create a long-form post for RZLT.
---

# RZLT Blog Voice

Write in short declarative paragraphs. Argument-led prose. Second-person address when appropriate.

## Banned constructions
- No em dashes anywhere. Zero tolerance.
- No "it's not X, it's Y" negations.
- No "we don't" or "we're not" first-person negations.
- No "In today's fast-paced world."
- No "In conclusion."

## Structural rules
- H1 is the article title. Sentence case.
- One key stat per H2 maximum, hyperlinked to the primary source.
- Internal links to 2-3 other RZLT blog posts when relevant.
- Closing section names the principle underneath the argument.

## Quality gates
Before finalizing, run:
- grep for em-dash character in the draft
- keyword placement check across H1, intro, body, closing
- link verification on every external citation

That file goes in .claude/skills/rzlt-blog-article/SKILL.md. Restart the Claude Code session and the skill is live. The description field is what triggers loading. Write it clearly enough that Claude knows when to pull the skill without being told.

Step 4: The first content session

Open the terminal, navigate to the project folder, and start Claude Code:

cd rzlt-content
claude-code

cd rzlt-content
claude-code

The first prompt is the brief. The cleaner the brief, the better the output. The structure that works:

Write a blog post for the RZLT blog.

Topic: [topic]
Primary keyword: [keyword]
Target length: [word count]
Audience: [who reads this]
Angle: [the defensible POV]
Internal links to include: [URLs from existing RZLT blog]
Sources to use: [primary sources for any stats]

Write a blog post for the RZLT blog.

Topic: [topic]
Primary keyword: [keyword]
Target length: [word count]
Audience: [who reads this]
Angle: [the defensible POV]
Internal links to include: [URLs from existing RZLT blog]
Sources to use: [primary sources for any stats]

Claude Code loads the matching skill, drafts the article, and writes it to a file in the drafts/ folder. The first draft hits maybe 80% of final. The remaining 20% is the human pass.

Step 5: The edit loop

This is the part that separates real production from hobbyist usage. After the first draft, the writer reads it and gives Claude Code targeted instructions:

Read drafts/article-v1.md. Three issues:
1. The intro paragraph buries the argument. Move the thesis to sentence one.
2. The third H2 has no proof point. Add a stat with a verified source.
3. Two em dashes slipped past the gate in the closing section. Remove them.

Output the revised version as drafts/article-v2.md

Read drafts/article-v1.md. Three issues:
1. The intro paragraph buries the argument. Move the thesis to sentence one.
2. The third H2 has no proof point. Add a stat with a verified source.
3. Two em dashes slipped past the gate in the closing section. Remove them.

Output the revised version as drafts/article-v2.md

Claude Code reads the file, makes the changes, saves the new version. The writer reviews v2. If something is still off, iterate to v3.

This loop is where the real work happens. The skill carries the voice. The brief carries the angle. The edit loop is where judgement gets applied.

Step 6: Quality gates as scripts

The em-dash check, the keyword audit, the link verification — all of it should be a script Claude Code runs against the draft. An example:

bash

# Check for em dashes
grep -c "—" drafts/article-final.md

# Count primary keyword occurrences
grep -ci "primary keyword phrase" drafts/article-final.md

# Verify external links return 200
for url in $(grep -oE 'https?://[^ )]+' drafts/article-final.md); do
  curl -o /dev/null -s -w "%{http_code} $url\n" "$url"
done

# Check for em dashes
grep -c "—" drafts/article-final.md

# Count primary keyword occurrences
grep -ci "primary keyword phrase" drafts/article-final.md

# Verify external links return 200
for url in $(grep -oE 'https?://[^ )]+' drafts/article-final.md); do
  curl -o /dev/null -s -w "%{http_code} $url\n" "$url"
done

These three checks take about ten seconds. Running them every time catches the failures that would otherwise reach the published version. Build the scripts once, run them on every piece.

What gets faster, what does not

This setup is what makes Claude Code marketing workflows actually work: drafting faster, voice consistency higher, quality gate enforcement automatic, and brand-switching nearly free. A writer working on different projects in the afternoon does not have to context-switch because the skills carry the context.

What does not get faster: the strategic decisions. What angle to take, which sources to trust, which keywords to target, when a piece is strong enough to ship. Those still take the same time they took before. The system makes everything around those decisions faster, which means the writer spends more of the working day on the decisions that actually matter.

The principle underneath Claude Code content production

Claude Code is not magic. It is a terminal interface with file access and skill loading. The leverage in Claude Code content production comes from what gets put into the skills and how the project folder is structured. Bad skills produce bad output faster. Good skills produce good output faster. The Claude Code for marketers playbook is exactly this: build the skills, then let the system run.