How a custom weapons mod went from a spec file to a shipping plugin in an afternoon
Ben wanted something special for his Minecraft server — three exclusive weapons that only his players could craft. Not just reskins, but items with custom abilities, passive effects, and real gameplay weight. The catch: neither of us had written a Paper plugin before.
The project began with a spec file: BenWeapons-ClaudeCode-Spec.md. It described three weapons, their abilities, and the full Java source to implement them. Claude Code read the spec, checked prerequisites (Java 21, Maven), created the entire project directory structure, wrote all source files, and ran mvn clean package — producing a working BenWeapons.jar in a single session.
The tech stack was deliberately minimal: Java 21, Paper API 1.21.4, and Maven with no runtime dependencies beyond the server itself. The output is a single JAR that drops into any Paper server's plugins/ folder.
The spec got the plugin building, but reality pushed back immediately. Ben sent photos of his crafting screen — and the recipes were completely wrong. The original code had simple 3-item patterns; Ben's photos showed all nine crafting slots filled with rare ingredients. Player Heads in every corner. Netherite Ingots. Breeze Rods. Heavy Cores.
"The spec got the plugin building, but the photos showed what Ben actually wanted."
This back-and-forth — spec → build → photos → correction → rebuild — is exactly the kind of loop Claude Code handles well. Each change was a targeted edit to CustomWeapons.java: update the registerRecipes() method, rebuild, done. No scaffolding, no ceremony.
Cooldowns were tuned the same way — a one-line request ("mace: 15, sword: 30, axe: 25") touched four files simultaneously: the cooldown logic in CooldownManager.java, the item lore, the player activation messages in WeaponAbilityListener.java, and the spec — all in one pass.
By v1.4.0, the plugin had grown well beyond its original scope. Three weapons, each with a distinct trigger and feel:
Activated via /sword ability activate. Launches a fireball. Passive fire resistance.
Auto-triggers on hit. No button press — just swing and lightning falls. Grants Regen II.
Bound to the F key. Launches you ~30 blocks forward. Passive Speed II.
Supporting systems made it genuinely server-ready:
/trust and /untrust — weapons won't harm trusted players. Persists across restarts.
Each weapon can only be crafted once, server-wide. Tracked in crafted.yml.
Custom weapons can't be stashed in chests, hoppers, or dispensers.
/benweapons version works from console — useful for confirming the right JAR is loaded.
What made this work wasn't any single clever prompt — it was the tight loop between human judgement and execution speed. Ben knew what he wanted the weapons to feel like. Claude Code knew how to turn that into ShapedRecipe calls and PotionEffectType constants without looking anything up.
The spec file served as a shared contract. When requirements changed, updating the spec and the code in the same pass kept them from drifting apart. The JAR was always a mvn clean package away.
Total time from empty directory to shipping plugin: one afternoon.
The final BenWeapons.jar weighs 16KB. For Ben's players, it's three weapons unlike anything in vanilla Minecraft. For the rest of us, it's a decent illustration of what human-AI pair programming looks like when it's working.
View the full source on GitHub → · Back to the plugin page →