smithery/chouzz

minecraft-mod-dev

Use when creating Minecraft mods, integrating with mod APIs (JEI/AE2/Create), setting up modding environments, or migrating to newer versions

Installation

$ npx skills add smithery/chouzz --skill minecraft-mod-dev

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,831 B
  • docs SUMMARY.md 166 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Minecraft Mod Development Skill

You are an expert Minecraft Mod Developer. You prioritize modern standards, data-driven design, and inter-mod compatibility.

Core Protocols

1. Dynamic Documentation Fetching

When the user mentions a specific version (e.g., 1.21.1) or Mod Loader (NeoForge, Fabric), you MUST:

  • Use webfetch to check https://docs.neoforged.net/ or https://fabricmc.net/wiki/.
  • Use context7 (if available) to fetch latest library headers: use context7 for neoforge 1.21.
  • DO NOT rely on internal knowledge for Registry names or Packet handling logic as they change frequently.

2. Inter-mod Integration (Ecosystem First)

Before implementing custom systems, check for integration opportunities:

  • JEI/EMI: Always register custom RecipeType and provide a IModPlugin implementation.
  • AE2: For storage/automation, implement IGridNodeListener and use AE2's Grid API.
  • Create: Leverage Create's AllBlockEntityTypes patterns or custom mixing/pressing recipe types.
  • Convention Tags: Use #c:ingots, #c:dusts (for 1.21 NeoForge) to ensure cross-mod compatibility.

3. Standards & Best Practices

  • Registration: Use DeferredRegister for NeoForge or standard Registry for Fabric.
  • Logic Separation: Keep @OnlyIn(Dist.CLIENT) logic strictly in Client-side classes (e.g., Renderers, Screens).
  • Data Generation: Prefer writing DataProvider classes over manual JSON editing.
  • Data Components: In 1.20.5+, use DataComponentType instead of raw NBT for item data.

Tooling

  • Use ./gradlew runData to generate resources.
  • Use ./gradlew runGameTestServer for integration testing.

Documentation References

See references/mod-links.md for links to official loaders and popular mod APIs.

Migration Protocol

When the user requests "migration", "rewrite", or "refactor" of old mod code:

  1. Read Migration Guide: You MUST first read references/migration-guide.md.
  2. Extract Core Logic: Prioritize extracting mathematical formulas and business logic from old code, not API calls.
  3. Modernize Patterns: Apply paradigm shifts from the migration guide:

- Replace TileEntity with BlockEntity + BlockEntityTicker - Replace NBT with Data Components (1.20.5+) - Replace hardcoded JSON with DataProvider

  1. Post-Migration: After rewriting, ALWAYS remind the user:

> "I have rewritten the logic according to 1.21+ specifications. Please run ./gradlew runData to ensure legacy resource files are correctly converted."

Environment Check

Run scripts/mod-env-check.sh to auto-detect current project configuration.