Releasing

Releases come from the “Release” workflow on GitHub. Nothing in the repository holds the version: the workflow takes it as input.

1. Write the notes. Add a ## X.Y.Z section to CHANGELOG.md, written for server owners, and push it. Patch for fixes, minor for features, major for breaking changes.

2. Run the workflow:

   gh workflow run release.yml -R MairwunNx/moafks -f version=X.Y.Z -f modrinth=true -f hangar=true

   Its changelog field overrides the CHANGELOG.md section. One of the two must be there.

3. Watch it: gh run watch.

The workflow builds the jar, tags vX.Y.Z, and attaches moafks-X.Y.Z.jar and a version-less moafks.jar to a GitHub release.

The stores

• Modrinth (moafks): the modrinth switch uploads the jar and syncs MODRINTH.md as the project page. It needs the MODRINTH_TOKEN secret.
• Hangar (MairwunNx/MoAfks): the hangar switch uploads the jar to the Release channel. Hangar doesn’t sync the page, so edit it on the site after a big change. It needs the HANGAR_TOKEN secret.

Moonlands

The moonlands switch, on by default, starts ship-plugin.yml in MairwunNx/minecraft with the FAMILY_ACTIONS_TOKEN secret. That workflow puts the new jar on the Moonlands server.

The autopilot

.github/workflows/autopilot.yml runs Claude every Monday at 03:00 UTC. It updates the dependencies and the game version, fixes what breaks, pushes, and runs the “Release” workflow with every store when what the plugin ships changed. It needs the CLAUDE_CODE_OAUTH_TOKEN secret.