The Changelog Habit That Keeps Five RAXXO Tools Honest

RAXXO, the developer behind five tools including Git Dojo and Statusline Builder, has adopted a strict changelog habit: every change gets a plain-language line written before the code merges. The rule, which requires a user-facing description of each update, prevents feature drift and makes it easy for users to verify what changed. 'A public changelog turns "trust me" into "check for yourself,"' the developer said.

Every RAXXO tool ships with a changelog file that gets a line written before the code merges, not after The rule is one sentence, plain language, no jargon, written for the person using the tool, not for me It catches quiet feature drift long before a user has to ask what changed A public changelog turns "trust me" into "check for yourself," which matters more than any feature list I was answering a message about Statusline Builder, a small free tool that renders a live status line for Claude Code, when I hit a question I could not answer cleanly: had the preset picker always shown that many options, or had I added a batch of them a few weeks earlier and just forgotten. I went looking through old commits to reconstruct the answer, which took longer than it should have, and the honest answer was I did not know. I had shipped the change, used the tool myself every day since, and still could not tell someone else what had changed and when. That is a small embarrassment on its own. It becomes a real problem once you run five tools instead of one. Git Dojo teaches git from the terminal, OhNine watches Claude usage limits from the menu bar, Statusline Builder generates status lines, Claude Blueprint packages a full Claude Code setup into one install, and RAXXO Studio turns a single video or image into captions for different platforms. Each one gets small updates on its own schedule. Without something written down, "what changed recently" becomes a question only answerable by reading git history, which is fine for me and useless for anyone else, including a user who just wants to know if the bug they hit last week is already fixed. The same gap showed up from the other direction with Git Dojo https://dev.to/blogs/lab/why-i-built-git-dojo-instead-of-another-git-gui , the terminal-first tool that teaches git through real exercises instead of slides. Someone working through one of the later lessons asked why a command that used to accept a shortcut flag suddenly needed the full argument spelled out. I had made that change on purpose, to match how the real git CLI behaves rather than a simplified version of it, but I had no record of when or why beyond my own memory. Answering felt like guessing out loud, which is not a good look for a tool whose entire pitch is teaching people to trust the terminal instead of fearing it. So I started keeping a changelog file for each tool, and more specifically, I started keeping the habit around writing one, which turned out to be the part that actually mattered. A changelog file with nothing in it is just a promise you made yourself. The habit is what fills it in. The rule is simple enough to fit in a sentence: before I consider a change finished, I write one line describing it in the same file, in language a user would understand, and that line has to exist before I call the work done. Not after I remember to, not during a cleanup pass once a month, before. That ordering is the entire trick. A changelog written after the fact turns into an archaeology project, exactly like the one I found myself doing over that Statusline Builder question. You are reconstructing intent from diffs, trying to remember why you touched a file three weeks ago, and the result reads like a commit log with the technical edges filed down, which is not the same thing as a changelog a real person wants to read. A changelog written in the moment, while the change is still fresh in my head and I still remember why I made it, takes less than a minute and reads like something a person actually wrote for another person. The language rule matters just as much as the timing. "Fixed a race condition in the preset loader" means nothing to someone who just wants their status line to stop flickering on startup. "Fixed a bug where the status line would flash the wrong preset for a second after opening a new terminal" says the same thing in words a user can match against what they actually saw. I write every line as if I am explaining the change to someone who has never opened the source code and never will, because that describes almost everyone who uses these tools. If a line needs a glossary, I rewrite it until it does not. I keep the format flat on purpose: a date, a one line description, done. No severity tags, no categories, no version numbers that only make sense if you already track the project closely. The flatness is what keeps the habit cheap enough to survive a busy week. The moment a changelog entry becomes a small writing project with required fields, it starts getting skipped, and a changelog that gets skipped stops being a changelog. It becomes an occasionally updated file that nobody, including me, actually trusts. I also resist the urge to bundle. A week with five small fixes becomes five separate lines, not one line that says "various fixes and improvements," which is the phrase I actively try to never write. That phrase is a tell that whoever wrote it either did not want to take the time to be specific or genuinely could not remember what they changed, and either way it gives the reader nothing to check their own experience against. If someone hit a specific bug, they want to see that specific bug named and dated, not folded into a vague catch-all line that could mean anything. The most useful side effect had nothing to do with the users reading it. It changed how I build. Writing a plain sentence about a change forces a kind of honesty a commit message does not. "Refactored the auth flow" is a perfectly normal thing to type into a commit and a completely useless thing to type into a changelog, because a changelog reader does not care about the refactor, they care about what is different for them. When I cannot answer that question in one clear sentence, it is usually a sign the change itself was not as clear as I thought it was while I was writing the code. More than once, trying to write the changelog line has sent me back to simplify the actual change, because I could not describe it simply and that was the tell. It also catches drift that would otherwise go unnoticed for months. Small tools accumulate small decisions: a default that quietly changed, a keyboard shortcut that moved, a setting that got renamed. None of those are big enough to announce on their own, and all of them are exactly the kind of thing that makes a returning user feel like the tool changed under them without warning. A running changelog turns that drift into a visible, dated trail instead of a mystery. When someone tells me a feature "used to work differently," I can check the file and tell them exactly when and why, instead of guessing alongside them. I wrote more about the checks I run before calling anything finished in the four-pass check I run before calling anything shipped https://dev.to/blogs/lab/the-four-pass-check-i-run-before-calling-anything-shipped , and the changelog line has become one more pass in that same spirit, a final check that forces the change to justify itself in plain words. A feature list tells a visitor what a tool can do today. A changelog tells them something a feature list cannot: that somebody is actually still working on it, and that the person building it is willing to be specific about what changed instead of hiding behind version numbers and marketing language. That distinction shows up most with the free tools. OhNine https://dev.to/blogs/lab/ohnine-why-i-built-a-menu-bar-app-for-claude-limits and Statusline Builder cost nothing, which means the usual signal of "someone paid for this so it must be maintained" is not available. A visible, regularly dated changelog does some of that same job. It says this is not an abandoned side project with a page still sitting online, it is a tool with someone actively behind it. It also changes the tone of support questions before they even happen. Someone who checks the changelog before writing in already knows whether their issue is a known, already fixed bug or something new, and either way they arrive at a conversation with more context than a blank "is this broken" message. I think about this the same way I think about the design system that makes five RAXXO tools feel like one studio https://dev.to/blogs/lab/the-design-system-that-makes-five-raxxo-tools-feel-like-one-studio : consistency is not just a visual choice, it is a trust signal, and a changelog that reads the same way across every tool tells a returning user they are dealing with one studio's habits, not five disconnected projects that happen to share a logo. None of this required new tooling or a process overhaul. It required one sentence, written at the right moment, in language meant for the reader instead of the author. That is a small enough bar that I have kept it up through busy stretches and quiet ones alike, which is the actual test of whether a habit is real or just something that sounded good the week I started it. A changelog is one of the cheapest trust-building habits a small studio can keep, and the value is almost entirely in the discipline of writing the line before the work is called finished, not in the file itself. Writing that one plain sentence catches drift I would otherwise forget, forces changes to justify themselves in words a user would actually understand, and gives visitors a concrete, dated reason to believe a tool is still being looked after. It costs less than a minute per change and it has saved me from more than one awkward "I'm not sure when that changed" conversation since I started taking it seriously. If you ship more than one small tool yourself, this is one of the few habits worth adopting exactly as it is, no adaptation required.