SkyBlock Minecraft: the story of a living wiki

It started the way many Minecraft obsessions do: alone on a SkyBlock island, with limited resources and a feeling that the real bottleneck was not the game, but the information. I spent hours jumping between outdated wikis, buried forum posts and disconnected videos just to understand one mechanic. Then came a question: what if the wiki could keep up with the game?

SkyBlockCodexAPI grew out of that frustration and a simple idea: organise public SkyBlock data into a wiki that is easy to explore. AI would help us build and debug it, while the game information would come from Hypixel’s API.

The first phase was pretty straightforward on the surface: connect to Hypixel's public API and start displaying information about:

• items
• collections
• skills
• elections
• bingo
• museum

On paper, the idea was simple: ask for data and show it. In practice, we soon discovered the real problem: the information does not always arrive in the same format or with the same level of cleanliness.

• Some descriptions came in plain text.
• Others brought lists.
• Others mixed lore, perks, unlocks and special fields.
• And many included Minecraft format codes like §7, §a, §d, or even alternative formats like %%light_purple%%.

That was one of the first moments in which AI began to add real value. It helped us:

• detect repeated structures within chaos
• propose normalizations without losing information
• transform formats designed for the game into something readable for the web
• speed up small iterations without losing visual coherence

It wasn't just about “translating JSON”. It was about interpreting the game’s visual language and bringing it to the web without losing its character.

The challenge of making it static without it feeling static

One major constraint was our decision to host the application on GitHub Pages.

That imposed a very clear restriction: no traditional backend.
No persistent server.
No private logic on the server side.

We treated this as a creative constraint. A static website could still feel dynamic, using only:

• HTML
• CSS
• JavaScript
• calls to public endpoints
• a light but flexible architecture

AI was especially helpful here because it helped us rethink the project multiple times without having to redo the entire thing. As we discovered which endpoints were public, which were not, which things could be queried directly, and which needed to be simplified, we quickly adjusted the architecture.

The result was an important decision: build a responsive, dynamic experience, but without its own backend, taking advantage of only what could be resolved safely and publicly. That allowed us to keep the deployment simple and the project very easy to share.

A real difficulty: the visual format of Minecraft does not exist on the web

One of the most curious—and most entertaining—problems was the treatment of the text.

In SkyBlock, colour carries meaning. A perk’s wording matters, but so does its presentation. Gold text, a light-blue line, a red stat or a purple rarity label are all part of the game experience.

Typical examples:

• +0.5% ☣ Crit Chance
• +1 ❈ Defense
• +5 SkyBlock XP
• perks with embedded colors
• specially formatted item names

To show that well on a website we had to solve many small difficulties:

• interpret codes §

• interpret alternative formats such as %%light_purple%%

• distinguish between symbols, numbers and text

• respect the “+” without breaking the color of the stat

• apply different colors depending on the attribute

• maintain visual readability without losing the style of the game

Here AI was especially useful as a rapid iteration tool. It helped us convert informal visual rules into concrete rendering rules. And, perhaps more importantly, to correct dozens of small bugs that appear when working with very irregular text.

Many of those mistakes would have taken a lot of time if we had gone case by case. With AI, it was much easier to spot patterns, check for exceptions, and adjust the outcome until it felt right.

Beyond the search engine: converting data into experience

Once the basic rendering was working, the next step was to stop thinking about just “displaying data” and start thinking about how to navigate a wiki.

There the decisions that gave the most personality to the project began to appear:

Search and suggestions

We wanted search to feel responsive, with autocomplete and suggestions appearing as players typed.

We added:

• real time suggestions
• search by items, collections and skills
• visual examples on the landing
• a search animation to make the home more attractive

In addition, we worked so that these suggestions were not just plain text, but rather respected colors, rarities and special formats. This way the search engine experience fit with the rest of the application.

Items: turning a basic page into something useful

The items section was probably one of the most worked on.

It was not enough to show name, category and ID. That was too much like printing a JSON to the screen. We wanted something that spoke the player's language.

We gradually refined each item page to include:

• name with color according to rarity
• support for specially formatted names
• image of the item according to its material
• support for head textures using skin.value
• support for 3D icons in skull items
• fallbacks for failed images, instead of the browser’s broken-image icon
• visual, organized and colored stats
• Museum information
• related items within the same set
• sum of total stats of the set

We also had to solve very specific and very “SkyBlock” cases:

• legacy materials like gold_boots that in real assets are golden_boots
• tinted leather armor with color field
• sets with inconsistent names such as:
  • Wise Dragon Boots
  • Boots of the Pack
  • Perfect Boots – Tier XII

AI helped us generalise rules. When we found an unusual case, we could iterate on the logic and turn exceptions into reusable patterns until we reached the result we wanted.

Collections: not only tiers, but context

The collections part also evolved a lot.

Initially, showing the category and tiers seemed enough. Once we started using the site as a tool, however, we realised we needed more context.

We ended up adding:

• icons by category
• horizontal display of tiers
• unlocks within each tier
• SkyBlock XP highlight
• clickable unlocks when pointing to real items
• support for recipes and minion recipes

That allowed a collection to be not just a list of requirements, but a small navigable path within the wiki itself. From a collection you can jump to an item, and from the item continue exploring other parts of the content.

Skills: levels, XP and rewards with context

The skills section also required a good amount of work. Not only because of the data structure, but because the API information had to be interpreted correctly.

The API did not give the experience “per level”, but rather the total accumulated experience. So we had to recalculate and represent:

• level
• XP required for that level
• Total XP
• unlocks by level

Then we added a detail modal for each level, where the unlocks are displayed in an improved visual format. And there the same idea that we had already learned was repeated: it is not enough to show text; You have to respect the visual language of the game.

Mayor and elections: when the data model depends on context

The Mayor section was particularly interesting: it had to display information and account for different situations:

• current mayor
• minister
• perks
• active elections
• candidates
• vote percentages
• possible special mayors

We split the interface into two columns:

• on the left, the current cabinet
• on the right, the current votes

Then we refined the presentation:

• perks with title and description
• minecraft colors in descriptions
• minister perks detection
• visible years
• votes shown as x/y z%
• order of candidates from highest to lowest vote

As often happens in real projects, edge cases appeared. Sometimes the election data was not where we expected it; sometimes the page displayed the previous election instead of the current one.

These types of problems are precisely where AI really saves time: not because it “guesses” the answer, but because it allows us to quickly test more robust parsing strategies until we find a consistent solution.

Bingo: convert an API into a playable card

The Bingo subpage was another of the most fun parts to build.

We didn't want to list objectives vertically. That was nothing like the actual game experience. So we turned it into a 5×5 card, visual and navigable.

We added:

• 5×5 grid
• modal by objective
• full item or objective description in the modal
• interactive hover effects
• community goal detection
• progressive coloring according to tier reached
• contextual point information
• separate navigation on its own subpage

With Bingo, more than any other module, the difference between “showing data” and “designing an experience” was clearly seen. That change in mentality was one of the best decisions of the project.

Museum: organize without cluttering

The Museum section was born as a natural necessity of the project. Once we had well-rendered items, it made perfect sense to build a dedicated browser that allowed exploration:

• What items does the Museum accept?
• how much XP does each give
• What category does it belong to?

In addition, we specifically worked to avoid unnecessary noise:

• armor set deduplication
• clean display by categories
• representative icons
• navigation from Museum to the corresponding item

And also here the nuances appeared: complete sets, main helmet icon in Museum, different ways to extract donation XP, etc.

What Codex really contributed

At this point, the contribution of AI can be summarized very well: less friction, more iteration, more consistency.

• It did not replace human judgment.
• It did not design on its own.
• It did not make important decisions without supervision.

But it did make it possible to work much faster on tasks like:

• detect patterns in inconsistent data
• propose cleaner render structures
• maintain consistency between pages
• debug small but annoying visual bugs
• adjust special cases without slowing down the pace of the project

And that has enormous value, because in projects like this the real enemy is usually not pure technical complexity, but rather the accumulated wear and tear of a hundred small details.

AI helped precisely there: in keeping the project moving.

Current result

SkyBlockCodexAPI today is no longer an idea, but a solid and functional foundation.

Currently includes:

• fast search engine
• smart suggestions
• rendering faithful to the visual language of SkyBlock
• much more player-oriented item sheets
• separate pages for Mayor, Bingo and Museum
• support for colors, perks, rarities and special formats
• clear navigation between sections
• deployment on GitHub Pages

All this without a traditional backend, maintaining a light architecture that is easy to share.

Code and application

You can access the source code at:
SkyBlockCodexAPI source code

And you have access to the application at:
Explore the museum in the app