How I Used My Own Blog to Research My Presentation About It
Last updated: 02.06.2026
How I Used My Own Blog to Research My Presentation About It
Audio Narration

The author needed a fast way to collect 14 blog posts for a presentation without manually copy-pasting from the browser. Fortunately, the blog already exposed each post as clean markdown at /md/posts/[slug], originally built for AI tools. This endpoint strips away HTML, navigation, and cookie banners, returning only the core content, which the author then fed into Claude for rapid reading and summarisation. Before working with individual posts, the author used /llms.txt, a structured, machine-readable index of the site similar to robots.txt but designed for AI discovery. Claude used this index to understand the site’s structure and locate relevant posts. For the presentation itself, the author used Slidev, a markdown-based slide tool, allowing Claude to generate and refine slides directly in markdown. The experience highlighted a “meta” benefit: infrastructure built for AI and other developers ended up being most useful to the author, demonstrating that investing in AI-friendly content formats can pay off immediately for the site owner.
The Setup
When I was asked to present my blog to a group of colleagues, the first challenge was practical: how do I gather 14 posts worth of writing without copy-pasting from a browser? I'd built a lot into the blog over the past year and needed a fast way to pull it all together.
Markdown at /md/posts
Every post on the blog is available as clean markdown at /md/posts/[slug]. I built this endpoint for AI tools — strip the HTML, navigation, and cookie banners, and return just the content. It turned out to be exactly what I needed for my own research. I fed several posts directly into Claude, which read and summarised them in seconds.
llms.txt as a Site Index
Before diving into individual posts, I pointed Claude at /llms.txt — a structured index of the site, like a machine-readable table of contents. Claude used it to map what the site contained before pulling individual posts. It's a convention similar to robots.txt but designed for AI discovery rather than search engine crawling.
Building the Slides with Slidev
For the slides I used Slidev (sli.dev) — a presentation tool built for developers where slides are written in markdown. That means Claude can write and edit them directly. The Claude Code skill for Slidev made it straightforward to generate the initial structure, iterate on layout, and keep the tone consistent. No drag-and-drop interfaces to fight with.
The Meta Moment
There's something satisfying about a tool working for yourself first. The markdown API and llms.txt were built with the idea that AI systems and other developers would find the blog easier to consume. In practice, the first person to benefit was me — using my own infrastructure as a research pipeline for a presentation about that same infrastructure.
Conclusion
If you're building a content site and wondering whether AI discoverability is worth the effort — build it anyway, even if you're not sure who else will use it. The most immediate value might come from yourself.

When the Claude window runs out: my take on T3 Code
T3 Code addresses the frustration of hitting Claude’s five-hour usage limit during focused work. Rather than replacing coding agents, it provides a single desktop interface for tools such as Claude Code, Codex, Cursor, Grok Build, OpenCode, and Antigravity, with users signing in through their own accounts. Each thread remains tied to its original provider, so an unfinished Claude conversation cannot be transferred directly to Codex. However, the surrounding workspace, project, and workflow stay in one app. When a limit is reached, T3 Code identifies the restriction and reset time, allowing the user to start a new thread with another provider and quickly restate the task. The app is free and does not resell or mark up tokens, aligning its incentives with users who want to avoid unnecessary calls. Its MIT license, self-hosting support, public codebase, and more than 21,000 GitHub stars are especially important because it handles provider credentials and repository access. Although founder Theo frequently promotes the product, its transparency makes those claims easier to verify. The Linux desktop app remains young and occasional releases cause problems, but steady improvements and its ability to coordinate separate agents make it a practical solution for maintaining momentum.
Read post
Trying out autonomous agents
Sandcastle is Matt Pocock’s workflow for running Claude Code unattended inside a Docker container. It assigns the agent a GitHub issue in a git worktree, then merges the resulting commits back into the user’s branch. Its init command quickly scaffolds the infrastructure, but useful results still depend on supplying clear, focused tickets. Wayfinder fills that planning gap by breaking an idea that is too large for one session into a map issue and smaller decision tickets. Each ticket addresses a single unresolved question rather than a build segment, producing the self-contained, labeled issues Sandcastle needs. Without this map, vague issues led to equally vague pull requests. Before queueing work, the author uses a grilling skill to challenge assumptions and force difficult decisions. Resolving uncertainty early prevents the agent from making costly guesses during unattended runs. For secrets, the author replaces a plaintext .env file with Varlock and a committed .env.schema. Values are resolved through Doppler and exposed only through process.env during execution, although each secret must still be explicitly forwarded into the container configuration. The author would use the setup again but stresses that ticket quality remains decisive. Every diff is still reviewed, tasks stay tightly scoped, and fully unattended overnight operation remains a future goal.
Read post