
minecraft-multiloader
Build and maintain Architectury-based Minecraft 26.x or 1.21.x mods that share one codebase across NeoForge and Fabric. Use only when both loaders are required; use minecraft-modding for a single-loader project.
- Installs
- 166
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/jahrome907/minecraft-agent-skills --skill minecraft-multiloader- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads minecraft-multiloader automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Minecraft Multiloader Skill (Architectury)
What Is Architectury?
Architectury is a framework that
lets you write one mod codebase that compiles to both NeoForge and Fabric JARs.
The common subproject has a shared API; platform subprojects implement
platform-specific behavior behind the @ExpectPlatform abstraction.
Routing Boundaries
Use when: one shared codebase must build and ship both NeoForge and Fabric artifacts.Do not use when: the project is single-loader only (minecraft-moddingfor NeoForge/Fabric, not both).Do not use when: the task is Paper/Bukkit plugin development (minecraft-plugin-dev).
| Component | Purpose |
|---|---|
architectury-loom | Gradle plugin — extends Fabric Loom for multiloader support |
architectury-api | Runtime library — abstractions over both platforms |
@ExpectPlatform | Annotation marking methods with platform-specific implementations |
common/ | Shared code (no loader-specific APIs) |
fabric/ | Fabric-specific code + entrypoint |
neoforge/ | NeoForge-specific code + entrypoint |
Versions (Minecraft 1.21.11)
# gradle.properties property names used by this skill's static helper.
# Get every tool version from the exact generated or known-working project.
mod_version=1.0.0
minecraft_version=1.21.11
enabled_platforms=fabric,neoforge
architectury_version=<project pin>
fabric_loader_version=<project pin>
fabric_api_version=<project pin ending in +1.21.11>
neoforge_version=<project pin in the 21.11.x family>
loom_version=<project pin>
Pin architectury_version, the Architectury plugin version, and loom_version
from the same generated or known-working project line. This skill deliberately
does not publish a copyable dependency matrix: its static helper cannot resolve
whether a particular set of versions is compatible.
For Minecraft 26.x / Java 25, use the official Architectury Template Generator only when its version selector offers the exact target. Generate a Multiplatform project with Fabric and NeoForge, then preserve the generated Gradle layout and pins as one set. If the generator does not offer the target, begin with an already working project on that exact line and inspect its resolved build; do not relabel a 1.21.11 template as 26.x. The published template downloads are not a substitute for an exact-current scaffold.
Do not mechanically change only minecraft_version in the retained example:
26.x is unobfuscated and its Loom/remapping setup differs from 1.21.11.
Bundled References And Helpers
- Version alignment reference:
references/architectury-reference.md - Sanity checker:
./scripts/check-version-sanity.sh --root <project>
Run the sanity checker after editing gradle.properties. It is a static
syntax-and-version-family preflight: it catches missing keys, snapshot pins,
missing fabric / neoforge platforms, and obvious version-family drift. It
does not resolve dependencies, prove loader compatibility, or replace the
project's Fabric and NeoForge build and smoke tests.
Root Project Layout
my-mod/
├── build.gradle ← root build (shared config)
├── settings.gradle
├── gradle.properties
├── common/
│ ├── build.gradle
│ └── src/main/java/com/example/mymod/
│ ├── MyMod.java ← shared init
│ ├── registry/
│ │ └── ModItems.java ← shared registry declarations
│ └── platform/
│ └── PlatformHelper.java ← @ExpectPlatform methods
├── fabric/
│ ├── build.gradle
│ └── src/main/
│ ├── java/com/example/mymod/fabric/
│ │ ├── MyModFabric.java ← Fabric entrypoint
│ ├── java/com/example/mymod/platform/
│ │ └── PlatformHelperImpl.java ← Fabric @ExpectPlatform implementation
│ └── resources/
│ ├── fabric.mod.json
│ └── assets/...
└── neoforge/
├── build.gradle
└── src/main/
├── java/com/example/mymod/neoforge/
│ ├── MyModNeoForge.java ← NeoForge @Mod entry
├── java/com/example/mymod/platform/
│ └── PlatformHelperImpl.java ← NeoForge @ExpectPlatform implementation
└── resources/
├── META-INF/neoforge.mods.toml
└── assets/...
Legacy Build Template
The old fixed Gradle scripts were a 1.21.11 snapshot and are intentionally not
presented as a current scaffold. For either supported version, read
references/legacy-1.21.11-template.md
or references/architectury-reference.md
before changing generated build files. They preserve version anchors and
source-set boundaries without encouraging a partial build script to be copied
into a different Minecraft line.
Shared Common Code
common/.../MyMod.java
package com.example.mymod;
import dev.architectury.registry.registries.DeferredRegister;
import dev.architectury.registry.registries.RegistrySupplier;
import net.minecraft.core.registries.Registries;
import net.minecraft.resources.Identifier;
import net.minecraft.resources.ResourceKey;
import net.minecraft.world.item.Item;
public class MyMod {
public static final String MOD_ID = "mymod";
// Architectury's DeferredRegister — works on both platforms
public static final DeferredRegister<Item> ITEMS =
DeferredRegister.create(MOD_ID, Registries.ITEM);
public static final RegistrySupplier<Item> MY_ITEM =
ITEMS.register("my_item", () -> new Item(new Item.Properties().setId(
ResourceKey.create(Registries.ITEM,
Identifier.fromNamespaceAndPath(MOD_ID, "my_item"))
)));
public static void init() {
ITEMS.register(); // registers with both platforms
}
}
@ExpectPlatform — platform-specific methods
Define the contract in common/:
package com.example.mymod.platform;
import dev.architectury.injectables.annotations.ExpectPlatform;
import net.minecraft.world.level.material.Fluid;
public class PlatformHelper {
@ExpectPlatform
public static boolean isModLoaded(String modId) {
// This body is replaced at compile time by the platform implementation
throw new AssertionError("ExpectPlatform implementation not found");
}
@ExpectPlatform
public static boolean isClient() {
throw new AssertionError();
}
}
Keep each platform implementation in the same Java package as the common
@ExpectPlatform class. Only the source set changes between common/,
fabric/, and neoforge/.
Implement in fabric/.../platform/PlatformHelperImpl.java:
package com.example.mymod.platform;
import net.fabricmc.loader.api.FabricLoader;
// Class name must match: <common class name>Impl
public class PlatformHelperImpl {
public static boolean isModLoaded(String modId) {
return FabricLoader.getInstance().isModLoaded(modId);
}
public static boolean isClient() {
return FabricLoader.getInstance().getEnvironmentType() ==
net.fabricmc.api.EnvType.CLIENT;
}
}
Implement in neoforge/.../platform/PlatformHelperImpl.java:
package com.example.mymod.platform;
import net.neoforged.fml.ModList;
import net.neoforged.fml.loading.FMLEnvironment;
public class PlatformHelperImpl {
public static boolean isModLoaded(String modId) {
return ModList.get().isLoaded(modId);
}
public static boolean isClient() {
return FMLEnvironment.dist.isClient();
}
}
Fabric Entrypoint
fabric/.../MyModFabric.java
package com.example.mymod.fabric;
import com.example.mymod.MyMod;
import net.fabricmc.api.ModInitializer;
public class MyModFabric implements ModInitializer {
@Override
public void onInitialize() {
MyMod.init();
}
}
fabric/.../resources/fabric.mod.json
This retained-1.21.11 metadata example follows the minimum dependencies in the upstream Architectury 1.21.11 branch. Keep the generated project's exact ranges when they are stricter.
{
"schemaVersion": 1,
"id": "mymod",
"version": "${version}",
"name": "My Mod",
"description": "A multiloader example mod",
"license": "MIT",
"environment": "*",
"entrypoints": {
"main": ["com.example.mymod.fabric.MyModFabric"]
},
"depends": {
"fabricloader": ">=0.18.2",
"fabric-api": ">=0.139.4+1.21.11",
"architectury": ">=19.0",
"minecraft": "~1.21.11"
}
}
NeoForge Entrypoint
neoforge/.../MyModNeoForge.java
package com.example.mymod.neoforge;
import com.example.mymod.MyMod;
import net.neoforged.bus.api.IEventBus;
import net.neoforged.fml.common.Mod;
@Mod(MyMod.MOD_ID)
public class MyModNeoForge {
public MyModNeoForge(IEventBus modEventBus) {
MyMod.init();
}
}
neoforge/.../resources/META-INF/neoforge.mods.toml
modLoader = "javafml"
loaderVersion = "[1,)"
license = "MIT"
[[mods]]
modId = "mymod"
version = "${file.jarVersion}"
displayName = "My Mod"
description = "A multiloader example mod"
[[dependencies.mymod]]
modId = "neoforge"
type = "required"
versionRange = "[21.11,)"
ordering = "NONE"
side = "BOTH"
[[dependencies.mymod]]
modId = "minecraft"
type = "required"
versionRange = "[1.21.11,1.22)"
ordering = "NONE"
side = "BOTH"
Build Commands
# Build both JARs simultaneously
./gradlew build
# Inspect the project's actual outputs. Generated templates choose their own
# archive base name and version convention:
find fabric/build/libs neoforge/build/libs -maxdepth 1 -type f -name '*.jar' \
! -name '*-sources.jar' ! -name '*-dev.jar' ! -name '*-javadoc.jar'
# Run in dev environment
./gradlew :fabric:runClient
./gradlew :neoforge:runClient
./gradlew :neoforge:runServer
# Datagen (if applicable)
./gradlew :neoforge:runData
Common Pitfalls
| Pitfall | Solution |
|---|---|
Using net.neoforged.* / net.fabricmc.* in common/ | Only use vanilla MC and Architectury APIs in common |
Direct field access on DeferredRegister (NeoForge style) in common | Use Architectury's DeferredRegister |
| Constructing a 26.x item without a registry key | Create its ResourceKey<Item> and call Item.Properties#setId before new Item |
Forgetting @ExpectPlatform throws AssertionError at runtime | Both fabric/ and neoforge/ must have matching same-package *Impl classes |
| Assets duplicated in fabric/ and neoforge/ | Keep assets in common/src/main/resources/assets/ |
| A common Mixin imports a loader API or targets one loader's side | Put it in that platform subproject; loader-neutral Mixins may be common when both generated platform configurations include them |
| Accessing world/registry on mod init thread | Use mod bus events for setup; never access world on init |
References
- Architectury API GitHub: https://github.com/architectury/architectury-api
- Architectury API 26.2 source branch: https://github.com/architectury/architectury-api/tree/26.2
- Architectury API 1.21.11 source branch: https://github.com/architectury/architectury-api/tree/1.21.11
- Architectury Loom: https://github.com/architectury/architectury-loom
- Architectury templates: https://github.com/architectury/architectury-templates
- Architectury Template Generator: https://generate.architectury.dev/
- Architectury docs: https://docs.architectury.dev/
FAQ
What does the minecraft-multiloader skill do?
Build and maintain Architectury-based Minecraft 26.x or 1.21.x mods that share one codebase across NeoForge and Fabric. Use only when both loaders are required; use minecraft-modding for a single-loader project.
How do I install minecraft-multiloader?
Run npx skills add https://github.com/jahrome907/minecraft-agent-skills --skill minecraft-multiloader in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/minecraft-multiloader/ (personal) or .claude/skills/minecraft-multiloader/ (project).
Which AI agents can use minecraft-multiloader?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is minecraft-multiloader safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains minecraft-multiloader?
It is published by jahrome907 in jahrome907/minecraft-agent-skills. It has 166 recorded installs.
More from jahrome907/minecraft-agent-skills
minecraft-modding
jahrome907/minecraft-agent-skills
Create, modify, debug, or migrate Minecraft mods for current NeoForge or Fabric 26.x, legacy 1.21.x, and Forge 1.20.1. Use for loader-based gameplay code and assets; use minecraft-multiloader when one codebase must target both modern loaders.
minecraft-testing
jahrome907/minecraft-agent-skills
Design and implement automated tests for current Minecraft 26.x or legacy 1.21.x mods and plugins using JUnit, MockBukkit, NeoForge Game Tests, or Fabric Game Tests. Use for test code and test execution, not release publishing or gameplay implementation.
minecraft-resource-pack
jahrome907/minecraft-agent-skills
Create and debug Minecraft 26.x and 1.21.x resource packs, including pack metadata, textures, models, blockstates, item definitions, sounds, fonts, animations, and shaders. Use for client-side visual or audio assets without gameplay code.
minecraft-datapack
jahrome907/minecraft-agent-skills
Create, edit, and debug vanilla Minecraft 26.x and 1.21.x datapacks, including functions, advancements, recipes, loot tables, predicates, tags, and pack metadata. Use when the deliverable is a datapack file tree without Java or loader APIs.
minecraft-server-admin
jahrome907/minecraft-agent-skills
Set up, operate, tune, and troubleshoot Minecraft Java 26.x and legacy 1.21.x servers across Paper, Purpur, Folia, Velocity, Fabric, and NeoForge. Use for infrastructure, backups, proxies, and live operations, not plugin or mod development.
minecraft-plugin-dev
jahrome907/minecraft-agent-skills
Create, modify, and debug server plugins for current Paper 26.x on Java 25 or legacy Bukkit-derived 1.21.x servers on Java 21. Use for JavaPlugin APIs, events, commands, schedulers, configuration, PDC, and Adventure, not client mods or vanilla datapacks.
Popular ai & agents skills
google-agents-cli-publish
google/agents-cli
This skill should be used when the user wants to "publish an agent", "publish my ADK agent", "register an agent with Gemini", "publish to Gemini" (formerly Gemini Enterprise), or needs guidance on the agents-cli publish gemini command. Also use when the user wants to "manage agents in Agent Registry", "list/update/delete registered agents", or "register an MCP server". Covers ADK vs A2A registration modes, programmatic and interactive usage, flag reference, auto-detection from deployment metadata, Agent Registry fleet management, and troubleshooting. Part of the agents-cli skills suite. Do NOT use for deployment (use google-agents-cli-deploy).
google-agents-cli-eval
google/agents-cli
This skill should be used when the user wants to "run an evaluation", "evaluate my agent", "evaluate my ADK agent", "write an eval dataset", "analyze eval failures", "compare eval results", "optimize agent", or needs guidance on the Gemini platform eval methodology and the Quality Flywheel. Covers eval metrics, dataset schema, LLM-as-judge scoring, and common failure causes. Applies to any agents-cli project, whatever framework the agent is written in. Do NOT use for agent API code patterns (ADK: use google-agents-cli-adk-code), deployment (use google-agents-cli-deploy), or project scaffolding (use google-agents-cli-scaffold).
skill-creator
anthropics/skills
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
codex-pet
prime-skills/runcomfy-agent-skills
Codex Pet generator on RunComfy. Build a Codex-compatible Codex Pet spritesheet.webp + pet.json from a single reference image, drop it into ${CODEXHOME:-$HOME/.codex}/pets/ / and Codex picks it up as a custom Codex Pet next to the 8 built-ins. This skill produces the exact Codex Pet atlas Codex expects (1536x1872 PNG/WebP, 8 cols x 9 rows, 192x208 cells, 9 animation states — idle, running-right, running-left, waving, jumping, failed, waiting, running, review). Calls OpenAI GPT Image 2 edit ONCE via the local RunComfy CLI as runcomfy run openai/gpt-image-2/edit to produce a canonical Codex Pet pose, then assembles all 9 animation rows programmatically with ImageMagick micro-transforms — no Codex Pro, no $imagegen, no OPENAIAPIKEY required, only RUNCOMFYTOKEN. Triggers on "codex pet", "create codex pet", "make codex pet", "hatch codex pet", "/hatch image", "desktop pet codex", "codex pets", "spritesheet.webp", or any explicit ask to build a custom pet for OpenAI Codex.
full-output-enforcement
leonxlnx/taste-skill
Overrides default LLM truncation behavior. Enforces complete code generation, bans placeholder patterns, and handles token-limit splits cleanly. Apply to any task requiring exhaustive, unabridged output.
executing-plans
obra/superpowers
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available