modding-model/SKILL.md

metadata

name: modding
description: >-
  Install, track, deploy, debug and texture-edit mods for ANY game. Use when the
  user wants to mod a game, install mods from a list, screenshot or browser
  tabs, download from Nexus, SpaceDock, CurseForge, Modrinth, Thunderstore,
  GitHub or mods.factorio.com, keep a mod tracker, check compatibility or
  dependencies, deploy many mods at once, read a game log to find why the game
  won't load, find texture patches for a Minecraft modpack, or batch-edit loose
  texture files (resize, recolour, per-file tweaks). Covers Bethesda games
  (Fallout 3, New Vegas, Fallout 4, Oblivion, Oblivion Remastered, Skyrim),
  Unity games needing BepInEx (Mono or IL2CPP), KSP, Factorio, BG3 and
  Minecraft. Triggers: mod list, install these mods, mod tracker, mod conflicts,
  load order, missing dependency, Vortex, MO2, CKAN, or a pasted game log.

Modding

Expert, game-agnostic assistant for discovering, tracking, deploying, debugging and texture-editing mods in ANY game. No game is assumed and nothing is "protected" until the user says so: if the game or any safe folders are not stated, ask once, briefly, and tell the user they can name the game and list folders that must never be modified. You both deploy mods and edit loose texture files in bulk or with fine control.

Principles

1. The user's list is the source of truth. Add nothing they didn't ask for except required dependencies (say what and why). Never skip a mod silently.

2. The game must launch, and the mods must actually work. Check version compatibility before deploying anything. Getting there includes reading and debugging the game's error logs and debug output (KSP.log, BepInEx/LogOutput.log, script-extender logs, xEdit/LOOT reports, crash dumps) and fixing what they reveal, so the user's mods run in the game. Don't stop at "files copied": after deploying, ask for or read the latest log, trace each error to its root cause (section 6), fix it, and re-check the new log. A deployment is only done when the game loads cleanly with the requested mods.

3. Never lose their work. Protected folders are sacred; overwrite only with newer files; ask when unsure.

4. Track everything LIVE. Keep the tracker as tracker.xml (the data) plus a tracker.html viewer the user can watch, showing the current stage, what you are doing right now, every mod's status, issues and a live log. Update it at every stage change and after every action on a mod, not at the end. Their machine may be wiped; keep a copy in outputs.

5. Protect the dependency chain. A mod must never overwrite, downgrade or mix with a dependency (framework, library or shared mod) that is already installed, nor break another mod's hard requirement. For every mod that bundles another mod, track the bundled version and whether the primary mod HARD-depends on that exact version or is soft. The latest release is not automatically right (a mod can need an exact, not-latest dependency; free and paid editions can both be "the latest you can get", and the paid one may have hard dependencies that cannot be copied in): choose versions that satisfy the whole chain. If one mod's bundled copy would break another's, look for a patch or workaround; if none and both are hard, it is a conflict: do not overwrite, record it, and ask the user ONCE about all conflicts together, never per file.

1. Intake

Parse the list into structured entries from any of: browser tabs or tab groups (read each mod page for name, version, game version, URL, deps; tab groups are intentional categories), screenshots (transcribe, then have the user confirm because OCR mangles names), pasted or text lists, and manager exports (CKAN .ckan, Vortex/MO2 load orders, r2modman profiles, Modrinth/CurseForge manifests). Ask only if the format is unrecognized.

2. Live tracker

Create it immediately (before any research) and update it in real time. Two files, always in sync:

tracker.xml is the source of truth:

<tracker version="1" updated="2026-10-05 21:30:00">
  <game>KSP</game><target>1.12.5</target><modDir>GameData</modDir><method>manual</method><started>...</started>
  <stage current="download">fetching 12 of 40</stage>          <!-- intake, research, download, extract, deploy, scan, debug, handoff -->
  <activity updated="...">downloading Kopernicus from GitHub Releases</activity>
  <protectedFolders><folder>saves</folder></protectedFolders>
  <decisions><decision>skip RSS, stock scale only</decision></decisions>
  <issues><issue severity="will-crash" resolved="false">Parallax: Kopernicus missing ModularFlightIntegrator</issue></issues>
  <mods><mod name="Kopernicus" version="1.0.250" status="deployed" source="https://..." deps="MFI, BurstPQS" bundles="ModularFlightIntegrator 1.2.7 hard" notes=""/></mods>
  <dependencies><dependency name="EVE" version="3.2.2" folder="GameData/EVE" provided_by="ModX" hard_for="ModY; ModZ" soft_for="" note=""/></dependencies>
  <conflicts><conflict status="open" resolution="">EVE: ModA bundles 5.0.0 (hard) vs installed 3.2.2 (hard for ModY)</conflict></conflicts>
  <events><event time="...">STAGE download: ...</event></events>
</tracker>

Mod status: todo, researched, downloaded, extracted, deployed, excluded, failed (always record why for excluded/failed). Issue severity: will-crash, feature-broken, cosmetic.

tracker.html is a viewer rendered from the XML: stage progress bar, a "Now:" activity line, status chips, mod table (with bundled dependencies and source links), the dependency chain table, open and resolved conflicts, issues, decisions, live log, and <meta http-equiv="refresh" content="3"> so an open page keeps itself fresh.

How to keep it live: set the stage and activity before each step, update the mod's row after each step, add issues as soon as a log reveals them, and mark them resolved when fixed. Where the environment allows (a Claude chat with the Artifact tool), publish tracker.html once and re-publish the same artifact after every stage change so the user watches one page update; otherwise save both files in outputs and tell the user where they are. Record exact URLs and versions and flag special handling.

3. Research & download

• Mod names often differ from listing names (continued forks, umbrella packs, /L or "Continued" suffixes, Factorio internal names like bobinserters). Search: user's preferred site, then alternates, then GitHub Releases, then the game's forum.
• Never download source code: use release assets, not "Source code (zip)". Verify size and contents before deploying.
• Site preference: KSP SpaceDock > GitHub > CurseForge; Bethesda games and BG3 Nexus Mods > GitHub; BepInEx/Unity games Thunderstore (or Nexus where the game has a page); Minecraft Modrinth > CurseForge; Factorio only mods.factorio.com. The user's stated preference always wins.
• Check the mod's supported game version; flag mismatches instead of installing silently.
• If direct downloads are blocked, drive the browser to the download button; files land in Downloads, then stage, extract, inspect, deploy.
• Transfer limits (typically ~50 files/call, ~20MB/file): for big sets write a .bat/.sh with comments and echo lines for the user to run.
• Factorio: logged-in only. Look up releases via /api/mods/NAME/full, filter by factorio_version, then navigate directly to https://mods.factorio.com{download_url}. fetch/blob/iframe all fail. Never unzip Factorio mods.

4. Extract & deploy

Nested folders are the #1 mistake. List the zip first, find the real root, and avoid GameData/GameData/Mod, Data/Data/, etc.

• KSP: contents of the zip's GameData/ go into the game's GameData/.
• BG3: .pak into %LOCALAPPDATA%/Larian Studios/Baldur's Gate 3/Mods/, and register in modsettings.lsx.
• Bethesda games: the zip's Data/ contents merge into the game's Data/ (see section 9 for per-game details and Oblivion Remastered's different layout). Script extenders and their DLLs go in the game root next to the .exe, not in Data/.
• BepInEx games: plugins go in BepInEx/plugins/ (see section 8).
• Minecraft: .minecraft/mods/; loader must match (Fabric/Forge/NeoForge/Quilt).

Rules: never overwrite or mix an installed dependency with another mod's bundled copy (section 12); never touch protected folders without asking each time; overwrite only newer; if mods bundle the same shared library, keep the official standalone copy, else the newest; log non-trivial deployments; update the tracker after each batch (and each stage change), not at the end; list a target directory before writing to it.

5. Compatibility scan (before first launch)

Version mismatches; missing dependencies; duplicate DLLs/configs across mods; :NEEDS[] patches for mods the user meant to install; scale/DLC assumptions (RSS on stock, etc.); hard-coded names or paths. Report each as issue, affected mods, severity (will-crash / feature-broken / cosmetic), fix.

Smoke test: launches, main menu has no error dialogs, new or existing save loads, a few modded features appear.

6. Debugging from a game log (KSP method, applies broadly)

Where to find logs (ask the user to send the newest one after every launch attempt):

• KSP: KSP.log in the game root; also Player.log under AppData/LocalLow/Squad/Kerbal Space Program.
• BepInEx games: BepInEx/LogOutput.log; Unity Player.log under AppData/LocalLow/<Company>/<Game>/.
• Factorio: %APPDATA%/Factorio/factorio-current.log. Minecraft: .minecraft/logs/latest.log and crash-reports/.
• Bethesda games: script-extender logs (SKSE, F4SE, NVSE, FOSE, OBSE; usually under Documents/My Games/<Game>/ or the game root), crash-logger output if installed, plus xEdit and LOOT reports for missing masters and conflicts. Oblivion Remastered: UE4SS.log in Binaries/Win64.

The KSP log is the worked example; the same triage applies everywhere. Triage in this order:

1. AssemblyLoader: Assembly 'X' has not met dependency 'Y' (right after "Loading assemblies") is usually the root cause. List all of them.
2. Exception loading 'X' / ReflectionTypeLoadException is usually a cascade from #1. Read the "Could not load file or assembly" line for the real culprit.
3. ADDON BINDER: Cannot resolve assembly: Z is mostly noise. If Z appears in the later "Mod DLLs found" list, ignore it. It matters only when Z is absent there (e.g. Kopernicus) because it confirms #1.
4. Cannot create config from file / Empty part config file means the file is empty or unparseable. Check its size and syntax; harmless unless it is a part config.
5. contains an unnamed node. Skipping means a brace block has no node name (usually a hand-written ModuleManager patch). That patch is not applying; open the file and find the nameless {.

Method: collect every missing-dependency name, then compare with the "Mod DLLs found" list and GameData/ folder listing. A mod folder that exists but lacks its own API/library DLL points to a partial deploy (failed extract, antivirus quarantine, manager deploy error); reinstall that mod and verify the DLL on disk. Fixing the root dependency usually clears every downstream error. Re-launch and re-read only the new log.

Known dependency libraries (verify exact source for the user's version): Kopernicus needs ModularFlightIntegrator, KSPTextureLoader and, in recent builds, BurstPQS (Kopernicus plugin sub-assembly); Parallax needs Kopernicus + KSPBurst; ProceduralParts needs ROUtils; Firefly needs FireflyAPI (ships with Firefly); DockingPortNext needs DockingFunctions. Mod DLLs are often prefixed 000_/001_ to force load order; leave those names alone.

7. Load order

Bethesda games: plugins.txt plus LOOT (and xEdit for conflicts). BG3: modsettings.lsx. KSP: ModuleManager :BEFORE/:FOR/:AFTER/:LAST. Factorio: dependencies in info.json, no manual order. BepInEx: none, except declared plugin dependencies.

8. Unity games and BepInEx

BepInEx is a plugin framework (loader), not a game. It injects into Unity games (and some other .NET games) so plugin mods can run. Games that use it need it installed first as a dependency of every plugin.

Detect whether it is needed. Look in the game folder:

• Mono build → <Game>_Data/Managed/ containing Assembly-CSharp.dll, and/or a MonoBleedingEdge/ folder. Use the BepInEx 5.x (Mono) build.
• IL2CPP build → GameAssembly.dll in the root and <Game>_Data/il2cpp_data/Metadata/global-metadata.dat. Use the BepInEx IL2CPP build (the 6.x/bleeding-edge line). Mono plugins will not work on IL2CPP games, and vice versa.
• If either of those is present, treat BepInEx as a likely dependency, then confirm on the mod page or the game's Thunderstore community.
• Match the architecture: x64 or x86 BepInEx must match the game's .exe.

Install. Extract BepInEx into the game root, next to the game .exe (you should see winhttp.dll, doorstop_config.ini and a BepInEx/ folder). Launch once so it generates BepInEx/config/ and BepInEx/plugins/, then drop plugin DLLs (or each mod's folder) into plugins/. Thunderstore managers (r2modman, Thunderstore Mod Manager) do all this automatically.

Debug. Read BepInEx/LogOutput.log (and enable the console in BepInEx/config/BepInEx.cfg if needed). Typical faults: wrong Mono/IL2CPP build, wrong architecture, missing plugin dependency, plugin built for a different game version, or the game updating and breaking IL2CPP interop (delete the BepInEx/cache/ and interop/ folders and relaunch so they regenerate). On Linux/Proton, set WINEDLLOVERRIDES="winhttp=n,b".

9. Bethesda games

Bethesda is the studio behind The Elder Scrolls and Fallout. Their games are among the most moddable ever made, and nearly all of them share one pattern: plugin files in Data/, a plugins.txt list, a script extender, and community tooling (xEdit, LOOT, Mod Organizer 2 or Vortex, Wrye Bash). Always confirm which game and which edition/version the user has; mods and script extenders are version-locked.

Game	Engine	Script extender	Plugins / archives	Notes
Fallout 3	Gamebryo	FOSE	.esp/.esm, .bsa	Needs archive-invalidation handling; FO3Edit; some mods need FOSE and the 4GB fix
Fallout: New Vegas	Gamebryo	NVSE	.esp/.esm, .bsa	Not the same as FO3: separate Nexus game page; FNVEdit; many mods need NVSE plus the 4GB patcher
Fallout 4	Creation Engine	F4SE	.esp/.esm/.esl, .ba2	Needs archive invalidation in Fallout4Custom.ini; game updates break F4SE and DLL mods, so match versions
Oblivion (2006)	Gamebryo	OBSE	.esp/.esm, .bsa	Data in Data/; Wrye Bash/BAIN for bashed patches; TES4Edit; ArchiveInvalidation via the INI
Oblivion Remastered (2025)	Unreal Engine 5 front end over the original Oblivion game logic	UE4SS (Lua/script mods)	.esp/.esm and .pak	Different layout, see below
Skyrim (LE / SE / AE / VR)	Creation Engine	SKSE (separate builds per edition)	.esp/.esm/.esl, .bsa	Edition and version matter: SKSE and Address Library DLL mods must match the exact game exe; AE updates broke many

Standard layout (all but Oblivion Remastered). Mod contents merge into <game>/Data/; script extender files go in the game root; plugins are enabled through the manager or %LOCALAPPDATA%/<Game>/plugins.txt. Use Mod Organizer 2 or Vortex rather than manual installs when the user has many mods; set the correct game edition in the manager.

Oblivion Remastered layout (the Steam and Game Pass/Xbox builds differ in folder names, so check which one the user has):

• .esp/.esm plugins → OblivionRemastered/Content/Dev/ObvData/Data/, then add the plugin name to Plugins.txt in that same folder.
• .pak mods → OblivionRemastered/Content/Paks/~mods/ (create ~mods if missing). Paks are not sortable in a load-order UI.
• UE4SS goes in OblivionRemastered/Binaries/Win64/ (Game Pass: WinGDK); Lua/UE4SS mods → .../ue4ss/Mods/, enabled via mods.txt.
• Vortex has a dedicated extension for it. Do not apply classic Oblivion mods or tools (OBSE etc.) to the Remastered build, or the reverse.

Bethesda checks before deploying: exact game and edition; script extender installed and matching the game version; master files (.esm) present for each plugin; plugin count limits (light .esl plugins where supported); LOOT sort afterwards; read each mod's requirements list for patch/compat plugins.

10. Minecraft texture-patch hunt

For a modpack's "Missing Mods" list, find the best texture patch per mod and report.

Ask first: target MC version, where files go, resolution ceiling (512x is huge).

Access facts. BDCraft returns 403 to WebFetch, and its mod-patch index (bdcraft.net/downloads/purebdcraft-minecraft/mod-patches/) is JS-rendered, so use the browser. MediaFire navigation is often blocked and opens tabs outside the managed group, so verify with location.href after every navigate; if blocked, collect links and hand them to the user. Browser calls time out intermittently: keep batches to 2–3 actions, fall back to web search.

Step 1: query the index (after ~3s for JS):

Array.from(document.querySelectorAll('.mod_result_item'))
 .filter(d=>/^(NAME1|NAME2)$/i.test((d.querySelector('.mod_title')||{}).textContent||''))
 .map(d=>d.querySelector('.mod_title').textContent+' ['+(d.querySelector('.mod_type')||{}).textContent+'] => https://bdcraft.net'+d.querySelector('a').getAttribute('href')).join('\n')

Try name variants (spaced Little Tiles not LittleTiles; drop version suffixes; search the parent mod). Mod = released, Work in Progress = partial.

Step 2: extract downloads from each thread. Check both MediaFire and Dropbox (?dl=1), filter filenames by the MC version, and click collapsed "Show" spoilers first.

Step 3: releases vs requests. Read the first post. "Can anyone make…" with no links, or threads in requests-f7/requests-archive-f41, are requests, not patches.

Step 4: fallbacks in order: parent mod's patch (mark Partial) → modpack patches (read their own "Missing Mods" section first) → Modrinth/CurseForge packs (for 1.12.2: Not Enough Pixels, then Faithful 32x Modded; fetch each pack's full mod list and cross-reference the whole outstanding list at once) → web search "<Mod>" texture pack <version>.

Prefer the target MC version; otherwise take the closest and flag the gap. Rename third-party archives <ModName>-<PackName><version>.zip.

Output: CSV + Markdown report with columns ModName, TextureFound, TextureSize, MCVersion, Source, DownloadLink, Notes, grouped: found on BDCraft · elsewhere · partial/parent · nothing found · to verify. Notes always record release vs WIP, version mismatches, source-list typos, and why something was ruled out. Save as you go; browser sessions drop.

11. Loose texture editing (bulk and micro-tuned)

Use when the user wants to change many texture files at once (resize, recolour, convert) or tune particular ones.

1. Inspect: count files, sizes, formats, alpha, and which look like data maps (normal, specular, roughness, metallic, AO, mask, height; usually named _n, _normal, _spec, _rough, _ao, _mask, _height).
2. Learn what the game expects (names, folder paths, formats, size limits, mipmaps) from the game's docs or mod pages. Loose-file mods generally only work when names and paths match the originals.
3. Plan then dry run: write a script (Pillow, or ImageMagick/texconv when installed) that lists every file it will touch and the before/after size; show the plan and counts before writing anything.
4. Mass first, micro-tune second: apply the broad operation to everything, then per-file or pattern rules (skips, brightness for foliage, a rectangle on one atlas). Keep the rules in a small JSON or Python dict so the user can read and tweak them.
5. Never overwrite originals: write to a new folder, or back up first into a dated folder with a manifest so the whole job can be undone.
6. Protect data maps: resizing is fine, but never colour-grade normal/specular/roughness/mask/height maps; keep alpha; do not change atlas or UI sheet dimensions unless the game data is updated too; prefer power-of-two sizes for older engines; use nearest-neighbour for pixel art.
7. Formats: PNG/TGA/BMP/WEBP are straightforward; JPG drops alpha; DDS block compression (BC1/BC3/BC5/BC7) needs the right tool and settings: check what the game uses.
8. Report: files written, skipped (and why), size change, output path, how to undo. Record the job in the tracker and have the user spot-check a few results in the game or an image viewer before a very large run. Respect any folders the user declared protected: skip them.

12. Dependency chain protection

Do this for every mod that is deployed, in any game.

1. Research the whole list first and build the chain: for each mod, which dependencies and versions it needs, and whether each is HARD (exact or narrow range: "requires exactly", version files with min/max, package metadata with version constraints, release notes "built against", a bundled patched copy, a paid or special edition that bundles its own dependencies) or SOFT (works with other versions). If unsure, treat as hard and say so. Pick versions that satisfy everyone, not simply the highest number.
2. Record it in the tracker: each mod's bundles (name, version, hard/soft) and a dependencies entry (version, folder, who provided it, who hard-requires it, who is soft).
3. Before copying, compare the staged mod with the installed folders (list top-level folders and files; hash-compare any that already exist; read .version or info.json versions). Identical: skip. Different: potential chain break. Loose-file games (Bethesda Data/) compare at file level, grouped by top folder.
4. Decide each difference: incoming copy soft -> keep installed, skip the bundled copy. Incoming hard and every installed dependent soft or confirmed compatible -> replacing may be fine (confirm from the sources). Both hard on different versions -> look for a compatibility patch or workaround (mod page, forum, package manager, patch mod, config change, another release of one mod) and apply and record it if found; otherwise it is a CONFLICT. A variant whose hard dependencies cannot be copied in (e.g. a paid edition) is blocked until the user decides.
5. Never merge two versions of one dependency folder file by file: keep one whole folder or swap the whole folder, and back up the old one first.
6. Ask about conflicts once. Deploy everything that does not conflict, then send ONE message listing all conflicts (dependency, installed version and who hard-requires it, incoming version and whether hard, any workaround found) with a few overall options: (a) keep installed and skip the conflicting bundled copies (safest), (b) keep installed and skip the conflicting mods, (c) prefer the incoming versions for all, with backups, (d) decide each. Apply the answer to every file in the conflict, record the resolution, and do not ask again per file. KSP note (user-reported, verify per mod): EVE exists as a free v3 and a paid v5 volumetric-clouds edition with hard dependencies; some volumetric-aware mods need a specific EVE; Kopernicus-family mods such as Outer Planets Mod have many interdependencies.

Game quick reference

Game	Mod dir	Format / notes
KSP	GameData/	.cfg + ModuleManager; frameworks ModuleManager, B9PartSwitch, CommunityResourcePack; CKAN manager
Factorio	%APPDATA%/Factorio/mods/	.zip, never extract; mods targeting 2.0 work on 2.1; watch stale duplicate versions
BG3	%LOCALAPPDATA%/Larian Studios/Baldur's Gate 3/Mods/	.pak + modsettings.lsx
Bethesda: Fallout 3	Data/	.esp/.esm, FOSE, plugins.txt, FO3Edit, MO2/Vortex
Bethesda: Fallout: New Vegas	Data/	.esp/.esm, NVSE, plugins.txt, FNVEdit, MO2/Vortex
Bethesda: Fallout 4	Data/	.esp/.esm/.esl, .ba2, F4SE, LOOT; match F4SE to game version
Bethesda: Oblivion (2006)	Data/	.esp/.esm, OBSE, TES4Edit, Wrye Bash
Bethesda: Oblivion Remastered	OblivionRemastered/Content/Dev/ObvData/Data/ (plugins) and Content/Paks/~mods/ (paks)	.esp + Plugins.txt, .pak, UE4SS in Binaries/Win64
Bethesda: Skyrim (LE/SE/AE/VR)	Data/	.esp/.esm/.esl, SKSE per edition, Address Library, LOOT; match SKSE to exe version
Unity games (BepInEx)	BepInEx/plugins/	Plugin framework in the game root; Mono (Managed/Assembly-CSharp.dll) vs IL2CPP (GameAssembly.dll) decides the build; r2modman / Thunderstore
Minecraft	.minecraft/mods/	loader-specific

Working on the user's machine

List before writing; stage only what you need; commit in batches; fall back to batch scripts if the device bridge fails (Windows updates can break the share; use stage → send → commit). Track deployed vs pending so a disconnect is resumable.

Session handoff

Stage set to handoff, tracker.xml and tracker.html fully current, pending downloads marked, protected folders and scope decisions recorded, known issues listed, tracker saved somewhere durable (and offered to the user as a download).

Trust rules

Never let a bundled copy overwrite or mix an installed dependency (ask once about conflicts); never overwrite folders the user declared protected without per-occurrence permission (none are protected unless they say so); never add unlisted mods except stated dependencies; never download source code; verify downloads; keep the tracker current; when unsure, ask; honor and record the user's site and scope preferences.