Marketing agency using ShipifyAI

ShipifyAI was originally designed for software teams, but the same workflow maps cleanly onto any organisation that produces text artefacts in a versioned repository, has a board of work items, and announces results on a chat channel. A marketing or content agency fits the model well. Blog posts, social copy, ad creative, landing pages, email sequences, and campaign briefs are textual artefacts that benefit from version control, peer review, and an explicit record of changes. Agency work also benefits from an AI assistant that has been told exactly which brand voice to honour and exactly which sources can be used to support a claim.

This article walks through the setup of ShipifyAI for a fictional mid-sized full-service agency. It covers how to structure the Jira board, the working repository, and the Slack channel, how to write a `CLAUDE.md` tailored for marketing copy, and which MCP servers to allow so that the AI can draft on-brand copy without inventing statistics or competitor claims.

The scenario

The agency has account directors who own each client relationship, content strategists who plan campaigns, a small team of copywriters who write everything that ships, an SEO specialist who handles keyword and search intent work, and designers who handle visual creative. The agency holds multiple client retainers across consumer and B2B verticals. Deliverables are a mix of long-form pieces such as blog posts and whitepapers, short-form pieces such as social posts and ad copy, and structured copy such as landing pages and email sequences. The agency leadership wants to use AI for first-pass drafting of routine copy so that strategists and copywriters can spend their time on strategy, brand thinking, and the higher-craft work that wins client renewals. Nothing leaves the agency without a copywriter or strategist signing off.

ShipifyAI's role is to take a structured task from Jira, hand it to Claude with the relevant client's brand book and the agency's claims policy, produce a copy draft committed to the repository, open a pull request for human review, and post the link in Slack. Nothing reaches a client or a published channel without a senior copywriter approving the work into the CMS, the email platform, or the ad system.

Setting up the document repository

The agency uses GitHub as its working repository, with private access restricted to the agency team. The repository is structured to mirror the client portfolio. Each top-level directory is a single client, with branch protection restricting access to the team assigned to that client. Within each client directory there is a `brand-book` subdirectory containing the canonical voice, tone, do-not-use list, and claims policy for the client; a `campaigns` subdirectory containing active campaign briefs and the copy they produce; a `templates` subdirectory containing reusable email templates, landing page outlines, and ad copy patterns; and an `archive` subdirectory containing past pieces that strategists draw on for context. Every Markdown file uses YAML front matter for metadata such as channel, target persona, keyword cluster, target word count, and call to action.

The ShipifyAI CLI writes its copy as Markdown — that is the format the agent emits to the branch, because plain-text diffs make pull request review meaningful, branches stay tidy, and the AI can produce changes the same way it produces code. What the agency does with that Markdown once a strategist has reviewed it is the agency's own call, and outside ShipifyAI's scope. Some pieces are rendered through a CI pipeline into the client's house template for proofreading; others are pasted into Google Docs for client review; others go straight into the client's CMS, the email platform, or the ad system. The same CI pipeline, where it exists, is also a useful place to lint front matter and to check the draft against the client's banned-phrases list before the strategist sees the result — but that is an agency choice, not something ShipifyAI provides or requires.

A key difference compared with the software scenario is that pull requests in the agency are not a gate to merging. They are a delivery channel. The AI's deliverable is the copy itself, sitting on a feature branch, with a pull request that gives the copywriter a structured place to read the diff, mark changes, and pick up the work. Most drafts are never merged into the default branch at all. The copywriter reviews the draft on the branch, takes the prepared text into the client's CMS, the email platform, the ad system, or the client's delivery channel, and that completes the task. The branch can then be deleted or kept for record.

The default branch is reserved for the canonical, client-wide artefacts: the brand book, the templates, and the claims policy. Changes there happen rarely, and they happen through deliberate, strategist-led merges, often as a separate housekeeping task that is not driven by the AI at all. Direct pushes to the default branch are still forbidden through branch protection, and the few merges that do happen still go through human approval. But the bulk of the AI's output never touches the default branch.

This shifts how branch protection is configured. The default branch still requires a pull request and at least one approval from the account director or content strategist before merging, and required status checks still include the lint and the banned-phrases check. But the agency does not pressure copywriters to merge AI feature branches. The expected lifecycle of an AI branch is: produced by the worker, reviewed by a copywriter, the draft is taken into the client deliverable channel, the branch is closed.

The GitHub Personal Access Token used by the worker follows exactly the same rules as in the software scenario. It is a fine-grained token, scoped to this single repository, with Read and write permissions on Contents and Pull requests, Read-only on Metadata, and no Administration permission.

Setting up the Jira board

The Jira project mirrors the client portfolio. Each issue represents a unit of copy work, such as an 800-word blog post for a keyword cluster, a five-email nurture sequence for a launch, a set of headline variants for a paid social campaign, or a landing page copy update.

The board has four columns that match the ShipifyAI model. The source column, named "Ready for AI drafting", holds tasks that have been screened by a content strategist and are deemed appropriate for AI drafting, with the brand book, the keyword brief, and any supporting context referenced in the issue. The In Progress column holds tasks the AI is currently working on. The In Review column, renamed "Ready for copy review", holds tasks where the AI has produced a draft on a feature branch and a pull request has been opened. From this column a copywriter picks up the draft. The Incomplete column holds tasks the AI returned because the brief was insufficient, because the claim required substantiation the AI could not retrieve, or because the work required strategic judgement before drafting could begin.

The board has a fifth column, "Backlog", which is not visible to the AI. The account director or content strategist lands every new task there. The strategist reviews each task, decides whether it is appropriate for AI drafting, and only then moves it to "Ready for AI drafting". This intake step is the agency's primary safety gate. Anything client-confidential that has not been cleared for AI processing, anything involving named-competitor comparisons, anything regulated such as financial or healthcare claims, and anything strategic such as positioning or brand work is never moved to the AI column. It stays with a copywriter and a strategist throughout.

The minimum wait time on the project is set to a few hours rather than a full business day. Campaign deadlines are often tight, but the buffer still gives a copywriter a window to claim a task they want to write themselves. This preserves craft development and gives the agency the option to assign a piece to a named human writer if the client expects one.

Setting up the Slack channel

The agency uses Slack for internal coordination, plus separate channels with each client. A dedicated channel, `#content-ai`, is configured as the project's notification channel in ShipifyAI. The channel is restricted to the agency's internal team. Notifications it receives include the announcement that a draft is ready for review, with a link to the pull request that holds it, and the announcement that the AI was unable to complete a task and the reason why. The link in the notification is the copywriter's entry point: they click through, read the diff, and take the work from there.

The Slack Bot Token is generated and configured exactly as described in the worker configuration article, with the same four scopes. The bot is invited explicitly to `#content-ai` and to no other channel. It is never invited to any channel shared with a client, and it is never invited to the agency's general or sales channels.

Writing a CLAUDE.md for the marketing context

The `CLAUDE.md` file is where the agency's conventions, plus each client's voice profile, are taught to the AI. It is the most important file in the repository for the quality of the drafts produced, and it is worth investing time in.

The file opens with a project overview that explains the agency, its principal verticals, and the way work is organised by client. The file describes the structure of the repository, naming the per-client directories, the brand books, the campaigns, the templates, and the archives. It tells the AI that brand-book changes propagate to upcoming pieces only through the deliberate action of a strategist pulling in the latest guidance, so a brand-book edit must never silently rewrite past drafts.

The file describes the agency-wide standards. Tone is matched to the client's voice profile. Reading-level targets favour plain language for consumer audiences and a more technical register for B2B. Channel-specific length and format constraints are listed: social posts have platform-specific character limits, email subject lines have a target length, ad copy has a discipline of one promise per piece. The file lists agency-wide banned constructions, cliches, and lazy openings.

The file also lists what the AI must never do, and this section is the most distinctive part of a marketing agency CLAUDE.md. It must never invent a statistic, never invent a customer quote, never invent a study, and never present an unverified number as fact. It must never make a comparative claim about a named competitor unless the brand-book explicitly permits and supplies the source. It must never make a regulated claim about a product's efficacy in health, finance, or other regulated verticals. It must never include GDPR-sensitive personal data in a draft. It must never bypass the review gate by trying to push directly to the default branch.

"AI-generated statistics" is the single biggest distinct risk in this scenario, and the file says so explicitly. Every number in a draft must be either retrieved through one of the allowed MCP servers and cited, or marked as a placeholder for the copywriter to fill in.

The file ends with a checks section. Before considering a task complete the AI must run the agency's lint script, which validates front matter and checks for banned phrases. It must run the claims pass, which verifies every factual claim has a source. It must run the SEO pass for any piece with a keyword target. It must produce a summary of the change in the pull request body, written for the reviewing copywriter, listing every cited source and flagging any unverified claim.

Allowed MCP servers for marketing drafting

This is where the agency scenario diverges from the software scenario. The AI in a marketing context needs structured access to client brand books, the agency's SEO tooling, and a curated set of competitor and market references, and it must not be allowed to fabricate statistics or fetch arbitrary URLs from the open internet.

The agency enables a small, curated set of MCP servers on the worker machine, configured in `~/.claude/mcp.json`. The list is intentionally narrow.

• A brand-book MCP server, scoped to the brand book of the client whose task the worker is currently handling. The server exposes structured lookups for voice, tone, banned phrases, claims policy, and approved customer terminology.
• A keyword/SEO MCP server, scoped to the agency's own SEO tooling exports such as Search Console performance and the agency's keyword research database. The server exposes search by keyword and intent and fetches metrics for a specific term. The AI uses it to ground SEO decisions in the agency's actual data.
• An archive MCP server, scoped to the client's `archive` directory. The server exposes search across past pieces so the AI can model the client's voice from real examples and avoid repeating angles already used.
• A filesystem MCP server, scoped to the working directory of the repository. This is the same MCP recommended in the software scenario.

The agency explicitly does not connect MCP servers that the AI could use to fabricate statistics or to operate against the agency's interest. There is no MCP server that can fetch arbitrary URLs from the open internet, because the moment the AI can pull a random URL it can cite a content farm or a hallucinated study as if it were authoritative. There is no MCP server connected to the agency's billing, CRM, or HR systems. There is no MCP server connected to client analytics platforms unless the client has explicitly authorised it through the brand book.

The MCP configuration file lists the chosen servers under `mcpServers`, naming each one and specifying the command that runs it. Each server runs as a child process of Claude Code on the worker machine, with its own credentials managed inside the server itself, and only the typed interface is exposed to the AI.

Skills for marketing copy

The agency ships its own skill pack inside `.claude/skills`, parallel to the software scenario but tailored for marketing work.

A `draft-blog-post` skill describes the agency's preferred structure for long-form content, including the hook, the structural promise to the reader, the body with subheadings, and the close with a single clear call to action. The skill instructs the AI to consult the brand book first, the keyword brief second, and the archive third to avoid repeating angles.

A `draft-social` skill describes the per-platform conventions, including character limits, hashtag policy, and the agency's approach to first-line hook writing. The skill produces several variants per task for the copywriter to choose from.

A `draft-email-sequence` skill describes the agency's approach to nurture sequences, including pacing, subject-line discipline, and the relationship between subject, preheader, and body.

A `headline-variants` skill produces a fixed number of headline variants for any long-form piece, with a discipline of one promise per variant and a banned-pattern check against the brand book.

An `apply-brand-voice` skill is a dedicated pass that re-reads a draft against the brand book and rewrites passages that drift from the client's voice. The skill is useful both as a step inside other skills and as a standalone task when a strategist wants to bring an older piece in line with an updated brand book.

An `seo-pass` skill applies the SEO brief to the draft, including title and meta description optimisation, header structure, and the placement of the target term and supporting terms in line with the agency's house guidance.

A `self-review-claims` skill mirrors the software self-review skill but adapted for marketing artefacts. It is the most important skill in the pack. It instructs the AI to re-read the draft as a sceptical legal reviewer, to verify that every factual claim has a citation retrieved through one of the allowed MCP servers, to flag every comparative claim and check it against the brand-book's competitor policy, and to mark every unverified number as a placeholder. A draft that fails the claims pass is returned to the strategist as Incomplete.

Iterating with the AI through review comments

The copywriter is not limited to taking the first draft as-is. The same PR review follow-up loop that the software workflow uses is available in the agency scenario, and it is the natural way to push corrections back to the AI without rewriting the copy by hand.

Every pull request opened by the worker has a title that starts with `[AI GENERATED]`. As long as that prefix is in the title, the AI will keep watching the pull request and will respond to review comments on it. A copywriter or strategist writes a review comment on the relevant line or paragraph, exactly as a senior copywriter would write feedback for a junior. The comment can ask for a tighter intro, a different angle, a different call to action, a softer or sharper tone, an additional benefit framing, or any other concrete change. Comments that involve client conversations or strategic positioning are handled offline by the human team; the AI loop is purely internal to the agency.

Six hours after the comment is posted, the worker treats the thread as actionable, posts a thumbs-up reaction as an acknowledgement that work has started, and asks Claude to address the comment in the context of the current branch. If Claude makes the change it commits the edit to the same feature branch with a message starting `[AI GENERATED] address review comment`, pushes the branch, and replies on the thread with `done [AI GENERATED]`. If Claude judges the comment incorrect or out of scope, it replies with `[AI GENERATED] declining` and a one-sentence reason, and leaves the text unchanged.

The six-hour minimum delay exists deliberately so that quick clarifications between agency team members do not trigger AI responses. If a copywriter leaves multiple comments at once, the AI handles each thread independently in its next iteration cycle. A thread that the copywriter resolves manually is skipped by the AI entirely.

This loop is what makes the "draft on a branch, take it from there" model practical. The copywriter does not need to perfect every draft by hand. They can hand back specific corrections, get a revised version a few hours later, and only then decide whether to take the copy into the client deliverable channel or discard the branch.

Security and confidentiality

The four pillars of ShipifyAI's security model apply to the agency scenario as they do to the software scenario, with a few agency-specific reinforcements.

The worker runs on a dedicated, isolated machine with no client confidential data outside the active task. The agency runs separate workers for engagements that have heightened confidentiality obligations or NDAs, so that copy drafted for one client never sees the brand book or the campaign material of another. The worker machine has no email client, no CRM credentials, no access to the agency's billing or time-tracking systems, and no access to any client's authenticated analytics unless the client has explicitly opted in. The AI sees only the per-client directory it is working on and the MCP servers explicitly listed in the configuration.

The AI does not modify Jira directly. The strategist's intake decisions are the agency's primary safety gate, and the worker only ever sees tasks that have been approved into the source column.

The AI cannot push to the default branch. The AI's working artefact is always a feature branch with a pull request, and the copywriter takes the draft from there into the client deliverable without merging in most cases. The PAT scope refuses direct pushes to the default branch, the deny list in the Claude settings refuses it, the CLI's branching logic does not produce such pushes, and the branch protection rule on the GitHub side would reject the operation.

In addition to the standard four pillars, the agency enables an egress firewall on the worker machine that allows outbound traffic only to the GitHub API, the ShipifyAI backend, the Anthropic API, the Slack API, and the specific endpoints of the allowed MCP servers. The AI cannot reach the open internet from the worker, so it cannot fetch arbitrary URLs that pretend to be sources, and it cannot exfiltrate draft copy. The agency also enables read-only mounts for everything outside the project working directory and rotates the worker container daily.

A typical task end-to-end

Consider how a single task flows through this setup. A client retainer includes a monthly blog programme, and the content strategist has scheduled an 800-word post on a chosen topic for a target keyword cluster. The strategist creates a Jira issue titled "800-word blog: topic X for keyword cluster Y, client Z", attaches the keyword brief, references the relevant section of the client's brand book, and lands the task in Backlog. After reviewing, the strategist moves it to "Ready for AI drafting". The minimum wait time of a few hours ticks down.

The next morning the worker picks up the task. Claude reads `CLAUDE.md`, loads the marketing skills, retrieves the client's brand book through the brand-book MCP, retrieves the keyword brief and metrics through the SEO MCP, checks the archive MCP for prior pieces on the same topic, and produces a feature branch with an 800-word draft that follows the agency's structure. Every factual claim is annotated with its source. Two numbers that the AI could not verify are left as placeholders with a note for the copywriter. The AI then runs the lint script, runs the seo-pass skill, runs the self-review-claims skill, and opens a pull request titled "[AI GENERATED] 800-word blog: topic X for keyword cluster Y". The pull request body summarises the piece, lists every citation, lists the two placeholder numbers, and notes the SEO posture. The Slack bot posts the link to `#content-ai` and the Jira task moves to "Ready for copy review".

A senior copywriter opens the pull request, reads the diff, decides the intro is too soft and the call to action is wrong for the funnel stage. They leave two review comments asking for a sharper hook and a different CTA, and they fill in the two placeholder numbers directly with values cleared by the client. Six hours later the worker addresses the two AI-actionable threads, makes the changes, replies `done [AI GENERATED]` on each, and pushes the revisions to the same branch. The copywriter reads the new version, accepts it, takes the text into the client's CMS for publication, and the pull request is closed without merging.

The Jira task moves to Done the moment the copywriter has used the draft. The Slack channel announces the pickup. Nothing on the default branch needed to change for the post to be published.

At every step a human controls the gate. The strategist decides what the AI works on. The reviewing copywriter decides what part of the draft is good enough to publish. The AI does the bulk of the mechanical drafting and source verification, which is exactly the kind of work that benefits from automation, while strategy, brand judgement, and client relationship remain entirely with the agency team.

Where to go next

The worker configuration article explains how to obtain and install each integration token in detail. The Claude configuration article explains how to write `CLAUDE.md`, how to author skills, and how to configure the allowList. The control article explains how a copywriter takes a draft or a task back from the AI at any point. The security article explains the four pillars in depth, including the rationale behind each layer of defence.