SkyHanni: a Kotlin utility mod that surfaces the numbers in Hypixel SkyBlock

What the mod actually adds

SkyHanni is a Fabric Minecraft mod that adds many useful features to Hypixel SkyBlock, and the four headline features are worth reading closely because they show what kind of tool it is.

Helpful GUIs mean viewing important information at a glance. Extra chat messages mean receiving reminders and tips at the right moment. Object highlighters mean focusing on important items in inventories or highlighting mobs in the world. And highly customizable displays mean personalising your scoreboard, tab list or chat format.

The pattern in that list is information rather than automation. The mod surfaces what the game is already showing you, in a place where you can read it while doing something else, and it changes the layout of the interface you already have. There is no mention of automating actions on your behalf, and the set of areas the mod is said to be especially useful for is telling: farming, slayers, bingo, Diana, fishing, rift and mining. Those are the repetitive, number-driven activities where a player is repeatedly checking a counter and a timer.

That framing matters for how the mod relates to the server's rules, and the project takes the question seriously rather than leaving it implicit. The Discord guidance for feature suggestions includes an instruction not to copy from existing mods or break Hypixel rules, and that instruction is directed at contributors, which is where the question actually belongs.

The longer feature list lives in a separate document, docs/FEATURES.md, and the getting started section points at it as the place to explore what the mod can do. The feature set is large enough that a single README summary would be misleading, which is a reasonable reason for the mod to have a documentation site rather than a long readme.

The project is LGPL-2.1 licensed, the primary language is Kotlin, the default branch is beta, and the recent releases are 9.2.0 from 2026-10-12, 9.1.0 from 2026-09-18 and 9.0.0 from 2026-09-16, with the last push to the repository on 2026-10-20. The mod is published on Modrinth and there is a Discord community, which is where most of the support and coordination happens for a mod like this.

Getting started, and where the configuration lives

The getting started section is three steps, and the third of them is the one that decides whether the mod is useful to you.

The first is to install, following the installation guide in docs/INSTALLING.md, which is a separate document from the readme. The second is to set up, by typing a command in game:

/sh
/skyhanni

The third is to explore, by reading the feature list.

That middle step is the one that matters, and it is worth saying plainly: SkyHanni is not a mod that works out of the box. The configuration is inside the game, behind a slash command, and a mod with this many features has a lot of settings. A user who expects a set of nice defaults and never opens the configuration will get the defaults, which are not what they want.

The alternative to that is that the mod's own description leads with highly customizable displays, listing the scoreboard, the tab list and the chat format as the things you are expected to reshape. The same phrase appears for the scoreboard, the tab list and the chat format, which tells you those are the parts of the interface the project expects users to want their own way.

The support structure reflects a mod with a large user base and a lot of configuration surface. There is a bug reports channel, with the guidance to check the faq and known-bugs channels first, a support channel for questions about the mod or about Minecraft in general, a suggestions channel for feature ideas, and a general chat channel for other SkyHanni users. The known-bugs channel in particular is a signal about how a mod that interacts with a live game server behaves: some features break when the game changes, and a project with a known-bugs channel is one that tracks that openly rather than pretending it does not happen.

The build: Gradle, Stonecutter and a multi-version source tree

The repository layout tells you how a mod that has to run against several Minecraft versions is put together.

The build is Gradle, with a build.gradle.kts and a settings.gradle.kts using the Kotlin DSL, and a Gradle wrapper checked in as gradlew and gradlew.bat so every contributor builds with the same Gradle version. There is a gradle/ directory for the wrapper configuration, a gradle.properties file, and a buildSrc/ directory for the project's own build logic, which is where the convention is that shared build code lives in a Kotlin source set rather than in a script.

The interesting file is stonecutter.gradle.kts, together with a versions/ directory. Stonecutter is a Gradle plugin for building a single source tree into several different artefact versions, and a Minecraft mod that supports more than one game version, and more than one mod loader, cannot do that with a plain Gradle build. The versions/ directory holds the version matrix, which is where the per-version source overrides and the mapping between Minecraft versions and mod loaders are described.

The topics list names both fabric-mod and forge-mod, and the two loaders have different internal APIs, so a mod supporting both is doing a nontrivial amount of abstraction. That is a large part of why the mod is written in Kotlin and structured as a Gradle project rather than as a loose collection of scripts.

The rest of the tree is a set of quality and release tools. There is a detekt/ directory, the static analysis framework for Kotlin, so style and complexity rules are checked in the build rather than by eye. There is an annotation-processors/ directory, which for a mod this size usually means code generation, for example for the repetitive data structures that describe items, mobs and locations. There is a buildTools/ directory, a sharedVariables/ directory for values shared across the build, a jitpack.yml so the project can be consumed from a JitPack coordinate, a .devauth/ directory for the development authentication flow, a .live-plugins/ directory, a pull_request_template.md and a CONTRIBUTING.md.

The .idea/ directory being checked in, and the .editorconfig and .gitattributes files, are the small signs of a team that works in an IDE and wants the formatting to be the same for everyone.

Licence, releases and what the project is trying to be

The licence is LGPL-2.1, which is an unusual choice for a Minecraft mod and worth pausing on.

LGPL is a weak copyleft licence. A mod distributed as a jar that links against libraries under the LGPL can be used, modified and redistributed under conditions that require the library itself to remain available and modifiable. For a game mod, the practical effect is that the mod's own source is expected to stay available to the community, which is close to the norm for the Minecraft modding scene, and a stronger licence such as GPL would have imposed copyleft on anything linking it.

The other thing the licence signals is the relationship between the mod and the game. The mod is not a derivative of Minecraft, it is code that runs alongside it through the loader, and the LGPL reflects the fact that the mod is a separate work that people are expected to be able to fork and improve. The repository has a CONTRIBUTING.md and the project asks for contributions in the readme, including the offer to fix that one annoying bug yourself, which is a community model rather than a product model.

The version scheme is the usual major and minor scheme with 9.x, and the recent 9.0.0, 9.1.0 and 9.2.0 releases over September and October 2026 suggest an active project with a steady release cadence. The default branch is beta, which means the branch the development happens on is called beta, and a user who builds from source rather than installing a release is building from that branch.

The distribution channels are Modrinth and Discord, and the repository is where the code lives. For a mod like this, that arrangement is the norm: the code is public, the artefact is a download, and the conversation about it happens in chat. The topics list also includes hacktoberfest, which is a common way for projects of this kind to collect a first round of external contributions.

Where SkyHanni is the wrong tool

The first limit is the obvious one, and it is worth stating plainly: this is a mod for one specific game mode on one specific server. If you do not play Hypixel SkyBlock, there is nothing here for you, and if you play Minecraft but not that mode, the mod is inert.

The second is that a client-side mod on a competitive multiplayer server is a category of software with its own rules, and the project is careful about it. The suggestions guidance tells contributors not to break Hypixel rules, and the known-bugs channel implies that features do break when the game changes underneath them. A mod that shows you a counter the game is already showing you is on one side of a line, and a mod that automates the game is on the other, and the difference is a matter of the server's terms as much as of the implementation. Anyone considering installing a client-side mod on a competitive server should read those terms rather than take the project's framing as sufficient.

The third is the maintenance risk that comes with the platform. SkyHanni depends on internals of Minecraft and of the mod loader, and it has to track both. A game update that changes a rendering or event API breaks the mod until somebody updates it, and the timeline between the game update and the working mod is the window in which a user has a broken client. Nothing in the architecture removes that, because a mod that reads the game's state is by definition coupled to how the game exposes it.

The fourth is the configuration burden, which is a real cost for a user who only wanted one feature. The mod ships a large number of options, and the expectation that the user opens a configuration screen and shapes it is part of the design. Somebody who wants one small overlay may find they have to sit through a settings tree to get it, and the settings themselves are in-game, which is slower to navigate than a plain config file.

And the fifth is the multi-version build. The Stonecutter setup with a versions/ directory is what makes the mod run on several Minecraft and loader combinations, and it is also what makes the source tree harder to read for a newcomer, because the same code has to be written against several API versions at once. For a contributor this is a real barrier, and it is one of the reasons a project of this size depends on a community Discord to onboard people.

Editorial conclusion

SkyHanni is worth trying if you play Hypixel SkyBlock and find yourself working out values the game shows you only in passing, because the feature set is aimed at exactly the repetitive parts of that game, with farming, slayers, bingo, Diana, fishing, rift and mining named as the areas it helps most, and because the scoreboard, tab list and chat formats are configurable rather than fixed. It is the wrong tool if you do not play that game mode, and it is the wrong tool if you want a clean unmodified interface. Before you install it, check three things: that the mod is appropriate for the server you play on, because the project's own suggestions channel asks contributors not to copy from existing mods or break Hypixel rules, and a client-side mod on a competitive server is exactly the situation those rules exist for; that you pick the right build, because the repository carries a Stonecutter multi-version build setup with a versions/ directory, and the default branch is beta, so a beta build and a stable release are different things; and that you read the installation guide rather than assuming, because the getting started steps point at a separate installation document and at the in-game /sh or /skyhanni command for configuration, and the mod has enough options that configuring it is a real part of using it.

Frequently asked questions

Official sources

1. License: LGPL-2.1
2. Project website
3. README
4. Releases
5. SkyHanniStudios/SkyHanni on GitHub