Editorial office 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. An online publication or magazine fits the model exceptionally well. Articles, briefs, explainers, and recurring column entries are textual artefacts that benefit from version control, peer review, and an explicit record of changes. Editorial work also benefits from an AI assistant that has been told exactly which sources to trust and exactly which house-style rules to follow.

This article walks through the setup of ShipifyAI for a fictional mid-sized online publication. It covers how to structure the Jira board, the document repository, and the Slack channel, how to write a `CLAUDE.md` tailored for editorial drafting, and which MCP servers to allow so that the AI can draft, fact-check, and cite without fabricating sources.

The scenario

The publication has an editor-in-chief who oversees the desk, three section editors covering news, features, and opinion, a small team of staff writers, and a fact-checking desk that signs off on anything before publication. The publication maintains a private repository of unpublished drafts, an archive of published pieces, a canonical style guide, and a pitches inbox. Most stories pass through a multi-stage edit before publication. The editor-in-chief wants the AI to take routine first-pass drafting off the staff writers so they can spend their hours on reporting, interviews, and editorial judgement. Nothing reaches readers without a human editor signing off.

ShipifyAI's role is to take a structured task from Jira, hand it to Claude with the publication's conventions and approved sources, produce a draft article committed to the repository, open a pull request for editorial review, and post the link in Slack. Nothing leaves the publication without a section editor approving the work into the CMS.

Setting up the document repository

The publication uses GitHub as its document repository, with private access restricted to the editorial team. The repository is structured to mirror the desk. There is a `drafts` directory for in-flight stories, organised by section and slug. There is a `pitches` directory where the intake editor lands raw ideas before they become tasks. There is an `archive` directory containing the published versions of every piece, kept in sync with the CMS through a one-way export. There is a `style-guide` directory containing the publication's house manual, organised by topic. There is an `assets` directory for images and embeds that travel with a piece. Every Markdown file uses YAML front matter for metadata such as slug, section, target word count, byline, and embargo date.

The ShipifyAI CLI writes its drafts 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 publication does with that Markdown once an editor has reviewed it is the publication's own call, and outside ShipifyAI's scope. Some pieces are rendered into the house template through a CI pipeline for proofreading; others go from the branch straight into the CMS; others are pasted into Word for the chief editor's final pass. The AI's job ends with the draft on the branch.

A key difference compared with the software scenario is that pull requests in the editorial office are not a gate to merging. They are a delivery channel. The AI's deliverable is the draft itself, sitting on a feature branch, with a pull request that gives the section editor 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 section editor reviews the draft on the branch, pastes the prepared text into the CMS for final layout and publication, and that completes the task. The branch can then be deleted or kept for record. Nothing has to land on the default branch for the piece to ship.

The default branch is reserved for the canonical, publication-wide artefacts: the style guide, the editorial standards document, and the published archive synced from the CMS. Changes there happen rarely, and they happen through deliberate, editor-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 editor-in-chief or the standards editor before merging, and required status checks still include a linter that validates front matter and a forbidden-terms check that flags banned phrasing. But the publication does not pressure editors to merge AI feature branches. The expected lifecycle of an AI branch is: produced by the worker, reviewed by an editor, the draft is taken into the CMS, 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. The worker can therefore push feature branches and open pull requests, but it cannot bypass branch protection on the default branch and it cannot merge anything itself.

Setting up the Jira board

The Jira project mirrors the desk. Each issue represents a unit of work, such as a 400-word news brief on a product launch from a press release, a 1200-word explainer on a recurring topic, a column entry with a fixed template, or an interview write-up from a transcript.

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 section editor and are deemed appropriate for AI drafting. The In Progress column holds tasks the AI is currently working on. The In Review column, renamed "Ready for pickup", holds tasks where the AI has produced a draft on a feature branch and a pull request has been opened. From this column a section editor takes the draft into the CMS. The Incomplete column holds tasks the AI returned because the brief was insufficient or because the story required reporting the AI could not do.

A task moves out of "Ready for pickup" the moment a section editor has used the draft. Whether the underlying pull request is merged, closed without merging, or left open as a record is a separate decision that does not affect the workflow. Most often the pull request is closed without merging once the article has shipped through the CMS.

The board has a fifth column, "Backlog", which is not visible to the AI. The intake editor lands every pitch there. The section editor reviews each pitch, decides whether it is appropriate for AI drafting, and only then moves it to "Ready for AI drafting". This intake step is the desk's primary safety gate. Anything involving original reporting, sensitive sourcing, embargoed information that has not been cleared, or first-person commentary is never moved to the AI column. It stays with a human writer throughout.

The minimum wait time on the project is set to a few hours rather than a full business day. News moves faster than legal drafting, but the buffer still gives a staff writer a window to claim a brief they want to write themselves. This preserves the apprenticeship value of routine drafting work.

Setting up the Slack channel

The publication uses Slack for desk coordination. A dedicated channel, `#editorial-ai`, is configured as the project's notification channel in ShipifyAI. The channel is restricted to editors and staff writers. Notifications it receives include the announcement that a draft is ready for pickup, with a link to the pull request that holds it, and the announcement that the AI was unable to complete a brief and the reason why. The link in the notification is the editor's entry point: they click through, read the diff, and take the work from there. The channel is a recap of the AI's activity, not a substitute for the desk's main coordination channel.

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 `#editorial-ai` and to no other channel. It cannot post elsewhere by accident, and in particular it is never invited to any channel shared with sources or freelancers.

Writing a CLAUDE.md for the editorial context

The `CLAUDE.md` file is where the publication's conventions 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 what the publication is, who reads it, what its editorial voice is, and what its mission is. It explains the principal sections, the typical word counts, and the language register expected in each. The AI then knows that a news brief is plain and lean, that a feature has room for narrative scenes, that an opinion piece carries a byline voice, and that the publication's audience is informed but not specialist.

The file describes the structure of the repository, naming the drafts directory, the pitches directory, the archive, and the style guide, and explaining what kind of artefact lives where. It tells the AI that style-guide changes propagate to upcoming pieces only through the deliberate action of an editor pulling the latest guidance into a section, so a style edit must never silently rewrite past drafts.

The file describes the publication's house style. This includes formatting conventions, such as headline case, dek length, and the use of subheadings every few hundred words. It includes terminology preferences, such as whether to write "AI" or "artificial intelligence" on first reference. It includes the publication's preferred citation format for quotes, sources, and external links. It includes a list of banned phrases, cliches, and constructions the editors do not want to see.

The file also lists what the AI must never do. It must never invent a quote, never invent a statistic, never invent a source, and never claim a fact that is not supported by the brief or by a retrieval through one of the allowed MCP sources. It must never publish a piece that purports to be on-the-record reporting. It must never include unconfirmed embargoed information. It must never bypass the review gate by trying to push directly to the default branch.

The file ends with a checks section. Before considering a task complete the AI must run the publication's lint script, which validates front matter and checks for banned phrases. It must verify every cited source by querying the appropriate MCP server. It must produce a summary of the draft in the pull request body, written for the reviewing editor. It must include a confidence note where the source material is thin or contested.

Allowed MCP servers for editorial drafting

This is where the editorial scenario diverges most clearly from the software scenario. The AI in an editorial context needs structured access to authoritative source material, and it must not be allowed to fabricate it. MCP servers are the right tool because they expose a typed interface that the AI can call by name, and the publication controls which servers are connected and what they expose.

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

• A wire-service MCP server, connected to the publication's subscribed news wire. The server exposes search by topic, by region, and by time window, and fetch by wire-item identifier. The AI is instructed to cite the wire item and the timestamp on any factual claim drawn from it.
• An archive MCP server, scoped to the publication's own past pieces. The server exposes search across the archive so that the AI can find prior reporting on the same topic and cite it for context.
• A style-guide MCP server, scoped to the `style-guide` directory in the repository. The server exposes structured lookups for terms, conventions, and ruled-on edge cases. The AI consults it before making any house-style decision.
• A press-release MCP server, connected to the publication's vetted intake feed of press materials. The server exposes search and fetch, and tags every item with the issuing organisation. The AI is instructed never to treat a press release as independent reporting.
• A filesystem MCP server, scoped to the working directory of the repository. This is the same MCP recommended in the software scenario.

The publication explicitly does not connect MCP servers that the AI could use to bypass the editorial model. There is no MCP server that can fetch arbitrary URLs from the open internet, because the single biggest risk in AI-assisted editorial work is the AI citing a blog post or a forum thread as if it were a verified source. There is no MCP server connected to the CMS itself, since publication is a human decision. There is no MCP server connected to social media, because social posts are not sources.

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. The credentials of the wire-service server and the press-release server live in environment variables on the worker, separate from any other secret. The publication rotates these credentials on the same schedule as the GitHub PAT.

Skills for editorial drafting

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

A `cite-source` skill describes when and how to cite a wire item, a press release, an archive piece, or a publicly available statement, and explicitly forbids citing anything that has not been retrieved through one of the allowed MCP servers. The skill names the publication's preferred citation format and gives examples.

A `draft-news` skill describes the structure of a routine news brief in the publication's house style, including lede, second paragraph context, supporting paragraphs, and a clean close. The skill instructs the AI to lean on the wire-service MCP and the press-release MCP for facts, and to flag any claim it cannot verify.

A `draft-feature` skill describes the longer-form structure for a feature, including the cold open, the nut graph, the reported sections, and the close. The skill instructs the AI to treat a feature draft as a scaffold for the writer's reporting, not as a finished piece, and to mark every passage that requires a reporter's confirmation.

A `headline-and-dek` skill describes the publication's headline conventions, the maximum length, the prohibition on clickbait, and the standard relationship between headline and dek. The skill produces several variants for the editor to choose from.

A `self-review-editorial` skill mirrors the software self-review skill but adapted for editorial artefacts. It instructs the AI to re-read the draft as a sceptical editor, to check that every factual claim is backed by a citation, to verify that no banned phrases have slipped in, and to check that the draft length matches the brief.

Iterating with the AI through review comments

The section editor 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 editorial scenario, and it is the natural way to push corrections back to the AI without rewriting the draft 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. An editor who wants the AI to revise something writes a review comment on the relevant line or paragraph, exactly as a copy chief would write feedback for a staff writer. The comment can ask for a tighter lede, a different ending, a missing piece of context, a softer or harsher tone, an additional source, a quote moved up, or any other concrete change. The comment is the instruction.

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 editor sees the response in the same thread on GitHub and decides whether to push back, accept the decline, or take over manually.

The six-hour minimum delay exists deliberately so that quick clarifications between editors do not trigger AI responses. If an editor leaves multiple comments at once, the AI handles each thread independently in its next iteration cycle. A thread becomes inactive once the bot has replied with `done`, so a follow-up comment after `done` is needed to re-open the conversation. A thread that the editor 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 editor 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 piece into the CMS or discard the branch.

If at any point the editor wants to take the pull request out of the AI's view, they remove the `[AI GENERATED]` prefix from the title.

Security and confidentiality

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

The worker runs on a dedicated, isolated machine with no access to source-protection material outside the active brief. Embargoed stories are not handed to the AI until the embargo lifts. The worker machine has no email client, no CMS credentials, and no access to the publication's billing or subscriber systems. The AI sees only the repository it is working on and the MCP servers explicitly listed in the configuration.

The AI does not modify Jira directly. The section editor's intake decisions are the desk's primary safety gate, and the worker only ever sees tasks that have been approved into the source column. Comments on Jira issues, marking a task as Incomplete, and transitioning to "Ready for pickup" all go through the ShipifyAI backend, which gives the desk a single audit trail of every state change.

The AI cannot push to the default branch. The AI's working artefact is always a feature branch with a pull request, and the editor takes the draft from there into the CMS 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. The defence is layered.

In addition to the standard four pillars, the publication 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 exfiltrate draft text and it cannot fetch arbitrary URLs that pretend to be sources. The publication 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 vendor sends a press release announcing a new product, and the news editor decides it warrants a short brief. The intake editor creates a Jira issue titled "200-word news brief on Acme's new product launch", attaches the press release reference, notes the target slug, and lands it in Backlog. The news editor reviews the brief, judges it appropriate for AI drafting, and moves it to "Ready for AI drafting". The minimum wait time of a few hours ticks down.

Later that morning the worker picks up the task. Claude reads `CLAUDE.md`, loads the news drafting skills, retrieves the press release through the press-release MCP, retrieves any prior coverage of Acme from the archive MCP, and produces a feature branch with a 200-word brief that follows the house news structure. Each factual claim is annotated with its source. The AI then runs the lint script, runs the cite-source skill to verify every citation, runs the self-review-editorial skill, and opens a pull request titled "[AI GENERATED] News brief: Acme product launch". The pull request body summarises the brief in plain language, lists every citation, and notes the press release timestamp. The Slack bot posts the link to `#editorial-ai` and the Jira task moves to "Ready for pickup".

The news editor opens the pull request, reads the diff, decides the lede is too soft, and leaves a review comment asking for a sharper opening. Six hours later the worker addresses the thread, replies `done [AI GENERATED]`, and pushes the revised lede to the same branch. The editor reads the revision, accepts it, takes the text into the CMS for layout, and publishes. The pull request is closed without merging once the brief has shipped.

The Jira task moves to Done the moment the editor has used the draft, regardless of whether the underlying pull request was merged or simply closed. The Slack channel announces the pickup. Nothing on the default branch needed to change for the brief to be published.

At every step a human controls the gate. The intake editor decides what the AI works on. The reviewing section editor decides what part of the draft is good enough to publish. The AI does the mechanical drafting and source verification, which is exactly the kind of work that benefits from automation, while the editorial judgement remains entirely with the desk.

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 an editor 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.