How this site works¶
What GitHub, Claude and Cloudflare each do, and the routine that keeps 106 source documents published, current and in one place.
Before this site existed, our documentation lived in three places. A set of standalone web pages covered the MRP Engine and other parts of Pulse Dashboard. The leahyconsulting.com website carried the product descriptions and support material. And 106 white papers, technical notes, fact sheets, wall charts and workbooks, written over more than 20 years, sat in folders as Word files, PDFs and Visio drawings and went out one at a time by email. Every one of those pieces is accurate where it sits. Keep one explanation in three places, though, and a single change to a screen leaves two of them behind. A reader then has no way to tell which copy is current.
Today all of it is one site, and every page carries the full history of every change made to it. Three systems keep it that way. You don't need to have used any of them before; this page covers the basics.
Where to start opens this section: which of these pages you need, and how long each takes. If you are joining the documentation work and want the setup rather than the explanation, Getting started with Claude Code is the step-by-step: the accounts to request, connecting Claude to GitHub, and a first change through to the published site. What lives where covers the part of that setup people ask about most: which pieces sit on your computer, which sit on your Claude account, and where you go to take access away.
How the site was built¶
The site came together in three phases, each folding one of the old documentation homes into this one:
The first phase merged what already existed on the web. Pulse Dashboard had separate documentation sites for the MRP Engine, the MRP Orders Drilldown, the Dashboard Client and the release notes, each standing alone. They were combined into one site with a single navigation tree and one search index.
The second phase brought in leahyconsulting.com. The site was crawled link by link, collecting every page reachable through its own navigation, and the relevant material was adapted here: the product sections and the first knowledge-base guides, each citing the page it came from.
The third phase integrated the 106 source documents, covered in the archive section later on this page: read, classified, rewritten and archived, with the document map recording what became of each.
None of it was automatic. Each phase ran as a series of working sessions in Claude Code: Claude drafted, we reviewed and corrected by hand, and the structure was adjusted until it read right.
The system at a glance¶
GitHubStores everything
Every page, and all 106 source documents, live in one shared folder, the repository. GitHub keeps every version of every file. If a file is in the repository, it is the current one.
ClaudeWrites and propagates
Claude is the AI assistant made by Anthropic. Describe a change in plain English, or make one by hand, and it drafts the edits in our house style, on every page the change touches.
CloudflarePublishes the site
Cloudflare watches the repository and turns every accepted change into the live site at www.leahydocumentation.com, worldwide, in about a minute. Publishing is not a step anyone performs.
A reviewed change follows the same six steps, and the lanes show who does each one:
The rest of this page covers each system, how one fact reaches every page that carries it, the archive behind the site, the day-to-day routine and the Ask the docs assistant.
GitHub¶
Git is a version control system: it tracks every change made to a set of files, along with who made the change, when and why. GitHub is the website that hosts our Git repository, the shared folder holding every page of this site. The whole team works against the same copy, in a browser, and there is nothing to install.
The repository¶
Every page of this site is a file in the repository, including this one, written in Markdown, a plain-text formatting convention. There are no Word files to hunt down and no argument about which folder holds the current version.
The repository is also the official home of the source documents themselves. The 106 originals in the archive live in it, beside the pages written from them, so a fact sheet and the page it became share one home and one history. There is one repository for everything.
Commits¶
A commit is a saved change: one edit, or a batch of related edits, recorded with its author, the date and a one-line message saying what changed and why. Commits are permanent. Git never overwrites; it adds a new commit on top and keeps every earlier version. Delete a paragraph today and you can still read it, compare it or restore it years from now.
Branches¶
A branch is a working copy of the whole site inside the repository. The main branch, main, is what Cloudflare publishes. To change anything, branch off. Git gives you a private copy to edit while main stays put and readers keep seeing the current pages. Branches are also how several people work at once, and the working-together section below shows how.
Pull requests¶
When the work on a branch is ready, you open a pull request. You are asking for your branch's changes to be pulled into main. GitHub shows the two versions in a side-by-side comparison, with every changed line marked, so the reviewer sees exactly what would change before anything changes. The reviewer can comment, ask for revisions or approve. Approving and merging the pull request folds the branch into main, and Cloudflare starts publishing.
Pull requests are a habit, not a lock. Nothing in the tools forces one: anyone with access can commit straight to main, and Cloudflare publishes it a minute later. For a typo or an obviously safe fix that can be the right call, and the history still records the commit and can still revert it. The habit earns its keep on everything else: anything a customer will read, anything touching several pages, anything worth a second reader.
Working together¶
Developers, consultants and sales reps will all be editing this documentation, often in the same week. Five habits keep that safe:
- Branch from the current main, never from an old branch, so you are editing the site as it stands today.
- Open one branch per change, small enough to review in a few minutes.
- Use a branch and a pull request by default; commit straight to main only for a small, obviously safe fix.
- Have someone other than the author review and merge anything that goes through a pull request.
- Merge within a few days. A branch that sits for a month is editing last month's site.
Git enforces the thing a shared folder cannot: one person's work cannot be undone by another person's save. Two branches that change different pages, or different parts of the same page, merge cleanly, and both changes land. When two branches change the same lines, Git refuses to pick a winner. The second merge stops, shows both versions and waits for a person to decide. In a shared folder the last save wins and nobody notices. Here the last save never wins silently, and because every merge is a commit, even a bad decision can be reverted.
A release week makes a concrete example. Pulse Dashboard 5.65 ships, and three things happen at once:
- A developer branches to write the 5.65 release notes and add the new report to the Inventory Optimization module page.
- A consultant, on a support call, spots a wrong menu path in the physical-inventory guide and branches to correct it.
- A sales rep branches to reword the introduction of the Inventory Optimization page to match the newest fact sheet.
Each branch merges through its own reviewed pull request. The consultant's branch was in flight while both of the others merged, and it landed cleanly because it changed a different page. The sales rep branched after the developer's merge, so the rewording started from the page that already carried the new report, and the finished page holds both edits.
When branches collide¶
Editing different pages never conflicts. Conflicts come from the files every change shares, and the clearest case on this site is the table of contents: the sidebar navigation is one list in one file, and adding a page means adding a line to that list. When two branches each add a page, both edit the same list within a few lines of each other, and the second merge stops. The front page's link lists and the section index pages behave the same way.
A stopped merge pauses the work, and nothing has gone wrong. Both branches keep their own versions, nothing is lost and nothing publishes. The conflicted file shows both edits marked, and finishing the merge means deciding what survives. For two added pages the answer is both entries, in order.
Claude resolves this kind of conflict safely. It merges the latest main into the branch, keeps both additions, rebuilds the site to confirm the navigation still works, and pushes the result, which shows up in the pull request for the reviewer like any other change. That is safe because both edits are additions and each pull request states what it set out to add.
What Claude will not settle on its own is two people rewriting the same sentence in different directions. That is a disagreement about content rather than a mechanical collision. Claude lays out both versions, and a person decides.
Not every change carries the same risk. Additions sit at the safe end: a new page, a new guide, a new entry in a list. Two additions rarely touch the same lines, and when they do, the fix is to keep both. Edits deserve more caution. Rewording can collide with someone else's rewording of the same passage. Restructuring moves text, and Git tracks lines rather than intent, so a section moved on one branch can leave a colleague's fix on another branch aimed at text that is no longer where it was. Screenshots and other image files cannot be merged at all. There is no line-by-line comparison of two images, so when two branches update the same screenshot, Git can only ask which one to keep.
The habit that keeps risky edits safe is sequencing. Commit and merge them in small batches, merge promptly and say what you are working on. Plan any major restructuring before it starts: give it a branch of its own with no content edits mixed in, keep that branch short-lived and hold other edits to the affected sections until it merges.
Cloudflare¶
Cloudflare operates data centers around the world and keeps a copy of the site in each of them, so a page loads from a data center near the reader rather than from one server in one city. We don't run a web server at all, so there is nothing to patch or restore.
Cloudflare Pages watches our GitHub repository. Every time a pull request merges into main, Cloudflare picks up the new files and publishes them worldwide in about a minute. No one uploads anything. If a change ever has to come back out, we revert the commit in GitHub and Cloudflare republishes the site as it stood before.
Cloudflare also runs the two services behind the Ask the docs assistant: AI Search, which re-crawls the published site and keeps its index current, and the function that answers a question from it. Both are covered in the Ask the docs section below. The search box in the site header is a separate thing, built into the pages themselves, and Using this site covers how to drive it.
Claude¶
Claude is the AI assistant that does the file work. It can read every page in the repository at once, and it writes to rules we set.
Those rules are the Leahy prose style guide, a document we wrote that lives in the repository alongside the pages. It pins down the house voice: professional and cordial, concrete in place of promotional. It also pins down the mechanics: how to carry the marks on Macola® and PULSE names, how to write UI paths in bold with arrows, how to quote status codes verbatim and which AI-sounding habits to strip out. Claude loads the guide every time it writes or edits a page a customer will read. The guide is a file in the repository, versioned like every other file, so improving it once improves everything Claude writes from then on.
Claude drafts the site's pages and the individual handouts we give customers, and it is not the only editor. Any file in the repository can be edited by hand, in the browser, on a branch like any other change. After a hand edit, tell Claude what changed and it carries the edit through to every related page, the same way it propagates a software change.
A request looks like this:
"The Supply Chain module is called Inventory Optimization now. Update the pages that still use the old name, and record the rename so a customer quoted for Supply Chain can still find it."
Claude finds the affected pages, drafts the edits in the house style and opens the pull request, with the side-by-side comparison ready for the reviewer. You never touch a file. Claude does the mechanical work, and people still decide what should change and whether the draft reads right.
One fact, many pages¶
The same fact often lives in several places. A Pulse Dashboard module's description appears on the module page, in the report catalog and on the product overview; a G/L posting rule appears in a wall chart and in two guides. In the old Word-file library those copies drifted apart, because updating one file did nothing to the others.
The repository keeps the copies, since a reader needs the fact on the page in front of them. What changes is the upkeep. One request updates every copy at once, and the module rename above is a real case:
The starting point doesn't matter. Ask for a change to a specific page, tell Claude what changed in the software, or edit a file by hand and have Claude bring the related pages into line. Each route ends the same way: one reviewed change that updates every affected page.
The archive and the document map¶
The source document library holds the original material: the 106 documents the site was built from, archived unedited under their original filenames. The published pages are rewrites. When someone asks where a statement came from, the original is on file.
The document map records what became of every document. Claude read and classified each one, and the whole library breaks down like this:
Adding a new document¶
The library isn't finished; more documents are waiting to be added. Hand one to Claude and it checks the file against the whole library before anything publishes:
For new material, Claude files the original under a descriptive name and decides which page it should become or extend. It rewrites the content in the house style: grammar corrected, formatting rebuilt, screenshots re-annotated. The decision goes into the document map.
The map works in the other direction too. Every page names the document it was adapted from, and every editorial change is recorded rather than left silent: a corrected step, a dropped version list, a merged pair of editions.
The day-to-day workflow¶
The routine is short, and all of it runs in a browser: GitHub, the published site and the conversation with Claude.
| When | What to do |
|---|---|
| You spot a typo or an outdated sentence | Tell Claude, or save it for the next batch of edits |
| The software changes | Tell Claude what changed, then review the pull request it opens |
| You have a document that isn't in the library yet | Hand the document to Claude, which checks for duplicates, files it and proposes the page it should become |
| A customer asks something the site doesn't answer | Tell Claude what the customer needed, and read the page it drafts |
| You'd rather make the edit yourself | Edit the file in the browser on a branch, then ask Claude to carry the change through the related pages |
| You want to know what changed recently | Open the repository's history, which lists every merge with its author, date and description |
Three habits keep the repository clean:
- Prefer a branch and a pull request. A small, obviously safe fix can go straight to main; everything else earns a second reader, so the published site stays the sum of reviewed changes.
- Open one branch per change. A branch that fixes one thing is easy to review and easy to revert; a branch that fixes nine unrelated things is hard to do either with.
- Review for truth and voice. Formatting, links and style are Claude's job to get right before the pull request opens, so the reviewer's two questions are whether it is true and whether it reads like us.
Because every change is a commit, you can compare any page with an earlier version and revert any commit, including one merged months ago.
Ask the docs¶
The Ask the docs assistant answers a question typed in plain English, and the answer comes back with links to the pages it was drawn from:
The widget is a file in the repository, the index and the answering function run on Cloudflare, and Claude writes the reply.
Using this site covers driving it: which questions suit it better than the search box, how to resize or pop out the panel, and what it cannot answer.
Support & contact¶
Our team is glad to walk through any of this: how to phrase a request to Claude, how to review a pull request or how to find a page's history.
- Consulting & Macola® services — (513) 723-8094 · [email protected]
- PULSE software support — (513) 723-8095 · [email protected]
- Sales & product questions — (513) 723-8091 · [email protected]