patrickz.aiLet’s talk ↗

Build apps / Project lab

Build a small Markdown publishing system

Publish two readable posts with a dependable index and safe rendering.

About 60 minutesSome experienceRead free · No sign-up

Before you start

A coding agent, basic Markdown and a static hosting preview.

Why this lesson exists

This lab adapts the “Publish a No-Build Markdown Blog With GitHub Pages” project write-up into a practice build. The time is an estimated first session, not a promise to finish a production system. Use the public repository as a reference when available; the exercise can be built with original sample content.

Do the exercise

  1. Define the practice version

    Define title, slug, summary and category before writing a renderer. Use a maintained Markdown parser with an explicit policy for raw HTML.

  2. Build step 1

    Create `index.html`, `styles.css`, and a `posts` folder.

  3. Build step 2

    Write one Markdown post with simple metadata.

  4. Build step 3

    Add its path to `posts/index.json`.

  5. Build step 4

    Fetch and render the post in JavaScript.

  6. Build step 5

    Add category and featured filters.

  7. Build step 6

    Publish the folder with a GitHub Actions Pages workflow.

  8. Run the experiment

    Create two posts, navigate to each directly and test an unknown slug. Include code characters and a long heading to check rendering and overflow.

A prompt to adapt

Replace the bracketed parts with your own practice details.

Work in a disposable practice project. Explain any setup requirements before changing files. Build one small step at a time and show how I can check it.

Design a frontmatter schema for a static personal blog. It needs title, slug, date, author, summary, category, tags, reading time, cover image, featured state, and SEO description. Return validation rules and two examples.

Write a dependency-free JavaScript module that fetches a JSON post index, loads a Markdown file, parses basic frontmatter, and renders safe HTML. Clearly identify what should use a trusted Markdown parser in production.

My first-version boundary: Define title, slug, summary and category before writing a renderer. Use a maintained Markdown parser with an explicit policy for raw HTML.

Run this experiment

Create two posts, navigate to each directly and test an unknown slug. Include code characters and a long heading to check rendering and overflow.

Check your result

Use evidence from your output. A confident explanation from the AI is not enough.

  • Both posts have stable direct URLs.
  • Unknown slugs display a useful not-found page.
  • Untrusted Markdown cannot inject executable HTML.

If it isn’t working

A hand-written Markdown converter is a teaching experiment, not a safe general-purpose parser. For static trusted authoring, pre-rendering pages can simplify the runtime.

Where this came from

Public project repository ↗. The practice lesson is an adaptation, not a verbatim transcript. About the sources.

Prepared September 2026. Tools and interfaces change; use current official setup instructions. Session lengths are estimates.

KEEP GOING

Your next useful step

Browse all 59 guides ↗