game_modding_workflow v1.0.0

name: game_modding_workflow description: "Mod a PC game you own, end to end: engine and version recon, mod loader and anti-cheat checks before any change, save and install backups, one small working slice first, asset conversion to engine formats, in-game verification with screenshots, packaging with install instructions and credits, and a field note. Use when planning, building, testing, or packaging a game mod on any engine."

Game Modding Workflow

Purpose

Take one mod from idea to a packaged file another player can install, without wrecking the install, a save, or an account. The workflow is service neutral. It does not depend on one mod site, one manager, or one asset service. Pick the loader and host the specific game actually uses.

The order matters: recon first, risk gate second, backups third, one small slice fourth. Most modding damage comes from skipping the first three and building on a game version, loader, or save that was never safe to touch.

Workflow

1. Recon the game before touching it. Fill the recon checklist in references/recon-checklist.md. Record game title, store, exact version or build, install path, save path, and config path. Identify the engine from real clues, not a guess: a Managed folder points to Unity Mono, il2cpp_data points to Unity IL2CPP, .pak files and Content/Paks point to Unreal, a Data folder with .esm/.esp plugins points to Bethesda Creation Engine, .vpk files point to Source. Note whether an official editor or mod tool exists for that exact game.

1. Run the anti-cheat and online risk gate. Look for anti-cheat in the install folder, the store page, and the publisher support pages. If the game has online, ranked, or shared world play, read the publisher rule on mods before proceeding. Default verdicts: a game with an officially supported mod mode or offline mode gets modded in that mode only. A game where mods are not addressed gets modded on a separate install or profile, kept offline. A game where the publisher bans mods in the mode you would play is not modded in that mode at all. Never present a bypass for anti-cheat, and never test a modded build on a live account you care about. Write the verdict in the field note.

1. Set up the safe lab. Scaffold it with the bundled script: python3 scripts/mod_lab.py init <lab_dir>. Copy, do not move, the saves into 00-backup-saves. Write a vanilla manifest before any change: python3 scripts/mod_lab.py manifest <game_install_or_data_folder> <lab_dir>/01-vanilla-snapshots/vanilla.csv. The manifest records relative path, size, and SHA256 for every file, so later you can prove what changed. Then confirm the clean restore path works in principle: Steam verify (Library, right click the game, Properties, Installed Files, Verify integrity of game files), a mod manager profile you can switch off, or removing the loader returns the game to vanilla.

1. Choose the loading route the game supports, in this order: in game mod menu or Steam Workshop if the game ships one, then a mod manager (Mod Organizer 2 keeps mods in separate folders and presents them through a virtual file system, so the real game folder stays clean; Vortex deploys files and sorts plugins with LOOT rules), then a code loader (BepInEx for Unity: match x86 or x64 to the executable, extract into the game root, run once so it generates BepInEx/config and LogOutput.log, then place plugins in BepInEx/plugins), then loose file replacement as a last resort with a manifest diff to track it. Pin the loader version in the field note. Do not mix two managers on one install.

1. Build one small working slice first. The slice is the smallest change that proves the whole chain: one recolor, one stat edit, one new item, one short script. Not a pack, not an overhaul. Build it, load it, see it in game. If the slice does not load, stop and debug the chain (wrong engine version, wrong folder, wrong load order, loader log errors) before making more content. Scaling a broken chain only makes a bigger broken mod.

1. Convert assets into the engine format the game reads. Work from a clean source file you keep (PNG or TGA for textures, FBX or OBJ for meshes, WAV for audio) and export the engine copy from it, never the other way round. Typical targets: DDS textures and engine native meshes for Bethesda titles, cooked .uasset content packed in a .pak for Unreal (UnrealPak or editor DLC cooking, cooked per platform, with the same internal path and name as an asset it replaces), plugin .dll files for Unity loaders, .vpk packages for Source. Use the short per engine entries in references/engine-playbooks.md. Record every conversion setting that mattered (size, compression, skeleton, engine version) in the field note, because the next asset will need the same settings.

1. Respect load order and conflicts. Where plugins exist, later loads win a direct conflict on the same record. Sort with LOOT where it applies, read its messages instead of blindly applying, and check remaining conflicts in the engine editor or xEdit style tool. One mod per test run when adding to an existing list, so a crash has one suspect. Never add or remove record heavy plugins mid playthrough on a save you intend to keep; test those on a throwaway save.

1. Verify in game with evidence. Launch through the same route a user will use (manager profile or loader, not a developer shortcut). Confirm the change appears, play the slice for several minutes, save, reload that save, and quit cleanly. Capture before and after screenshots into the lab screenshots folders, named with the mod version. Read the loader or game log after the run (for BepInEx, BepInEx/LogOutput.log) and note any error lines, even if the game seemed fine. A mod that works once but errors on reload is not done.

1. Package only what the mod needs. Build the dist folder from a clean list: mod files in the exact relative layout the loader expects, README.md, CREDITS.txt. Run python3 scripts/mod_lab.py check-pack <dist_dir> and fix every failure it prints. The README must state what the mod does, game version it was tested on, requirements, install steps in order, how to confirm it loaded, uninstall steps that remove every added file, and known conflicts. Do not ship executables or scripts in a pack without a plain explanation of what they do. Zip the dist folder contents, not a parent folder with a second nested copy inside.

1. Credit and check permissions before any upload. List every asset, code fragment, and tool output that is not your original work in CREDITS.txt, with author and source. Nexus Mods rules, which state the common standard well: permissions are file specific, only the original author sets them, crediting does not by itself grant use, and if a file states no permission, assume you must ask the author first. Keep the permission messages. Your own game files stay out of the pack: never redistribute base game assets, only your changed or new files.

1. Write the field note the same day. Complete field-notes.md from the lab scaffold: engine and how you confirmed it, loader and version, anti-cheat verdict, slice result, what failed with the exact symptom, conversion settings, load order notes, screenshot file names. The next mod, by you or anyone else, starts from this note instead of from memory.

Worked example, a Unity recolor slice end to end: recon finds il2cpp_data, so the IL2CPP loader build is required. Risk gate: single player, no anti-cheat found in the install or publisher pages, verdict is mod this install. Lab is scaffolded, saves copied, manifest written. Loader installed, first run generates its config and log. Slice: one texture swapped in a test plugin, game launched, new color visible on the item, screenshot saved to screenshots/after, log checked with no errors, save reloaded successfully. Only then are the remaining textures converted with the same settings, the pack checked, credits written, and the field note closed out.

Output Contract

• A completed recon checklist with engine evidence and a written anti-cheat verdict.
• A lab folder with save backups, a vanilla manifest CSV, before and after screenshots, and a completed field note.
• A working slice proven in game before any larger build, with the log file checked.
• A packaged mod: a zip whose contents pass scripts/mod_lab.py check-pack, with README install and uninstall steps and a CREDITS file covering every borrowed asset.
• A test record stating game version, loader version, load order position if relevant, and the save and reload result.

Operating Rules

• Back up saves and write the vanilla manifest before the first file change. No exceptions, even for a tiny edit.
• Quality and safety beat speed. If the anti-cheat or publisher position is unclear, treat the install as online and do not mod it until it is clear.
• Never bypass, disable, or hide a mod from anti-cheat, and never help test mods in a mode the publisher has ruled out.
• Never redistribute base game files or another author work without permission. Credit is required, and credit alone is not permission.
• Test on a throwaway save when plugins are added or removed. An existing long save is not a test bed.
• One change per test run after the slice. A crash report that says everything changed proves nothing.
• Pin versions everywhere: game build, loader, editor, and your mod version go in the README and the field note.
• Keep source assets separate from engine exports. Rebuild the export from source, do not edit the export as the master.
• If a step cannot be verified in game, say so plainly in the field note instead of marking the mod done.

Available connectors

• Use muse.connector_search to find other connectors and muse.skill_search to find related skills.

• If nothing here fits, look on the web for a maintained API or MCP server and set it up with the custom connector setup skill, or build a custom connector.