The Blog Was a Demo, Not a Brand

The blog existed for 6 months. The home page rendered fine. The about page said this is a Jekyll theme demo. The posts were placeholder text.

The reason: I built the blog as a demo, not as a brand. The theme was elegant. The content was empty. I never wired the blog to the vault. I never wired the blog to the resume. I never wrote a publish script. The blog was a folder on a server. The vault was a folder on my laptop. The two folders did not know about each other.

The asymmetry was embarrassing. The vault had 126 markdown files, 10 strategy pages, 30 concept pages, 8 entity pages, 1 corpus analysis. The blog had 1 page that said demo. The brain was full. The mouth was empty.

The vault

Markdown files

10 strategy pages, 30 concept pages, 8 entity pages, 1 corpus analysis. The brain was full. The mouth was empty.

The blog

1 demo page

Said this is a Jekyll theme demo. The asymmetry was embarrassing. The fix is the publish layer.

The fix is the publish layer. The publish layer is a script that takes a vault draft, transforms it for Jekyll, commits it, and pushes to GitHub Pages. One command. One URL. One published post.


CLI Mode, Broken Ruby, One Terminal

The session that produced this rebuild was a CLI session.

No GUI

CLI only

Could not run Obsidian. Could not preview the site. Could not click publish in a CMS. The publish step had to be one bash command.

No local Jekyll build

Broken Ruby

System Ruby was 2.6. Gemfile.lock required bundler 4.0.12. bundle exec jekyll build failed before it started.

No GUI screenshots

Headless failed

screencapture and chrome --headless both failed. The publish step had to work without them.

One shell

Testable in terminal

The script takes a file path. Produces a live URL. The whole thing is testable in a terminal.


The 4-File Pipeline

Vault → queue → script → live URL. That is the whole thing.

content/queue/<draft>.md       (vault side, status: ready-to-publish)
scripts/parse-frontmatter.py  (YAML → bash, helper)
scripts/publish-blog.sh       (the pipeline: transform + copy + commit + push)
~/ShayanSpiel.github.io/      (GH Pages side, _posts/, auto-builds on push)
01

User writes a draft In content/queue/<date>-<slug>.md. The draft has status: ready-to-publish in the frontmatter.

02

User runs one command bash scripts/publish-blog.sh <draft-path> —yes. The script takes over from here.

03

Script transforms frontmatter Adds Jekyll fields (layout, date, author). Drops vault fields (status, standalone_test, pillar). Whitelist, not blacklist. Stable contract.

04

Script copies screenshots Scans body for image references. Resolves paths. Copies to assets/uploads/<date>-<slug>/. Rewrites paths in the post.

05

Script commits and pushes Stages the new post and uploads. Commits with a meaningful message. Pushes to origin main. GitHub Pages rebuilds. The post is live in ~30 seconds.

The whole flow is one command. The user runs the command, walks away, and the post is live. The script is the publish layer.


The Result

The rebuild shipped 4 deliverables in 4 hours. The brand hierarchy is now consistent.

1

Home page rewrite

index.md now has a hero, latest 5 posts, currently shipping, and a what this site is section. No more demo content.

1

About page rewrite

about.md now has the personal-brand story arc, the 5 offers with detail, and contact info. No more demo.

2

Pillar posts

This post + the prior post on the second-brain architecture. Both published the same night.

15

Screenshots

7 for the first pillar, 8 for this pillar. All 1600x1600 PNGs. All in assets/uploads/.

4h

Total time

From empty demo to brand blog. No GUI. No local Jekyll build. One command per post.

30s

Time to live

From git push to live URL. GitHub Pages rebuilds. The post is public.

The brand hierarchy is now consistent. The blog about-page mirrors the wiki shayanspiel page. Every surface points to the same person.


Publishing Is the Part No One Teaches

Most blog advice is about writing. Most content-engine advice is about drafting. Nobody talks about the publish step.

The publish step is the layer between I have a draft and the draft is live. The publish step is the friction. The publish step is the part that makes people not post. The fix is a script. The script takes a file path. The script does the rest.

Without script

10 minutes of clicking

Login to the CMS. Format the frontmatter. Copy screenshots to the right folder. Update the index. Commit. Push. Repeat. 10 minutes. Every. Single. Time.

With script

One command

The script reads the draft. Transforms the frontmatter. Copies the screenshots. Stages the commit. Pushes. The post is live in 30 seconds. The user walks away.

You can not post if you can not publish. You can not publish if the publish step is 10 minutes of clicking. The 10 minutes is the friction. The friction is the reason you do not post. The script is the friction-killer.


If You Have a Vault, Build the Script

The script is 4 hours. The script is the publish layer of Session-as-Content Infrastructure.

4

Files

The whole pipeline is 4 files. The vault draft, the YAML helper, the publish script, the GH Pages destination. Nothing else.

4h

Build time

The script took 4 hours to write. It saves 10 minutes per post. Break-even after 24 posts. The script is the leverage.

2

Posts in 1 night

First night using the script: 2 posts shipped. The pipeline works end-to-end. The vault is now wired to the live site.


You can not post if you can not publish. The script is the friction-killer.

4 files. 4 hours. One command. The vault is now wired to the blog. Clone the Spiel OS repo. Build the publish layer. Ship the same night.

Clone the SpielOS repo