Back to Posts

Building an AI-Assisted Publishing Pipeline for My Knowledge Base

Cover Image for Building an AI-Assisted Publishing Pipeline for My Knowledge Base

It's been about a month and a half since my first post here.

Kelly's Notes started as a place to document my own growth, sharing what I learn through a blog and a knowledge base. Along the way, building AI into that workflow turned into a learning project of its own.

In the beginning, I focused mainly on adding knowledge base articles. But when I tried to organize the material I'd gathered into something useful for my own understanding, I kept running into notes with different formats and different points of emphasis, and it got confusing fast. That's when it hit me: this was exactly the kind of problem AI could help with. So I started using it to gather topics by category and draft articles based on those topics.

At first, I wrote each article one at a time through chat. Over time, the flow of the articles and the content of each section settled into a pattern, and I ended up with a template that worked well for me. Once I had a few articles built on that template, the next step was getting them into the CMS (Contentful), and copying and pasting each one by hand got old fast. So I had AI write a script to handle that part of the workflow:

  1. Create the article locally

  2. Run a dry run to check the diff against what's in the CMS

  3. If it looks right, push it (this creates a draft in the CMS)

  4. Preview it in the CMS web app to see how it looks published

  5. If it's good, publish it manually

That took care of getting articles into the CMS, but the content itself is what actually matters. Claude's own responses carry a line reminding me that it's an AI and can make mistakes, and that stuck with me: it would be easy to let a tool like this quietly take over decisions that are supposed to stay mine. So before automating any part of the content itself, I asked it how I should verify its own work, and built the check around one rule: the report presents evidence, never a verdict. We settled on checking four things:

  • Does the code shown actually run and produce the claimed result?

  • Do version-specific claims match the primary source?

  • Does the cited source actually support what's being cited?

  • Does the fix resolve the symptom it's supposed to fix?

I built a skill that checks those four points and writes up the results as a report. The report is dense and sticks strictly to facts. Reading it takes more effort than just reading the article itself, but I end up learning more from it, too. Whether something is actually right is still my call to make, and that's the part I don't want to hand off.

I revise the draft based on that report, then finish the article and push it to the CMS.

The full pipeline now looks like this: gather topics, draft the article, verify it, edit it, publish it in the CMS, then generate a commit message from the changes and commit. I kept the human steps, editing and publishing, in place, and used AI where it actually saved time.

You can find the skills in my GitHub repo.