Minecraft Plugin Development

Minecraft Plugin Development

Use this skill for Minecraft server plugin work in the Paper, Spigot, and Bukkit ecosystem.

This skill is especially useful for gameplay-heavy plugins such as combat systems, wave or boss encounters, war or team modes, arenas, kit systems, cooldown-based abilities, scoreboards, and config-driven game rules.

For grounded implementation patterns drawn from real Paper plugins, load these references as needed:

• `references/project-patterns.md` for high-level architecture patterns seen in real gameplay plugins
• `references/bootstrap-registration.md` for onEnable, command wiring, listener registration, and shutdown expectations
• `references/state-sessions-and-phases.md` for player session modeling, game phases, match state, and reconnect-safe logic
• `references/config-data-and-async.md` for config managers, database-backed player data, async flushes, and UI refresh tasks
• `references/maps-heroes-and-feature-modules.md` for map rotation, hero or class systems, and modular feature growth
• `references/minigame-instance-flow.md` for arena instances, countdowns, loot refreshes, wave systems, visibility isolation, and entity-to-game ownership
• `references/persistent-progression-and-events.md` for long-running PvP servers with profiles, perks, buffs, quests, economy, custom domain events, and extension registries
• `references/build-test-and-runtime-validation.md` for Maven or Gradle packaging, shaded dependencies, generated resources, soft dependencies, config validation commands, and first-round server test plans

Scope

• In scope: Paper, Spigot, Bukkit plugin development
• In scope: plugin.yml, commands, tab completion, listeners, schedulers, configs, permissions, Adventure text, player state, minigame flow, arena instances, map copies, loot, waves, persistent profiles, perks, buffs, quests, economy, and PvP/PvE game loops
• In scope: Java-based server plugin architecture, debugging, refactoring, and feature implementation
• Out of scope by default: Fabric mods, Forge mods, client mods, Bedrock add-ons

If the user says "Minecraft plugin" but the stack is unclear, first determine whether the project is Paper/Spigot/Bukkit or a modding stack.

Default Working Style

When this skill triggers:

1. Identify the server API and version target.
2. Identify the build system and Java version.
3. Inspect plugin.yml, the main plugin class, and command or listener registration.
4. Map the gameplay flow before editing code:

• player lifecycle
• game phases
• timers and scheduled tasks
• team, arena, or match state
• config and persistence

1. Make the smallest coherent change that keeps registration, config, and runtime behavior aligned.

If the plugin is gameplay-heavy or stateful, read `references/project-patterns.md` and `references/state-sessions-and-phases.md` before editing.

If the task touches arena isolation, map instances, chest or resource refills, wave spawning, route voting, spectator visibility, or game-specific chat, also read `references/minigame-instance-flow.md`.

If the task touches persistent player progression, profile saves, economy rewards, perks, buffs, quests, custom combat events, or long-running shared PvP servers, also read `references/persistent-progression-and-events.md`.

If the task touches build files, plugin.yml metadata, shaded dependencies, generated resource output, deployment to a test server, optional plugin integrations, or release validation, also read `references/build-test-and-runtime-validation.md`.

Project Discovery Checklist

Check these first when present:

• plugin.yml
• pom.xml, build.gradle, or build.gradle.kts
• the plugin main class extending JavaPlugin
• command executors and tab completers
• listener classes
• config bootstrap code for config.yml, messages, kits, arenas, or custom YAML files
• generated resource output such as target/classes, build/resources, or copied plugin jars
• scheduler usage through Bukkit scheduler APIs
• any player data, team state, arena state, or match state containers

Core Rules

Prefer the concrete server API in the repo

• If the project already targets Paper APIs, keep using Paper-first APIs instead of downgrading to generic Bukkit unless compatibility is explicitly required.
• Do not assume an API exists across all versions. Check the existing dependency and surrounding code style first.

Keep registration in sync

When adding commands, permissions, or listeners, update the relevant registration points in the same change:

• plugin.yml
• plugin startup registration in onEnable
• any permission checks in code
• any related config or message keys

Respect main-thread boundaries

• Do not touch world state, entities, inventories, scoreboards, or most Bukkit API objects from async tasks unless the API explicitly permits it.
• Use async tasks for external I/O, heavy computation, or database work, then switch back to the main thread before applying gameplay changes.

Model gameplay as state, not scattered booleans

For gameplay plugins, prefer explicit state objects over duplicated flags:

• match or game phase
• player role or class
• cooldown state
• team membership
• arena assignment
• alive, eliminated, spectating, or queued state

When the feature affects match-heavy minigames or persistent-brawl gameplay, look for hidden state transitions first before patching symptoms.

For multi-arena plugins, isolate per-game visibility, chat recipients, scoreboards, loot, and entity ownership. Do not let one arena observe or mutate another arena by accident.

Favor config-driven values

When the feature includes damage, cooldowns, rewards, durations, messages, map settings, or toggles:

• prefer config-backed values over hardcoding
• provide sensible defaults
• keep key names stable and readable
• validate or sanitize missing values

Be careful with reload behavior

• Avoid promising safe hot reload unless the code already supports it well.
• On config reload, ensure in-memory caches, scheduled tasks, and gameplay state are handled consistently.

Implementation Patterns

Commands

For new commands:

• add the command to plugin.yml
• implement executor and tab completion when needed
• validate sender type before casting to Player
• separate parsing, permission checks, and gameplay logic
• send clear player-facing feedback for invalid usage

Minimal registration shape:

commands:
  arena:
    description: Join or leave an arena
    usage: /arena <join|leave>

@Override
public void onEnable() {
    ArenaCommand command = new ArenaCommand(gameService);
    PluginCommand arena = getCommand("arena");
    if (arena != null) {
        arena.setExecutor(command);
        arena.setTabCompleter(command);
    }
}

Listeners

For event listeners:

• guard early and return early
• check whether the current player, arena, or game phase should handle the event
• avoid doing expensive work in hot events such as move, damage, or interact spam
• centralize repeated checks where practical

Scheduled Tasks

For timers, rounds, countdowns, cooldowns, or periodic checks:

• store task handles when cancellation matters
• cancel tasks on plugin disable and when a match or arena ends
• avoid multiple overlapping tasks for the same gameplay concern unless explicitly intended