One positive side effect of this custom visual theme that I’m working on is that I’m cleaning up this plugin’s mess on my blog. I have way too many with little added value for the readers.

Analyzing My Installed Plugins

Just finished compiling the list of Micro.blog plugins that my blog is using: 31 in total. Then Claude AI analyzed all GitHub repos to see if there were any potential conflicts. Here’s the complete impact report for all 31 plugins, organized by risk level:

🔴 Avoid / Direct Conflicts with Your Theme

micro-blog-cards-theme — This is a full replacement theme, not a plugin. Installing it would completely override your custom theme. Skip it entirely.

plugin-collections — Injects its own lightbox targeting .e-content img. This directly conflicts with the custom lightbox you built in v0.9.12 (theme.js). Both would fight over the same images. Don’t install unless you remove your lightbox first.

plugin-opengraph-basics — Your theme already has full Open Graph meta tags (added in v0.5.9 in head.html). Installing this would generate duplicate OG tags in the <head>.

🟡 Caution / Needs Attention

plugin-archive-months — Overrides list.archivehtml.html, which would take over the archive page display with its own year/month grouped layout and inline JS. Replaces the theme’s existing compact archive view.

plugin-photos-months — Overrides list.photoshtml.html. Conflicts with your already-installed plugin-all-photos, which also provides that template. Last one installed wins.

plugin-screenshots — Also overrides list.photoshtml.html. Same conflict with plugin-all-photos.

kottkrig/microdotblog-photos-page — Also overrides list.photoshtml.html. Same three-way conflict. Pick only one photos page plugin.

stoot — Its CSS expects CSS custom properties (--gray-*, --white, --black, --link, --text-base) that your theme doesn’t define. Mastodon embeds will render with broken/missing styles. Fixable by adding those variables to style.css.

plugin-post-stats — No dark mode support in its CSS. The stats page cards and Chart.js charts will look visually inconsistent in dark mode. Fixable with CSS overrides.

plugin-bigfoot — Already analyzed. jQuery 1.12.4 (~90KB) loaded on every page, and footnote popover CSS won’t respect dark mode. Set post_separator = "article.h-entry" when installing.

plugin-conversation-on-mb — Adds a “View conversation on Micro.blog” link, but requires manually calling {{ partial "conversation-link.html" . }} in your theme’s single post templates. Your theme already loads Micro.blog’s conversation.js via microhook-after-post.html, which renders the full conversation box. This plugin adds a different thing (a link vs. a box), so they don’t conflict — but it needs a manual theme edit to integrate.

plugin-reply-by-email — Same situation: requires {{ partial "reply-by-email.html" . }} manually added to your single post template. Your theme already has reply.js for native Micro.blog replies. These serve different purposes (email vs. Micro.blog) and can coexist, but need a theme edit.

plugin-reply-on-mastodon — Repository returns 404. No longer exists.

plugin-search-space — Creates a /search-space/ page (different URL from your installed /search/ page). Having two search pages could confuse visitors. Pick one.

Bottom line: The most important things to avoid are plugin-collections (lightbox conflict) and plugin-opengraph-basics (duplicate OG tags). For the photos page, pick only one of: plugin-all-photos, plugin-photos-months, plugin-screenshots, or kottkrig/microdotblog-photos-page.

I’m not sure everything has been analyzed correctly, especially when it comes to photo-related plugins.

Time for a Complete Reset

It’s time for a project status update. I’ve been working hard trying to get the Micro.blog/Hugo engine to make this custom theme work the way I want. It’s not an easy task. I’m starting to think that because Micro.blog is a niche product, even though it is based on Hugo, there are some particularities in the templating system that Claude AI is not well-trained for. Micro.blog plugins make things even more complicated. I’m now at a point where I need to feed all plugin GitHub repositories into my conversation so Claude AI can fully understand what each plugin injects into the templates. Finally, due to unpredictable issues with blog posts and image deletions, I had to delete and recreate my test blog, which wiped everything.

I’m fairly certain that when I’m ready to apply my custom theme to my production blog, everything will break. Luckily, we can easily revert to another theme and perform a full rebuild. It’s tedious but seems like a reliable process.

Spent some time building my custom theme for Micro.blog with Claude Code. It works but the nature of Hugo processing with different templates complicates the process. What works on the main timeline won’t always work on individual posts. Lot’s of back and forth to test and fix things. The good thing is that I’m building exactly what I want.

You can see the current design right here.

Another milestone accomplished: I now have a basic custom theme installed on my Micro.blog test website. It’s not a plugin per se; it’s a custom theme stored on my GitHub account that Micro.blog fetches. I don’t yet know how to turn it into a plugin with version numbering and all that, but I might not need that after all. I just wish Micro.blog would update automatically whenever I push a new change to my repo, like Vercel does.

I recently decided to drop the numericcitizen.io domain name and focus on numericcitizen.me for all my needs. The former was tied to a Craft subscription that I’ll cancel, too. I prefer to manage everything inside a single space under a single domain. It’s cheaper.

Continuing my thinking about a custom-built Micro.blog theme plugin, I wondered why most of Micro.blog themes design card-based? Here’s Claude AI’s answer:

Cards became the dominant Micro.blog theme style largely by following a broader web design trend from the mid-2010s, when Pinterest and Material Design made cards ubiquitous. Theme authors adopted them because they handle variable-length content safely and look great in screenshots. The fork-from-fork nature of many Micro.blog themes then perpetuated the pattern. The irony is that cards aren’t actually the best fit for Micro.blog’s typical stream of short title-less posts — making it a real opportunity for anyone wanting a distinctive, better-suited design.

Besides the fact that Micro.blog launched in 2018, the rest of Claude’s response makes me think that my design choice of a left sidebar, similar to Micro, is a good one.

Vibe Coding a Custom-Built Micro.blog Theme Plugin

I started working a my next vibe coding project: building my own Micro.blog theme plugin. I wanted to have one even before vibe coding was a thing, but I didn’t have the experience with Hugo and Micro.blog theme creation. With Claude Code, having that knowledge is secondary to the task, but having a clear mind about the desired final product is paramount. I started gathering specifications that will end up in some form in the specs.md file that I’ll feed to Claude Code. I’m also gathering design tidbits that reflect what I like. Ultimately, all my Micro.blog sites will share most of the design elements. Thanks the goal.

I plan to provide more updates about this little project, here on my meta blog. I’m doing all my work in Craft, a great tool for such project. I might decide to share my document with you dear readers if you show sign of curiosity.

What Happened in Recent Days - A LOT

Over the past few weeks, I’ve been on an intensive learning journey exploring automation, cloud deployment, and AI integration. I’ve been hands-on, building real workflows and connecting actual services. Here’s what I discovered along the way.

Getting Started with Automation

The foundation of this exploration was deploying n8n as a self-hosted instance on a cloud provider. This wasn’t just about clicking a button—it required understanding infrastructure, configuration, and the basics of running a service in the cloud. Once that was in place, I could start building workflows.

Building basic workflows in n8n taught me what it actually means to create a functional automation. It’s not enough to have a good idea; you need to understand how data flows through your workflow, how triggers initiate actions, how conditions branch logic, and how errors are handled. Meeting all the requirements for a working workflow meant learning to think systematically about each step and its dependencies.

Accelerating Learning with AI

One of the biggest breakthroughs was leveraging Claude AI to accelerate my learning across different subject matters. Rather than struggling through documentation alone or spending hours debugging, I could ask targeted questions and get explanations tailored to my specific use cases. This fundamentally changed how quickly I could iterate and experiment.

Claude became my learning partner—helping me understand concepts, troubleshoot issues, and even write code. This wasn’t just about saving time; it was about compressing what might have taken weeks of traditional learning into days of focused experimentation.

Building and Connecting

From there, I expanded into multiple directions simultaneously. I deployed Next.js apps on Vercel using Claude Code, which gave me a way to build custom web interfaces quickly. I integrated GitHub for continuous delivery, automating the process of pushing code changes to live services like Scribbles and Micro.blog.

But the real power came from connecting external services directly into n8n workflows. I learned to interact with Telegram, Discord, Micro.blog, and Tinylytics through their APIs, webhooks, and HTTP requests. Each integration taught me something different about how modern services communicate with each other. Some services have well-documented APIs; others require reverse-engineering their webhook payloads. Some are straightforward; others have quirks you only discover through experimentation.

The Deeper Challenges

The more complex problems emerged when I tackled data persistence and LLM integration within n8n. Adding state management to automation workflows isn’t trivial—you need to decide where to store data, how to retrieve it, and how to keep it synchronized across multiple workflow runs. It’s one thing to run a workflow once; it’s another to run it reliably over time while maintaining context and history.

Incorporating AI services—whether through pay-per-use models like Claude or subscription-based services—required careful consideration. I had to think about cost implications, rate limits, and how to structure requests efficiently. Suddenly, every API call had a price tag, and I became much more conscious of resource consumption.

Key Insights

What stands out most is a clearer understanding of tool selection. Each platform has its place, and knowing when to use n8n versus a custom Next.js app versus a direct API call makes all the difference. Sometimes the right answer is a simple webhook; sometimes you need the flexibility of a full application. This contextual thinking has become invaluable.

I’ve also learned to transpose ideas into concrete use cases, leveraging service APIs from Scribbles, Tinylytics, and Micro.blog in ways I hadn’t considered before. What started as “I wonder if I can connect these services” became “Here’s a specific workflow that solves a real problem.”

I’ve discovered how to make the most of services I was already depending on—Micro.blog and Inoreader—by understanding their capabilities more deeply. These tools had features and integrations I’d overlooked, and now I’m using them in ways that actually enhance my workflow.

I’ve also expanded my toolkit with utilities like VS Code, GitHub, and Postman, each playing a crucial role in different parts of the workflow. VS Code became my development environment, GitHub my version control and deployment trigger, and Postman my tool for testing and understanding APIs before integrating them into n8n.

The Bigger Picture

The journey has been about understanding not just individual tools, but how they fit together in a larger ecosystem. It’s about recognizing that modern development isn’t about mastering one tool—it’s about understanding how to orchestrate multiple tools to solve real problems. And it’s about using AI not as a replacement for learning, but as an accelerant that lets you learn faster and go deeper.