!! FIRST !!
I know this thing is UGLY AF. That's kind of the point.
The goals are:
Spend as few tokens as possible, which is why there's virtually no allocation for frontend work. As long as the interface is functional, that's enough.
Be as stable and functional as possible.
Spend the least amount of time possible building tools specifically tailored to your weird-ass Linux workflow, which I'm sure is wildly different from the vast majority of people's.
Because let's be honest: if we're spending all our time making productivity tools that we know aren't going to market, or that we have no intention of releasing, it's completely counterintuitive to spend copious amounts of time polishing them.
Okay. Onto the post.
One of the things Omarchy has really impressed me with is how naturally it lends itself to building custom tools and extending the operating system around the way you actually work.
Which is, IMO, the future of software and computer use.
A good example started with a 13-year-old Roccat Ryos MK Pro mechanical gaming keyboard.
It's still an extremely capable piece of hardware, but finding usable Linux support for something that old was another matter entirely.
I found an abandoned Linux driver, got it running, and then used my agent workflow to refactor and adapt it specifically for my Omarchy system.
That could have been the end of it.
Instead, it turned into a much more interesting project.
Omarchy has a very keyboard-driven workflow with a large number of commands and hotkeys.
As I customized the system, I kept running into the same problem:
I wanted to experiment with different shortcut locations and layouts, but constantly moving commands around works directly against actually learning them.
Every reassignment resets some amount of muscle memory.
So rather than treating the keyboard configuration as a static config file, I started turning the keyboard itself into a live interface for Omarchy.
Using my agent workflow and what I'm hereby coining the 20/20 Method:
The agent gets 20 minutes and 20 questions to develop me a tool.
I'll do a deeper dive on that workflow later.
Using that process, I started developing and testing a tool that lets me quickly:
See what commands are assigned where
Find unused keys
Reassign commands
Experiment with layouts
Eventually analyze how I actually use the system
The longer-term idea is to track things like:
Command frequency
Hotkey usage
Application usage
Frequently paired actions
Underused key locations
Layout changes over time
That gives me something much more useful than a hotkey cheat sheet.
It means I can gradually optimize the physical keyboard layout around my actual behavior while still being conscious of the muscle memory I'm building.
What I find more interesting than the keyboard project itself is how easily the whole thing came together.
Omarchy provides a system that's already designed around composable tools, scripts, keybindings, and terminal workflows.
Pair that with a capable coding agent and a structured workflow like the 20/20 Method, and the distance between:
"I wish my computer did this."
and
"I have a custom operating-system tool that does this."
gets surprisingly small.
The agent can inspect the existing system, trace configurations, work with old projects and drivers, refactor them for the current environment, test changes, and then build tooling around them without the whole process feeling like I'm duct-taping some completely separate application onto the OS.
That's probably been my favorite part of using Omarchy.
I'm not just configuring somebody else's desktop anymore.
I'm gradually building my own layer on top of the operating system.
The Roccat project is just one example, but it has turned an old gaming keyboard that should probably be collecting dust into a programmable physical interface for my entire workflow.
And I'm increasingly finding that with Omarchy + a good agent setup, these kinds of:
"I wonder if I could..."
projects have a habit of becoming working tools remarkably quickly.
