Building an agentic content production system with Claude Code
Director, Web and Content Strategy
This post by an engineer explains how his team uses the .claude folder in Claude Code. The folder is the hidden directory where you store context files, behavioral rules, and automated workflows so Claude understands how to operate in a specific project. He’d set up coding conventions, tool configs, CI integrations. Very engineering-brained. The tool is called Claude Code, so fair enough.
I run a web and content team. We write blog posts, tutorials, and technical guides for a living. Not the target audience.
But the .claude folder kept nagging at me. Structurally, it solves a content operations problem. You define your voice, your process, your team structure, your quality bar once, in files. Claude reads the folder before every session. It remembers what you told it last time because you wrote it down. That’s not an engineering trick. That’s institutional memory, which is the thing every content team pretends to have and actually stores in three people’s heads and a Google Doc from 2022.
So we adapted it. This post walks through what we built: a shared Claude Code project called the Content Workflow Manager. Five people, one content function, production to publishing to distribution. The system is early and I’ll be honest about where. Here’s what’s in the folder.
A .claude folder for a marketing team holds the same things it holds for an engineering team: context, rules, and workflows, scoped to content production instead of code. Ours defines voice and tone, a four-stage review process, team routing, and six invocable skill workflows. Claude reads it before every session. The system handles the rest.
What a content team’s Claude Code system does
The Content Workflow Manager handles our full production cycle for blog posts, tutorials, technical guides, website copy, landing pages, and the newsletter. Scoping requirements, drafting, structured review, Contentful publishing prep, and post-publish distribution copy. It also runs our issue workflow in Linear: inbox triage, sprint planning, weekly leadership summaries.
Our stack is Claude Code, Cursor, and Linear. Claude Code is the agentic layer where the .claude folder lives and where the system runs. Cursor is where some team members prefer to work day-to-day. Linear is how I keep track of everything across the team. Every issue we create, triage, plan, and close flows through Linear, which means I can see all work in one place regardless of which lane it belongs to.
Five people use the system. Two content managers who produce drafts. A production manager who runs the publishing checklist before anything goes live. A web producer who facilitates standups and coordinates across teams. And me, responsible for strategy and anything that touches the system itself.
We work four lanes. New SEO and GEO posts get the full production workflow from requirements through publish. Tutorial updates run off Linear-based task briefs and follow their own rhythm; this lane is still under construction. System work covers improvements to the workflow manager itself. And there’s a general lane that handles everything else.
That last one turned out to be the most interesting. Any team member can open a session in the Content Workflow Manager and work on any type of task, whether or not it’s a blog post. They get the full context of the system for free: voice rules, review processes, team routing, all of it loaded before they start. It’s a context bubble. You step inside it and Claude already knows how your team works, who owns what, and what the quality bar looks like. That applies just as well to writing a stakeholder update or scoping a project as it does to drafting a blog post.
The .claude folder, annotated
I’ll walk through each component and explain why it exists. The “why” is the part I wish more people published.
The most important file. Claude reads it at the start of every session. It defines the system’s purpose, who does what, how the four lanes work, and which knowledge files and skills to load. Single source of truth for how Claude behaves in this project.
We update it when the system changes. If something isn’t in CLAUDE.md, Claude doesn’t know about it. This sounds obvious but it took a few sessions of “why doesn’t it know about the new review stage” before the lesson stuck.
.claude/agents/
Persona files. Behavioral profiles Claude adopts for specific tasks. When a condition is met (a review stage begins, a strategy session opens), Claude reads the relevant file and works from inside that persona for the duration of the task.
We have seven. Each one has a documented personality, biases, and working style. Three work outside the production workflow. Four run the review stages in sequence.
The Architect is the strategic advisor. It surfaces assumptions, presents options with tradeoffs, and frames problems before proposing solutions. I use it for campaign planning and system decisions. It’s the one I talk to when I’m not sure what we should be doing next, which is more often than I’d admit publicly.
The Librarian is the research agent. Competitive analysis, GEO research, claim validation. Its core constraint is epistemic integrity: it states uncertainty directly and never fills gaps with inference. If it can’t verify something, it says so. That one constraint prevents more problems than any other rule in the system.
The Mouthpiece handles communications that need careful register. Stakeholder updates, exec briefings, anything where tone has to land right on the first pass. It writes in a consistent, even-keeled, considerate voice and adjusts formality based on who’s reading and where they sit in the org. I built it because getting the tone right for a VP update is a different problem than getting the facts right, and I wanted a persona tuned specifically for that.
The remaining four run our review stages. A review process that agrees with everything you write is not a review process, so each of these is built with specific friction.
The Corrector runs Stage 1. Technical accuracy: code correctness, version numbers, hallucinated product features, unsourced claims. The brief I wrote says “jaded Hacker News energy.” It does not give you the benefit of the doubt.
Webcrawler handles Stage 2. SEO and GEO optimization: keyword density, answer-first structure, internal linking, AI retrieval patterns. It knows the difference between content that ranks and content that simply exists on the internet.
The Censor is Stage 3. Brand voice enforcement: prohibited phrases, AI-generated writing patterns, active voice, inclusive language. It maintains a growing list of patterns we’ve banned. “In today’s rapidly evolving landscape” was the first casualty. It was not the last.
The Focus Group covers Stage 4. It stands in for the target reader and evaluates whether a piece would actually convert someone. Scorecards, specific feedback, no generalities. If it can’t point to the paragraph that lost the reader, the review isn’t done.
.claude/rules/
Knowledge files Claude reads as context throughout sessions. Not prompts. Reference documents. Claude consults them the way a new hire consults internal docs: before acting, not after making something up.
Eleven files. I won’t walk through every one, but the ones worth annotating tell you something about how the system thinks.
Brand voice covers tone principles, prohibited phrases, and a content quality checklist. The checklist lives here because if it lives in someone’s head, it gets skipped. If it lives in a shared doc, it gets skipped slightly more politely.
Review process defines the four-stage sequencing, scorecard format, pass/fail criteria, and the change suggestion protocol. The protocol is specific: reviewers suggest changes one at a time, show before and after text, and ask before implementing. We wrote it out because “leave suggestions as bullets” was producing noise, not usable edits.
Cross-content strategy is our internal linking framework. Tier 1 keywords that must link to specific URLs on first mention, tier 2 keywords for contextual opportunities, density rules per thousand words. This is the kind of knowledge that normally lives in one person’s head and gets inconsistently applied. Writing it into a reference file means Claude enforces it every session without being reminded.
Pipeline defines the four lanes with stage ownership and routing logic. Who owns what type of work, what review tier applies, how issues move through Linear states. It exists because ambiguity about routing is how things fall through cracks, and a five-person team can’t afford to lose track of who’s responsible for what.
CircleCI principles documents the company’s five guiding principles and seven manager behaviors. The Architect uses them as a review lens when evaluating strategic decisions. That was a deliberate design choice. Company values usually live on a wall or in an onboarding deck. Encoding them as a reference file that an agent actually reads before giving advice turns them into something functional.
Scheduling defines the work week, a weekend date guard, and due date rules. It exists because we kept setting due dates on Saturdays. I realize that sounds like a small thing. It was a small thing. It happened every single week until we made the machine stop letting us do it.
.claude/skills/
Skills are invocable workflows. Structured prompts Claude executes when triggered by a specific phrase. Each skill folder has a SKILL.md defining modes, sequencing, and behavior.
Six skills.
seo-geo-post is the full production workflow for new content: requirements, outline, draft, four-stage review, publish prep, distribution copy. It’s the longest skill and the most tested. It has a checkpoint command that exports a structured resume block for long sessions that risk losing context. We built that after losing a full review pass to a session timeout. You only need that to happen once.
tutorial-update creates a scoped update task in Linear with staleness flags and a brief. The skill doesn’t produce content. It produces the task that starts production. That distinction matters because it means the skill encodes how we think about work, not just how we do it.
publish-prep is a Contentful checklist. Confirms metadata, verifies internal links, and checks production requirements before CMS entry. It runs before every publish.
promote generates post-publish distribution copy: newsletter blurb, LinkedIn post, short-form social. Triggered after a piece goes live.
the-guild is the operational spine. It started as an issue management layer for content work, but it turned into something bigger. Six modes: triage inbox, post-sync after team meetings, planning, backlog review, mark done, weekly summary. Every issue the team creates, processes, plans, and closes goes through it, across all four lanes. The general lane runs entirely through THE GUILD because there’s no other production skill attached to it. If someone on the team needs to scope a project, draft a proposal, or plan a cross-functional initiative, they open a session and THE GUILD handles the issue lifecycle while the rest of the system provides context.
The weekly summary is my favorite. Right now it generates a single leadership-ready narrative from the past week’s completed work. The vision is to split it into two modes: a Monday version that preps the team for our weekly backlog meeting by surfacing what’s ready, what’s overdue, and what needs scoping, and a Friday version that rolls up wins and progress for the report I send to my VP. Same underlying data, different framing, different audience.
The name is from Discworld. In Ankh-Morpork, every profession has a guild. The Alchemists’ Guild, the Thieves’ Guild, the Fools’ Guild (where clowning is no laughing matter). Each one manages its own affairs and sets its own standards. A self-governing body for a self-governing system. The content team needed a guild. So we made one.
workflow-skill-check is environment validation. Confirms all expected files are present and the Linear MCP connection is live. Run it after cloning or pulling updates. It’s the boring one, which means it’s the one you’ll be most grateful for at 9am when something isn’t working and you don’t know why.
Where it is today
The system is early, and that’s the honest version. The review workflow is solid and the issue management layer does what we need it to. Some skills are more mature than others, and the tutorial lane is still getting tuned. But the core of it works, and we use it every day.
What surprised me was how fast it outgrew content. I built this for blog posts and tutorials, but the general lane and THE GUILD turned it into something any team member could use for any type of work. That changed how I think about where it goes next.
We’re five people on one content team at CircleCI. We built this because we got tired of doing the same work manually every week and decided to write it down in a way a machine could read. The fact that the machine is Claude and the format is a hidden directory is an implementation detail. The actual decision was “let’s stop pretending we’ll remember the process and make the process remember itself.”
The Growth team is the next group I want to bring in. After that, wider marketing, each with their own CLAUDE.md but the same folder structure and shared patterns where they make sense. Right now we’re learning what generalizes and what’s specific to how our five people work.
If you’re building something like this for your team, the .claude folder is where it starts. What you put inside it is up to you.
