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.