I've started keeping a MAKING-OF.md journal in my repositories - a first-person log of how each project comes together with an AI agent, including the dead ends and the arguments. This post is the first chapter of diderot's journal, lightly edited for the blog: how a "Helm for AI agent skills" went from a name-picking session to a working update / install / status over git sources, in two working sessions. The code this post walks through landed in diderot#2.
I don't get many chances to play tennis. Between work, everyday constraints, and lately some pretty uncooperative weather, court time is rare and valuable. So when I finally found a slot that worked — and the booking system refused to give it back — frustration set in fast.
Note: A 🇫🇷 French version of this post is available on Sciam's blog (my employer). Like many developers, my life is littered with unfinished side projects. But this time was different. This time, I had GitHub Copilot as my coding companion, and I actually finished. Let me tell you how AI-assisted development helped me build a gift card management application that I actually use every day — and I did it almost entirely without opening an IDE.
I've used Git Flow on quite a few projects over the years — and honestly, I've reached a point where I don't think it's the right choice for most modern teams anymore. It's not that Git Flow was bad. In fact, when Vincent Driessen came up with it back in 2010, it made a lot of sense. We didn't have solid CI/CD pipelines yet. Releases were manual. Teams were smaller and slower. Having a clean branching model for "features," "releases," and "hotfixes" was a huge step forward at the time. But now?...
I left Red Hat a few months ago and joined Sciam, but I had to return my corporate laptop. To maintain my workstation setup, I decided to reuse my old Dell XPS and migrate my data from one laptop to another. After installing a fresh Fedora system on the XPS, everything seemed fine initially, but some unexpected issues arose afterward.
