Me and Habitica
I'll be honest: I'm not really that much of a Habitica user. I learned about it from my colleague. Signed up for an account, thought the gamification was cool, and that's it.
Used it a bit, then I had the most cliché thought a developer could have: I need to automate this. Let's be honest: nobody wants to manually push a button when they commit something at work, open a PR, or review somebody else's PR. Nobody.
Pitched the idea to my colleagues. They thought it was cool, but everyone's busy with work. There was no out-of-the-box solution yet.
Fine. I'll build it.
That's how this thing started. It wasn't called Octogriffin back then. It wasn't really called anything. We had some discussions about what it should and should not be, which got me pretty excited.
Started coding. This was shortly before agentic AI. Slowly but surely it was taking shape: a little webhook handler here, a bit of an OAuth redirect there, and voilà! It was working. Locally. On my machine. Ngrok helped.
Built more pages, more triggers, more everything. But then I realized: for this to work at work, we would need to install it on our client's GitHub organization account.
Defeat.
Not happening. Took the wind out of my sails.
It sat in this unfinished state for a while. Then Opus 4.8 came out and I realized I could get it working real quick. Wrote up some PRDs and specs, and let Opus have a go at it.
Was decent. Talked about it with my colleague again. We came up with the name: Octogriffin. Bought the domain, deployed everything. It was awesome.
Sat again for months, until the first users and Ko-fi supporters came in. Put the wind back in the sails. Felt good. Around that time Opus 5.5 came out.
Fine. I'll finish it.
Completed a new feature, overhauled the website, released it, wrote a LinkedIn post, now writing this. Life is great again.
If my horrible writing skills haven't convinced you to try it out, then I don't know what will. Check it out either way:
Claude's complaints
Claude gave me some feedback on this post.
The readers never find out what it does.
Ugh. You create triggers like "When I commit in these repositories, score this task in Habitica." That's the simplest trigger. There's a lot more. Don't make me tell you what it does, just try it out.
There's only one link.
Right.
- GitHub repo: github.com/drazenbebic/octogriffin
- Installation guide: octogriffin.com/installation
- Sponsors page: octogriffin.com/sponsors
The AI part is your most interesting angle, and you skip past it.
Is it really? I used Opus 5.5 and made it redesign everything from scratch using the atomic design methodology. Told it I like purple and that we should use noise in gradients to make it look cool. Also used a lot of Matt Pocock's skills (Improve Codebase Architecture, for example). There. You're informed.
Closing the loop.
I'm currently working on GitHub organization support. It still doesn't do that, lol.
The DEV Content Playbook emphasizes that the best posts don't just broadcast information—they start a discussion.
So, uh... Have you ever done something like this? Let me know what you think, I guess?
octogriffin.com
Top comments (2)
Webhook retries are a useful edge case for the GitHub-to-Habitica bridge: recording the delivery ID before awarding XP can keep a redelivery from granting the same reward twice. How do you handle events that arrive out of order?
Absolutely! Octogriffin already handles this by keeping a log entry of every event that awards XP. The delivery ID is part of a uniqueness constraint on that table. Before we score anything we log that it happened. If it can't be logged, it already exists, and it's skipped. If Habitica rejects the score, the entry is removed again, so a retry can still deliver it.
As for events that arrive out of order: we don't really care about that. The result of any event is "Score this habit X times", and it doesn't matter in which order they arrive as long as they get processed properly. Triggers have a cooldown feature, but it's based on when Octogriffin handles the request, not when it happened. So whichever event arrives first scores, and two at the same time can’t both get through.
I checked the code and there actually is one place where order matters: suspending and unsuspending the GitHub app. A suspend arriving after the matching unsuspend would currently leave the app suspended. Fixing that is next on my list.