patrickz
Before you start
A coding agent, basic Markdown and a static hosting preview.
Why this lesson exists
The original is a no-build Markdown blog on GitHub Pages, where each post is a plain Markdown file listed in posts/index.json. This lab keeps that simple structure and makes safe rendering and a not-found page part of the first version, before any filters.
Do the exercise
Set your boundary
Define title, slug, summary and category before writing a renderer. Use a maintained Markdown parser with an explicit policy for raw HTML.
Create the folder
Create index.html, styles.css and a posts folder.
Write two posts
Write one Markdown post with simple metadata (title, slug, summary and category), then a second one.
List them in the index
Add each post’s path to posts/index.json.
Render safely
Fetch the post and render it with a maintained Markdown parser. Turn raw HTML off and block javascript: links.
Handle unknown slugs
When a slug is not in posts/index.json, show a clear not-found message with a link back to the post list.
Publish the folder
Publish the folder with a GitHub Actions Pages workflow.
Next sessions, not today
- Category filter Once both posts pass the checks, add a category filter.
A prompt to adapt
Replace the bracketed parts with your own details.
Help me build a no-build Markdown blog in plain JavaScript in a new practice folder. First version only: two posts with title, slug, summary and category frontmatter, a posts/index.json list, safe rendering and a not-found view. No category filter or extra frontmatter fields yet. List the setup commands before changing any files. Then work in six checkpoints and, after each, tell me how to check it: 1. index.html, styles.css and a posts folder. 2. Two Markdown posts with that frontmatter. 3. Both paths listed in posts/index.json. 4. Rendering with [a maintained Markdown parser you name and explain], raw HTML off and javascript: links rejected. 5. A not-found message for unknown slugs, linking back to the list. 6. A GitHub Actions Pages workflow that publishes the folder. Add a test post with a <script> tag and a javascript: link to confirm neither runs. My blog topic: [one sentence].
Once it runs, paste your code and ask:
Review this Markdown blog for unsafe rendering. Check the parser’s raw HTML setting, how links are filtered, what an unknown or malformed slug shows, and whether a post with a <script> tag or a javascript: link can run anything. List each gap and a test that proves the fix.
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. Add one test post with a <script> tag and a javascript: link and confirm neither runs.
Check your result
Use evidence from your output. A confident explanation from the AI is not enough.
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.
Optional. Progress stays in this browser.
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.