Writing a family book chapter by chapter with ShipifyAI

ShipifyAI was designed with software teams and other professional organisations in mind, but the workflow at its heart is just as useful for a tiny project run by a family. A multigenerational memoir, a family chronicle, or a privately printed book of recollections is the kind of long-form work where versioning preserves drafts, where a chapter board keeps the project moving, and where an AI assistant can produce careful first drafts from interviews and source materials while the family keeps editorial judgement firmly in human hands. The platform's enterprise patterns translate cleanly to a small, personal setting once the tone of the configuration is adjusted.

This article walks through the setup of ShipifyAI for a fictional family writing a memoir of their grandparents' generation, chapter by chapter, over the course of a year and a half. It covers how to structure the chapter board, the working repository, and the notification channel, how to write a `CLAUDE.md` that captures the family's voice, and which MCP servers to allow so that the AI can draft from interviews and verify facts without inventing details.

The scenario

The family consists of a retired grandparent who is the project's initiator and senior voice, an adult child who is the primary writer and editor, the adult child's partner who has interviewed several elderly relatives and recorded the conversations, and a teenage grandchild who has been scanning family photographs, letters, and public records. The goal is a twelve-chapter memoir covering the grandparents' early lives, wartime years, post-war migration, family life, professional careers, and reflections in retirement. The book is intended for private printing for the extended family, with no commercial publication. Source material is a growing collection of interview transcripts, scanned photographs, family letters, and verified public records such as census entries and civil registries. The primary writer wants the AI to produce careful first drafts of each chapter, drawing only from the actual source material, so that the family can spend their time on the parts that need human judgement and memory.

ShipifyAI's role is to take a chapter assignment from the board, hand it to Claude with the family's house rules and the relevant transcripts, produce a draft chapter committed to the repository, open a pull request for the writer to read and comment on, and quietly announce that the draft is ready. Nothing in the family's book is written without the writer reviewing the AI's work and shaping it into the finished chapter.

Setting up the document repository

The family uses a private GitHub repository as the project's home. Access is restricted to the four family members involved in the project. The repository is structured to mirror the book itself. There is a `chapters` directory with one Markdown file per chapter, named for clarity such as `01-roots.md`, `02-childhood.md`, and so on through `12-reflections.md`. There is a `research` directory with subfolders for `interviews`, `letters`, `photos`, and `records`. Interview transcripts are kept as Markdown with timestamps and speaker labels. Scanned letters and photos live in `assets`, with descriptive filenames and a short Markdown caption file next to each. An `outline.md` at the repository root captures the overall structure of the book, and a `timeline.md` keeps a running family chronology that every chapter has to respect.

The ShipifyAI CLI writes its draft chapters 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 revisions can be reviewed the same way code is reviewed. What the family does with those Markdown chapters once they are reviewed is up to the family, and outside ShipifyAI's scope. The fictional family in this article wires up a CI pipeline that renders the chapters into a printable PDF using their chosen book template, so anyone can see what the book is starting to look like at any point in the project; another family might prefer to take the text into a different word processor, into InDesign, or straight into a print-on-demand service, and none of that would change the way ShipifyAI operates.

A meaningful difference from the law firm and editorial scenarios is what the default branch represents. In this project the default branch is the book. Each finished chapter merges to the default branch and becomes part of the canonical manuscript. A merge is not the exception here; it is the goal. The AI still produces its drafts on feature branches, and a pull request is still the place where the writer reads the draft and asks for changes, but the destination of every successful chapter is the default branch. The repository is the manuscript, and the manuscript is what the family is building.

This shifts how branch protection is configured. The default branch requires a pull request and at least one approval from the primary writer before merging, and required status checks include a lint that validates the chapter front matter and a self-review pass on citations to source material. The writer typically reviews a draft over a few days, leaves review comments where the tone is off or the facts need adjusting, lets the AI revise, and only then merges the chapter when they are happy with it. A merged chapter is the canonical record of what the family chose to remember in that part of the story.

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 chapter board

The family uses Jira because the primary writer has used it at work and prefers a familiar tool. A simpler board such as GitHub Projects or a kanban app would work just as well. Each issue represents a chapter, a major subsection of a chapter, or a small drafting task such as weaving a particular interview transcript into an existing draft.

The board has the four columns that match the ShipifyAI model. The source column, named "Ready for AI drafting", holds chapters the family has agreed are ready to draft, with the interview transcripts, letters, and records identified in the issue description. The In Progress column holds the chapter the AI is currently drafting. The In Review column, renamed "Ready to read", holds chapters where the AI has produced a draft on a feature branch and a pull request has been opened. From this column the primary writer takes over for review, revision, and eventual merge. The Incomplete column holds tasks the AI returned because the source material was thin or because the chapter requires a memory only a family member can supply.

A task moves out of "Ready to read" when the primary writer has finished revising the chapter. In this project, finishing usually means merging the pull request into the default branch, because the book itself lives on that branch. Occasionally a draft turns out to be the wrong starting point, in which case the writer closes the branch without merging and lands a more specific task in Backlog.

The board has a fifth column, "Backlog", which is not visible to the AI. The primary writer lands every idea, draft chapter request, and source-material gathering task there. The writer decides when a chapter is sufficiently scoped to hand to the AI and only then moves it to "Ready for AI drafting". This intake step is the family's safety gate. Anything sensitive that involves a living relative who has not given clear permission stays out of the AI column entirely.

The minimum wait time on the project is set loosely. A few hours is enough. The point is to give the writer time to change their mind about a chapter assignment after sleeping on it. There is no hurry, and the family is the only stakeholder.

Setting up the notification channel

The family uses a private Slack workspace with a single channel, `#family-book`, configured as the project's notification channel in ShipifyAI. The same effect could be achieved with an email notifier or a quiet shared chat in any messenger; Slack is just an example. Notifications it receives include the announcement that a draft is ready to read, with a link to the pull request, and the announcement that the AI was unable to complete a chapter and the reason why. The link in the notification is the writer'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 `#family-book` and to no other channel.

Writing a CLAUDE.md for the book

The `CLAUDE.md` file is where the family's voice and house rules are taught to the AI. For a book project it is even more important than in a professional scenario, because the AI's output has to sound consistent across chapters that may be written months apart.

The file opens with a project overview that explains what the book is, who its readers are, who the central figures are, and the timeline and geography it covers. It explains the family's primary languages, the regions where the story takes place, and the way the family wants its grandparents' generation to be remembered. The AI then knows that proper names refer to specific real people, that places are real, and that the narrative voice should match what the family has decided.

The file describes the structure of the repository, naming the chapters directory, the research directory, the outline, and the timeline. It tells the AI that every claim about a person, a date, or a place must come from the research directory or from a record the family has gathered, and that an interview transcript is the authoritative voice of the relative who gave the interview.

The file describes the family's chosen voice. This includes the narrative perspective for each chapter, the tense, the pacing, and the chapter structure. The family has decided on a cold open that drops the reader into a scene, an exposition section that gives historical context, a longer scene built from interview material, and a reflection that ties the chapter to the next. Terminology is settled in the file: how the grandparents are referred to, how their hometown is named, how wartime events are described.

The file also lists what the AI must never do. It must never invent dialogue. It must never embellish a memory beyond what an interview transcript or a letter supports. It must never claim a date or place without a citation to a record. It must never use the names or addresses of living minors. It must never include medical details or other sensitive personal information that the family has chosen not to publish. 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 chapter complete the AI must run a lint script that validates chapter front matter, run the cite-source-family skill to verify every cited record exists, and run the self-review-memoir skill to look for invented details. It must produce a summary of the chapter in the pull request body, written for the primary writer, listing which transcripts and records were used.

Allowed MCP servers for memoir drafting

This is where the family scenario diverges from the other scenarios. The AI in a memoir context needs structured access to the family's own 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 family controls which servers are connected and what they expose.

The family enables a small, narrow set of MCP servers on the worker machine, configured in `~/.claude/mcp.json`.

- A transcripts MCP server, scoped to the `research/interviews` directory of the repository. The server exposes search across the interview transcripts by speaker, by date, by topic, and by keyword, and fetch by transcript identifier. The AI is instructed to cite the interview and the timestamp on any factual claim drawn from it.

- A records MCP server, connected to an official public-records source such as the national civil registry's open data interface. The server exposes lookup of birth, marriage, death, census, and migration records by name and date range. The AI uses it to verify dates, places, and family relationships that the writer can corroborate.

- A timeline MCP server, scoped to the `timeline.md` file. The server exposes structured lookups of the running chronology so that the AI cannot place an event in the wrong year.

- A filesystem MCP server, scoped to the working directory of the repository. This is the same MCP recommended in the software scenario.

The family explicitly does not connect MCP servers that could leak family information. There is no MCP server connected to a commercial genealogy service, because uploading family identifiers to such a service is exactly the kind of personal exposure the family wants to avoid. There is no MCP server that can fetch arbitrary URLs from the open internet, because that would let the AI cite a stranger's blog post as if it were a record. There is no MCP server connected to social media or to cloud photo libraries.

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.

Skills for memoir drafting

The family ships its own small skill pack inside `.claude/skills`, tailored to the project.

A `draft-chapter` skill describes the family's chosen chapter structure and instructs the AI to follow the outline and the timeline as the spine of the draft. The skill instructs the AI to read every interview transcript referenced in the chapter brief before drafting, and to maintain the voice established in the chapters that have already been merged.

A `weave-interview` skill describes how to integrate a passage from an interview transcript into narrative prose without losing the relative's voice. The skill enforces strict rules about quotation: a direct quote must match the transcript exactly, attributed to the speaker with the date of the interview.

A `verify-date` skill describes how to verify any date, place, or family relationship through the records MCP before writing it into a chapter. The skill instructs the AI to flag a claim that cannot be verified and to leave it as a placeholder for the writer to confirm.

A `cite-source-family` skill describes how to cite an interview, a letter, a photograph caption, or a public record in a footnote-style note kept at the end of the chapter draft. The skill names the family's preferred citation format and gives examples.

A `self-review-memoir` skill mirrors the software self-review skill but adapted for memoir. It instructs the AI to re-read the chapter as a sceptical family member, to check that every passage about a real person is supported by an interview or a record, to verify that no detail about a living minor has been included, and to confirm that the chapter respects the voice and tense set in the prior chapters.

Iterating with the AI through review comments

The primary writer 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 memoir scenario, and it is the natural way to push corrections back to the AI without rewriting whole passages by hand. It is also the place where another family member who interviewed a relative can leave a comment correcting a tone, a nuance, or a small fact that only they would know.

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. The writer or another family member writes a review comment on the relevant line or paragraph, exactly as a co-author would write feedback. The comment can ask for a softer tone in a scene, an additional detail from a specific interview, a passage rewritten in a different tense, a date corrected, or any other concrete change.

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

The six-hour delay is set deliberately so that a quick aside in the comments does not trigger an AI response. If the writer leaves several comments at once, the AI handles each thread independently in its next iteration cycle. A thread that the writer resolves manually is skipped by the AI entirely.

This loop is what makes chapter drafting practical. The writer does not need to rewrite the AI's draft from scratch. They can hand back specific corrections, get a revised chapter a few hours later, and then merge it into the manuscript when it is ready.

Privacy and respect

The four pillars of ShipifyAI's security model apply to this project as they do to any other, with a stronger emphasis on family privacy than on commercial confidentiality.

The worker runs on a dedicated machine. There is no email client on it, no cloud photo library, no calendar, no social media. The AI sees only the repository it is working on and the MCP servers explicitly listed in the configuration. The family is deliberate about what it puts into the repository in the first place: photographs are scrubbed of identifying metadata before scanning, transcripts are reviewed before they are committed, and any reference to a living minor's full name, address, school, or medical history is removed at intake. Sensitive material that the family wants to keep out of the book entirely never enters the repository at all.

The AI does not modify the board directly. The writer's intake decisions are the family's primary safety gate, and the worker only ever sees chapters that have been approved into the source column.

The AI cannot push to the default branch. Every change goes through a pull request and through the writer's review and merge. 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 family also 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 records MCP server. The AI cannot reach the open internet, so the project's source material cannot leave the family's controlled environment. The worker container is rotated daily, so any state accumulated during a session is gone the next morning.

A typical chapter end-to-end

Consider how a single chapter flows through this setup. The family has finished gathering interviews about the grandparents' wartime years and has agreed that chapter four is ready to draft. The writer creates a Jira issue titled "Draft chapter 4: grandfather's wartime years", lists the two relevant interview transcripts in the description, references the timeline entries for the years in question, and lands the task in Backlog. After sleeping on the scope, the writer moves it to "Ready for AI drafting". The minimum wait time of a few hours ticks down.

Later that day the worker picks up the task. Claude reads `CLAUDE.md`, loads the memoir skills, retrieves the two interview transcripts through the transcripts MCP, verifies key dates and places through the records MCP, reads the previous three chapters to model the established voice, and produces a feature branch with a draft of chapter four. The chapter follows the family's chosen structure: a cold open built from a scene in one of the transcripts, an exposition section that gives the wartime context, a longer scene woven from both interviews with direct quotations attributed to the grandfather, and a reflection that ties into the next chapter. Each citation to an interview or record is kept in a footnote at the end of the chapter.

The AI then runs the lint script, runs the cite-source-family skill to verify every citation exists, runs the self-review-memoir skill to check for invented details, and opens a pull request titled "[AI GENERATED] Draft chapter 4: grandfather's wartime years". The pull request body summarises the chapter in plain language and lists every transcript and record used. The Slack bot posts the link to `#family-book` and the Jira task moves to "Ready to read".

The writer reads the draft over a couple of evenings. They like the cold open, find one scene too soft for what their parent actually described, and notice a missing detail about a sibling that came up in a third interview the family had forgotten to reference. They leave two review comments asking for the specific changes. Six hours later the worker addresses each thread independently, retrieves the third transcript, revises the scene and adds the missing detail, replies `done [AI GENERATED]` on each thread, and pushes the revisions to the same branch. The writer reads the new version, accepts it, and merges the pull request into the default branch. Chapter four is now part of the manuscript.

The Jira task moves to Done the moment the chapter is merged. The Slack channel announces the completion. The book is one chapter longer.

At every step a human controls the gate. The writer decides what the AI works on, which transcripts feed which chapter, and what passes into the manuscript. The relatives who gave the interviews and the family member who collected them shape the AI's revisions through review comments. The AI does the careful first-pass drafting and citation work, which is exactly the part of the project that benefits from a patient assistant, while the family keeps every editorial decision.

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 the writer takes a draft or a chapter back from the AI at any point. The security article explains the four pillars in depth, including the rationale behind each layer of defence.