Home

ModSmith is an AI development tool that forges mod ideas into compilable, editable, runnable Fabric mods through “natural language → structured blueprint → deterministic code generation.” It provides both a CLI and a Web UI, with the Web UI offering two modes: Chat (concept Q&A) and Execute (direct generation).

1. Industry Background: The “High Barrier” Dilemma of Minecraft Mod Development

Minecraft is one of the best-selling video games in the world, and its massive player community has generated enormous demand for mods. However, mod development has long been a highly specialized task, requiring developers to master:

• Java programming and object-oriented design;
• Complex mod loader APIs (Fabric / Forge / NeoForge);
• Minecraft’s underlying mechanisms (registries, resource packs, data packs, rendering pipeline);
• The associated toolchain (Gradle, mappings and obfuscation, data generation, model JSON, etc.).

For ordinary players, content creators, or small teams without a programming background, there is a huge learning gap between “having a mod idea” and “making a playable mod.” As a result, many ideas never get past the conceptual stage, and the supply of community content is far from saturated.

2. Limitations of Existing AI Tools: The Gap from “Chat” to “Engineering”

In recent years, large language models (LLMs) have made significant progress in code generation, but applying them directly to mod development still faces three major pain points:

• API hallucination: LLMs may generate nonexistent Fabric API calls or confuse interfaces from different Minecraft versions;
• Unverifiable: Generated code often cannot compile directly and lacks a global understanding of the project structure;
• Non-editable: If users want to tweak a parameter (such as the hunger value restored by a food), they can only regenerate the entire file, with no incremental modification.

The community urgently needs a solution that can leverage LLM natural language understanding while ensuring that the output code is compilable, editable, and rollback-capable.

3. Project Positioning: An AI-Driven Mod Generation MVP

This project aims to build an AI-native development tool MVP for Minecraft Fabric mod development. Its core idea is to decouple “user intent” from “code implementation.” By introducing a structured “Mod Content Blueprint” layer, the LLM is only responsible for translating natural language into a verifiable JSON blueprint, and then a deterministic code generator translates the blueprint into complete, compilable Java/JSON project files.

The MVP uses Zhipu GLM as the LLM backend, targets Minecraft 26.2 (Fabric Loader 0.19.5), and currently supports basic, food, and tool item types.

Compared with directly letting LLMs write code, this architecture has the following advantages:

• Predictable: LLM output is constrained at the blueprint level, preventing hallucinations from directly polluting the final code;
• Verifiable: Blueprints can be strictly validated via JSON Schema, and errors can be intercepted before generation;
• Editable: Users can modify individual fields in the blueprint and regenerate, without rewriting all code;
• Extensible: The blueprint structure supports expansion from simple items to complex types such as food, tools, blocks, and entities.

4. Core Approach: Blueprint + Deterministic Generation + Dual Verification Loop

The MVP’s technical route is divided into three layers:

1. LLM parsing layer: Receives user natural language descriptions, combines the blueprint Schema and few-shot examples, and generates structured blueprint JSON;
2. Deterministic generation layer: Based on a Fabric project template and the Jinja2 template engine, translates the blueprint into Java classes, resource files, textures, etc.;
3. Dual verification layer:
   • Compile verification: Automatically runs ./gradlew build; on failure, feeds the error log back to the LLM to correct the blueprint, with up to 3 retries;
   • Runtime verification: Launches the game, parses logs, and automatically determines whether the mod loaded and items registered successfully.

5. Interaction Modes: Chat + Execute

ModSmith offers two interaction modes in both CLI and Web UI:

• Chat (concept Q&A): Acts as a “requirements consultant,” using multi-turn dialogue to help users clarify vague ideas into concrete mod descriptions. Chat does not generate code; it only outputs natural language replies and produces a structured 【Requirement Summary】 at the end.
• Execute (direct generation): Takes a clear mod description and triggers the full generation pipeline: blueprint generation → project generation → compile verification → packaging → runtime verification.

In the Web UI, Chat is the default tab, matching the product logic of “clarify first, generate later.” After chatting, users click “⚡ Summarize Requirements,” and the summary is auto-filled into the Execute description box for one-click generation.

6. Future Direction: Plan Mode

Referencing ModCrafting’s “three-mode intelligent routing” design, ModSmith’s long-term roadmap is Chat → Plan → Execute:

• Chat: Clarify requirements (“What do you want to build?”)
• Plan: Confirm the approach (“Here’s what I plan to do—does this look right?”) — not yet implemented
• Execute: Run generation (“Okay, starting now.”)

The core idea of Plan mode is to have the LLM produce a reviewable, editable structured plan before generation, including the files to create, fields, and verification steps. Users can review each item, directly modify parameters (such as duration_ticks, nutrition), and only trigger the generation pipeline after confirmation.

Why Plan is deferred in the MVP:

• Chat mode already handles “requirement confirmation,” and the 【Requirement Summary】 acts as a lightweight “plan”;
• With only basic, food, and tool item types supported, few fields need clarification, diluting Plan’s editing value;
• Implementing Plan fully requires new backend (plan generation and execution), frontend (a third tab, field-level editing), and Schema design, estimated at 5–6 days—not cost-effective for now;
• Plan will become truly valuable once block, armor, recipe, or multi-item generation is supported.

Plan is therefore listed as an explicit future direction, but is out of scope for the MVP.

7. Target Users and Expected Value

• Target users: Players with mod ideas but lacking programming ability, content creators, and students in educational settings;
• Short-term value: Has validated the complete pipeline from “natural language → compilable, runnable mod,” covering requirement clarification, blueprint generation, project compilation, packaging, and in-game log verification;
• Long-term value: Lower the barrier to mod development, unleash community creativity, and form a full-chain automation tool from idea to release—introducing Plan mode once more item types are supported to further improve control in complex scenarios.