# Scaffold

> Generate a complete, buildable Minecraft plugin project skeleton — build file (Maven or Gradle), main class, plugin.yml, resources, .gitignore, and standard source layout — from the target stack in .mcplugin/config.yml. Use this to start a brand-new plugin, create the initial project structure, or bootstrap a plugin from zero. Run /setup-platform first if the stack isn't configured yet.

- Skill: `itamarb2010-jpg/scaffold` (Agent Skill)
- Install (CLI): `npx skillmds@latest add itamarb2010-jpg/scaffold`
- Raw SKILL.md: https://api.skillmd.com/api/skills/itamarb2010-jpg/scaffold/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: itamarb2010-jpg (https://skillmd.com/u/itamarb2010-jpg)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/itamarb2010-jpg/scaffold

---


# Scaffold a plugin project

Generate a project that **compiles on the first build** and loads on the target server. Work
from the recorded stack and fill the bundled templates — don't hand-improvise build files.

## Phase 1: Load the stack

- Read `.mcplugin/config.yml`. **If it's missing**, stop and tell the user to run
  `/setup-platform` first (that skill records platform, MC version, Java, build tool, and the
  API coordinate this skill needs). Offer to run it now.
- Read the templates you'll fill (relative to this skill; `Glob` for them as a fallback):
  - `../../templates/pom.xml.template` (Maven) **or**
    `../../templates/build.gradle.kts.template` + `../../templates/settings.gradle.kts.template` (Gradle)
  - `../../templates/plugin.yml.template`
  - `../../templates/PluginMain.java.template`
  - `../../templates/gitignore.template`
- Skim `../../references/build-systems.md` so the coordinate/shading details match the stack.

## Phase 2: Confirm project identity

The identity + `plugin.yml` metadata are normally already in `.mcplugin/config.yml` (written by
`/start` or `/setup-platform`). **Read them and use them — don't re-ask what's already set.** Only
if a field is genuinely missing (an older config, or someone ran `/scaffold` first) gather it per
`../../references/project-config.md`: plugin name, base package (group id), version `[1.0.0]`,
description, author(s), optional contributors/website/prefix, and main class `[= plugin name]`.

Ensure the derived fields are present and consistent (recompute any that are missing):
- `artifact_id` = plugin name lowercased
- `package` = `group_id.artifact_id` (unless the user set an explicit package)
- `main` = `package.main_class`

Briefly restate the identity you'll generate with before writing anything.

## Phase 3: Generate the project

Create standard Maven/Gradle layout and write files by substituting every `{{TOKEN}}` in the
templates from the config + identity. Compute the token values carefully — especially
`{{PAPER_API_VERSION}}` (Maven range vs Gradle `+` differ; see `build-systems.md`) and
`{{API_VERSION}}`/`{{JAVA_VERSION}}` (from `VERSION.md`, already in the config).

For `plugin.yml`, fill `{{DESCRIPTION}}`, `{{AUTHORS}}` (comma list), `{{CONTRIBUTORS}}`,
`{{WEBSITE}}`, `{{PREFIX}}` from the config. For an empty optional field (`contributors`,
`website`, `prefix`) **keep the line present but blank** (`contributors: []`, `website: ''`,
`prefix: ''`) rather than removing it — so they're easy to fill in later. `{{PLUGIN_NAME_LOWER}}`
in the commented permission examples is the plugin name lowercased.

Layout:
```
pom.xml            OR   build.gradle.kts + settings.gradle.kts
.gitignore
src/main/java/<package path>/<MainClass>.java
src/main/resources/plugin.yml
```
Where `<package path>` is the package with dots as folders (e.g. `com/example/teleporthub`).

Show the user the file list and the filled build file + `plugin.yml` for approval **before
writing** (these are the files most sensitive to a wrong token). Then write them.

## Phase 4: Record identity + verify

- Update `.mcplugin/config.yml` with the identity fields (`plugin_name`, `group_id`,
  `artifact_id`, `package`, `main_class`, `plugin_version`, `author`, `description`) so later
  skills (`/add-command`, `/build`, …) can read them.
- Sanity-check without a full build: confirm `main` in `plugin.yml` equals
  `<package>.<MainClass>`, the Java source folder path matches the package, and the build file's
  Java/toolchain version matches `java_version`. Report the checks.

## Phase 5: Hand off

Tell the user the exact next commands, e.g.:
- "Build it: `/build` (needs JDK {{java_version}} on your PATH)."
- "Add your first command: `/add-command`, or an event listener: `/add-listener`."

Do not auto-run the build. Never fabricate a Gradle/Maven wrapper binary — if the user wants a
wrapper, tell them to run `mvn -N wrapper:wrapper` or `gradle wrapper` locally.