kurtrolland.com — project instructions

This repo is Kurt Rolland’s personal blog: a Jekyll site published by GitHub Pages at https://kurtrolland.com. Pushing to main publishes; GitHub rebuilds the site in about a minute. There is no build step to run locally.

Who is writing

Kurt is a CTO and agentic architect (enterprise AI, Microsoft 365, agentic systems; Microsoft MVP) and an independent researcher writing on AI and the ethic of non-power, with Jacques Ellul as a primary source. The research is on a publication track (articles, possibly a book). Never describe Kurt as a doctoral student or claim a University of Aberdeen affiliation. The blog is where those two lives meet. Readers mostly arrive from LinkedIn: practitioners, technology leaders, and some theologians and ethicists.

Voice

Plain language over jargon, always. Kurt writes in the first person, concretely, and would rather have a conversation than an audience. He explains a technical or theological idea by showing why it matters to someone building or buying these systems, not by defining terms. Avoid hype, avoid hand-wringing, and avoid the LinkedIn-thought-leader register (no “Here’s the thing.”, no one-sentence paragraphs stacked for effect, no closing “Agree?”). When a post draws on the dissertation, keep the academic scaffolding out: no literature review, minimal citations, footnote-free unless a quotation needs a source.

Two kinds of post. Technical posts are assertion-led: the claim first, then the reasons and the real case behind it, and every technical assertion carries a citation as an inline link (docs, spec, paper, changelog). Inline links, not footnotes. Academic posts (the non-power research) also use the research project’s own writing skill and voice profile when that folder (PhD - AI and the Ethic of Non-Power) is connected; see draft-post and edit-post. The research skill never overrides the form rules above.

How the site is laid out

  • _drafts/ — work in progress. Jekyll never publishes this folder. Drafts have no date in the filename: _drafts/some-slug.md.
  • _posts/ — published posts, named YYYY-MM-DD-slug.md. The date in the filename is the publish date.
  • about.md, index.md — pages. _config.yml — site settings; change rarely.
  • assets/ — images. assets/og-image.png is the default LinkedIn preview card; a post can override it with image: in its front matter.
  • .claude/skills/ — the publishing workflow (see below).

Front matter every post needs

---
layout: post
title: "Title in sentence case"
excerpt: "One or two sentences. This is what LinkedIn and the post list show."
---

date: is optional (the filename date is used). Add image: /assets/<file>.png only for a post-specific preview image. Keep titles under ~60 characters so they don’t truncate in preview cards.

The publishing workflow

Four skills, meant to run in order but usable alone:

  1. draft-post — turn source material (notes, a transcript, a dissertation excerpt, a conversation) into a draft in _drafts/.
  2. edit-post — editorial pass on a draft: structure, plain language, title, excerpt.
  3. publish-post — move the draft to _posts/ with today’s date, validate, commit, push, confirm it’s live.
  4. linkedin-teaser — write the LinkedIn post that links to the article.

Publishing is a real-world action (the post goes public and LinkedIn readers see it). Always show Kurt the final file and get an explicit yes before committing to main.

Conventions

  • Post length varies with the material; don’t pad and don’t truncate a real argument to hit a number.
  • Slugs: lowercase, hyphens, 3–6 words, no stop-words if it reads fine without them.
  • Commit messages: post: <title> for new posts, edit: <slug> — <what changed> for edits, site: <what> for config/theme changes.
  • Never edit CNAME or the url: line in _config.yml; those tie the site to its domain.