← All craftbooks

Scaffold a Mod

Home and everyday lifeevalv1.0.0released 2026-06-05workflow: build-loop

Steps

Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.

1. Scope the modmodmakerentry

   the idea, the target version, the structure rules locked

   Show working prompt

   Define the mod before creating a single file. Step 1: state the mod's core idea in one sentence — the thing that should happen in the game — and the target game version it must run on. Step 2: lock the structure rules for that version — the pack_format number pack.mcmeta must carry for the target version (from the project's version notes when present, stated explicitly either way), the namespace for this mod (short, lowercase, no spaces), and the folder layout the version expects under data/ for the mechanics the idea needs (functions, recipes, advancements, tags). Step 3: decide the one working example that proves the core idea end to end — the smallest set of files that makes the thing actually happen in-game. Step 4: write an acceptance-criteria checklist ('pack.mcmeta is valid JSON with the right pack_format for the target version', 'all content lives under the namespaced folders', 'the working example is complete — every file it needs exists', 'README has install steps and a test step a kid can follow'). Call write_task_note with the idea + version + pack_format + checklist and write notes/scope.md.

2. Scaffold the datapackdeveloper

   pack.mcmeta plus the namespaced tree with one working example

   Show working prompt

   Build the datapack tree against the locked rules. Step 1: write pack.mcmeta at the workspace root — valid JSON with the pack object carrying the pack_format number locked in scope and a one-line description of the mod. Step 2: lay out the namespaced tree under data/ exactly as the target version expects, and build the working example — every function, recipe, advancement, or tag file the core idea needs, each in its right folder with its right name; a scaffold whose example is missing a file teaches a kid that mods do not work. Step 3: use the version's correct folder names and identifier syntax throughout — one renamed folder between versions is the classic silent break, so double-check against the structure rules from scope. Step 4: re-read every JSON file for validity and every function file for command syntax. Call write_task_note with the file count and the namespace.

3. Write the READMEcopywriter

   install and test steps a twelve-year-old can follow

   Show working prompt

   Write the README that gets the mod into the game. Step 1: open with what the mod does, in one line a kid would repeat to a friend. Step 2: write the install steps — where the datapack folder goes for the target version, written concretely for the platform, one action per step, no step assuming knowledge the last step did not give. Step 3: write the test step — exactly what to do in-game to see the mod work, and exactly what should happen when it does. Step 4: add the version note — which game version this pack targets and the one-line warning that other versions may need a different format number. Write README.md and call write_task_note with the README path and the test step in one line.

4. Evaluatereviewer

   Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.

   Show working prompt

   Open pack.mcmeta, walk the tree under data/, and read README.md against every criterion from notes/scope.md: pack.mcmeta is valid JSON carrying the pack_format locked for the target version, all content sits under the namespaced folders with the version's correct folder names, the working example is complete — trace the core idea file by file and confirm every reference resolves — and the README's install and test steps are concrete enough for a twelve-year-old to follow without help. Write PASS/FAIL per criterion; on any failure, name the missing or misplaced file and loop back to scaffold.
   
   Then route — this is the whole point of the loop:
   
   - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`.
   - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "scaffold" })` to loop back. The builder fixes exactly those gaps.
   
   Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.

5. Finishdeveloper

   All acceptance criteria met. Stamp a short summary and report DONE.

   Show working prompt

   Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.

Triggers

Phrases that suggest this craftbook to a crew.

• scaffold a mod
• start a datapack
• make a minecraft mod
• set up the datapack
• my kid wants a mod

Source

View this craftbook on GitHub · MIT license