Best practices

Why it matters

Someone who shipped code before AI tends to spot a bad answer early. That catches a lot of bugs before they ever reach a load order.

How to do it

1. Be honest about where you're starting from. Lots of good mods come from people who learned on the job.
2. Start with small mods and grow them. Each one teaches you what the AI tends to get wrong.
3. Ask the AI why it picked an approach, and look up anything in the answer you don't follow.
4. Ask a more experienced modder to look over your first release. Modding Discords are full of people happy to help.

Why it matters

AI writes code that looks right and is quietly wrong, like a script that runs every frame or a hook that never lets go. A person reading every line is the best guard between that and a player's CTD.

How to do it

1. Read every change before it goes into a build, ideally the same day it was written.
2. Ask the AI to explain each function back to you, and stop when the explanation and the code disagree.
3. Keep each change small so a full read stays realistic.
4. Read the diff in git before every commit. Anything you skim past is code you haven't read.

Why it matters

When a bug report comes in, you need to know where to look. If you can't say what a part does, all you can do is ask the AI to guess again.

How to do it

1. Pick a file and explain it in your own words, then ask the AI where your explanation is off.
2. Write a short section in the README on how the mod fits together.
3. If a part stays a mystery after that, rewrite it in a way you do understand.

Why it matters

Code can run without a single error and still do the wrong thing, like a patch that edits the wrong record or a setting that never loads. Players only care whether it does what the page says.

How to do it

1. For each feature, decide what you expect to see, then go and look for it in game.
2. Check the actual results. Open the records in xEdit, read the files it writes, or check values in the console.
3. Treat "this should work now" from the AI as a guess. It can't run your game.

Why it matters

AI will happily invent a function that sounds right, like a Papyrus call or an SKSE method that was never there. That's how you get scripts that fail silently or a plugin that crashes on load.

How to do it

1. Open the real docs for every call it names, such as the Creation Kit wiki, the SKSE headers or the library's own reference.
2. Search for the function in the official source before you build on it.
3. Ask the AI where it got a call from, then go and check that place yourself.
4. Read your Papyrus log and compiler warnings. "Unknown function" there usually means the AI guessed.

Why it matters

AI sessions leave old attempts, test hooks and functions nobody calls lying around. Dead code can still load and register events, and it makes the next bug much harder to find.

How to do it

1. Once a feature works, ask the AI which functions nothing calls, then confirm with your own search.
2. Delete commented-out blocks. Git remembers them if you ever need them back.
3. Strip debug messages and test keybinds before a release.

Why it matters

Comments the AI wrote for an earlier version will mislead whoever reads the code next, and that's usually you, six months later, chasing a bug.

How to do it

1. When code changes, reread the comments around it in the same pass.
2. Delete comments that only repeat what the line already says.
3. Rename functions and variables whose names describe something they no longer do.

Why it matters

Players and other modders judge a mod much better when they know which parts AI did and which a person did. Saying it yourself builds trust, and it beats the comment section working it out.

How to do it

1. Add a short paragraph to the description saying what AI wrote, what you wrote and what you checked.
2. Be specific. "AI wrote the MCM menu, I wrote the quest scripts and tested both" tells people far more than "made with AI".
3. Put your strip on the page so the details are one click away.

Why it matters

Tests catch the bug you bring back three versions later before a player finds it. They pay off most in tools, patchers and DLLs, where one mistake can touch a lot of files.

How to do it

1. Start with the parts that read or write data, like parsers, patchers and anything that touches saves.
2. Have the AI write tests, then read them. It will happily write a test that checks nothing.
3. Break the code on purpose once and make sure a test goes red.
4. Run the tests before every release, or let GitHub Actions run them on every push.

Why it matters

Mods do get uploaded without the author ever loading them. Players find out fast, usually with a crash at the main menu.

How to do it

1. Load the game with the mod and use every feature the page lists.
2. Read the Papyrus log or your SKSE plugin's log after the session and chase every error.
3. Download your upload back from the mod page and test that exact file.

Why it matters

Some bugs only show up after an hour or two. Script lag piles up, saves bloat, or the game crashes on the fifth cell change. A five-minute check never sees them.

How to do it

1. Play a normal session of a couple of hours with the mod running.
2. Keep an eye on save size and the Papyrus log as you go.
3. Ask a few players to run a beta for a week before the full release.

Why it matters

Your own setup has years of files, tweaks and other mods that can hide a missing requirement. A fresh install is what a new player actually has.

How to do it

1. Make a clean profile in MO2 or Vortex with only the requirements your page lists.
2. Install from the archive you uploaded, following your own written steps.
3. If it needs anything you didn't list, add that to the page.

Why it matters

One game can mean several builds. Skyrim SE and AE need different SKSE and Address Library files, a patch can break every plugin overnight, and Game Pass copies often can't load a script extender at all. Players need to know whether your mod runs on the build they actually have.

How to do it

1. Name the exact builds you ran it on, like "1.6.1170 Steam", not just "AE".
2. Only claim a downgrade target, like 1.5.97 or 1.6.640, if you loaded the mod on it yourself.
3. Say which store builds you tried, and say so plainly when Game Pass or Epic can't run it.
4. When the game patches, test again and update the list, even if the answer is "not yet".

Why it matters

A mod that's fine on your GPU can crash on someone else's, and a DLL can lean on a runtime only your machine has. Shaders, ENB setups and the Steam Deck are where this bites most.

How to do it

1. Ask a friend or tester with a different GPU brand or OS to try it.
2. If your game runs on the Steam Deck or under Proton, try it there.
3. Write on the page what it was tested on.

Why it matters

Most bug reports come from load order conflicts. A little checking against popular mods saves a lot of time in the comments later.

How to do it

1. Open your plugin in xEdit with the big mods from your category loaded, and look at every conflict.
2. Test alongside the common frameworks and fixes most players run, like USSEP or a popular overhaul.
3. List known incompatibilities and any patches on the page.

Why it matters

AI tends to write for the exact case you asked about. Players will find the others, like a missing master, an empty inventory or a save from an older version.

How to do it

1. Ask the AI to list what could go wrong with each feature, then handle the likely ones.
2. Try odd setups yourself, such as a brand new character, zero items or a modded race.
3. Test updating from your last version on an existing save, as well as a clean install.

Why it matters

When something goes wrong, a clear log line is easy to fix. A CTD or a corrupted save is how a player loses a two-hundred-hour character.

How to do it

1. Catch errors where your code meets the outside world, like file reads, game hooks and network calls, and log them clearly.
2. If a requirement is missing or the game version is wrong, log it and switch the feature off.
3. Tell players where the log lives so bug reports come with it.

Why it matters

When a crash is hard to find, AI will often offer to catch it and carry on: a handler that swallows the exception, or a patch that skips the instruction that faulted. The crash goes away, but whatever caused it is still broken, and now it can quietly damage a save instead of stopping the game.

How to do it

1. Find out why it crashed before you change anything. Read the crash log and follow it back to your own code.
2. Ask the AI what caused the crash, not how to stop it. If its answer is a try/catch around the crash site, keep asking.
3. Catching an error you expected at your own edge, like a file that won't open, is fine. That's failing safely. Catching a crash inside the game's code and carrying on is not.
4. If a workaround really is the best you can do for now, say so on the page and in the known issues, and log every time it fires.

Why it matters

Players remove mods mid-playthrough all the time. Baked-in scripts and leftover records can break a save long after the mod is gone.

How to do it

1. Uninstall the mod partway through a save, load that save and play for a while.
2. Unregister events and clean up script state on the way out where you can.
3. If removal isn't safe, say so plainly near the top of the page.

Why it matters

AI code often polls every frame or scans every reference when it doesn't need to. On a heavy load order that turns into stutter, and players will blame some other mod.

How to do it

1. Measure frame time in a busy area with and without the mod.
2. Look for loops that run every frame or on every cell load, and ask whether they need to.
3. When the AI offers a faster version, measure again. Faster on paper isn't always faster in game.

Why it matters

A small leak is invisible in a short test and a crash three hours in. DLLs and tools that run in the background are the usual suspects.

How to do it

1. Watch memory and handle count in Task Manager or Process Explorer over a long run.
2. Check that every hook, timer and file you open gets closed again.
3. Look for lists and caches that only ever grow.

Why it matters

Rushed releases are where the obvious bugs slip through. A day of waiting often saves a week of hotfixes.

How to do it

1. Sleep on it before you upload, then test once more in the morning.
2. Run a short beta with a few players or your Discord.
3. Avoid releasing on a game update day unless you're fixing a break.

Why it matters

A beta that says it is a beta gets patient bug reports. A beta dressed up as finished gets angry ones, and players can not tell how much to trust it.

How to do it

1. Put the stage in the title or the first line of the page: alpha, beta or stable.
2. Say what the stage means for this mod, like "saves are safe, features may change".
3. Change the label when the mod moves on, and note it in the changelog.

Why it matters

An exe or DLL nobody can trace is the scariest download on any mod page. Signing it, or packaging it the same way every time, lets people check they got what you built.

How to do it

1. Build releases from a clean checkout with a script, so every release is made the same way.
2. Sign your executables if you can, and publish SHA-256 hashes for every file either way.
3. Let GitHub Actions build the release so the build log is public.

Why it matters

Source code helps most when someone else can turn it into the same file you shipped. Then anyone can check the download matches the code.

How to do it

1. Write the build steps in the README, then follow them on a clean machine.
2. Pin the versions of your compiler, tools and libraries.
3. Build releases from a tagged commit, ideally in CI.

Why it matters

A virus warning scares players off, whether it's real or a false positive. A scan link answers the question before anyone has to ask.

How to do it

1. Upload each release file to VirusTotal and link the result on the page.
2. Nexus scans uploads too, so point people to that result as well.
3. If a scanner flags it, explain why in the description. Packers and injectors trip a lot of them.

Why it matters

Source lets people see what a mod does and keep it alive if you move on. To be honest about it, a public repo means people can read the code, not that anyone did.

How to do it

1. Put the code on GitHub or a similar host and link it from the mod page.
2. For Papyrus mods, ship the .psc source files alongside the compiled scripts.
3. Tag each release so the code matches the download.

Why it matters

If your mod needs another AI-built tool to run, players inherit that tool's problems as well. Every unchecked piece is one more thing that can break.

How to do it

1. List every tool and helper your mod needs at run time.
2. Prefer established frameworks like SKSE or Address Library over one-off helpers.
3. If you do rely on an AI-built tool, hold it to this same list before you depend on it.

Why it matters

A missing requirement is the most common reason a mod "doesn't work". AI also suggests requirements that don't exist or are the wrong version.

How to do it

1. Fill in the Requirements section on Nexus, with versions where they matter.
2. Click every requirement link once and make sure it goes to a real, current mod.
3. Test with exactly those requirements in a clean profile.

Why it matters

Install steps written from memory skip things, and uninstall steps often don't exist at all. Both turn into support questions.

How to do it

1. Follow your own written steps on a clean profile, word for word.
2. Have someone else follow them without your help, and fix wherever they get stuck.
3. Write uninstall steps too, including what stays behind in saves.

Why it matters

Players forgive bugs they were told about. Surprise ones turn into angry comments, and a list cuts down on duplicate reports.

How to do it

1. Keep a Known issues section near the top of the description, or a pinned post.
2. Add workarounds where you have them.
3. Move each item to the changelog once it's fixed.

Why it matters

Players need to know whether an update fixes their bug or needs a new save. Without a changelog they have to guess.

How to do it

1. Use the Nexus changelog tab, or a CHANGELOG file in your repo.
2. Say on every version whether it's safe to update mid-save.
3. Let the AI draft the entry from your commits, then rewrite it around what players will notice.

Why it matters

Without a license, other modders can't tell whether they may patch, translate or carry on your mod. Clear permissions keep it alive after you stop.

How to do it

1. Pick a license or permission set and state it on the page.
2. Fill in the permissions section on Nexus.
3. Check that any code or assets you pulled in come with terms you can actually pass on.

Why it matters

Every mod has bugs. What players want to know is whether anyone will answer when they find one.

How to do it

1. Reply to bug reports, even if it's just to say you've seen it.
2. Ask for the details that help, like load order, game version and the relevant log.
3. Say on the page how long you plan to support it. If you don't plan to, say that too.

Why it matters

Players often know exactly what a mod is missing. Saying whether you take requests sets expectations on both sides.

How to do it

1. Say on the page whether you take requests, and where to post them.
2. Keep a short list of the ideas you liked so people can see they were heard.
3. Be upfront about what's out of scope.

Why it matters

Bugs reported in comments get buried. A public list shows what's known and what's fixed, and saves you reading the same report ten times.

How to do it

1. Turn on the Nexus bugs tab or GitHub Issues.
2. Link it from the top of the description.
3. When you close an issue, note the version that fixed it.

Why it matters

Game updates break mods, SKSE plugins and DLLs most of all. Players want to know if it'll be fixed after the next patch.

How to do it

1. Note the last game version you tested on, near the top of the page.
2. Update after game patches, or say plainly that you won't.
3. If you step away, say so and point to whoever picks it up.

Why it matters

Code that downloads files, opens ports or reads outside input can be abused. AI often writes those parts with no checks at all.

How to do it

1. List every place your code makes a network call, writes a file or takes input from outside the game.
2. Ask the AI to review those parts for security problems, then check each claim yourself.
3. Give the code only the access it needs.

Why it matters

Players have a right to know if a mod talks to the internet. An unexplained connection looks like spyware even when it's just an update check.

How to do it

1. Search your code for every URL and network call, including any the AI added.
2. List each one on the page and say what it sends.
3. If there are none, say that. It's good news worth sharing.

Why it matters

Collecting data from players without asking breaks trust fast. AI sometimes adds analytics or crash reporting without being asked.

How to do it

1. Search the code for analytics, crash reporting and update checks.
2. Remove anything you don't need.
3. If you keep something, make it opt-in and say what it collects.

Why it matters

Native code runs with full access to the game and the machine. A DLL that has only ever run on your rig can crash on a different game version or CPU.

How to do it

1. Have testers on different hardware and game versions run it before release.
2. Use Address Library or a similar approach so it isn't tied to one exe version.
3. Check the game version on load and stay switched off on versions you haven't tested.

Why it matters

Running as admin gives a program full control of the PC. Players shouldn't have to hand that over for a mod.

How to do it

1. Run your tool once as a normal user and fix whatever breaks.
2. Write to the user's own folders instead of Program Files or the game install where you can.
3. If something really does need admin, explain exactly why on the page.

Why it matters

AI-written descriptions tend to run long, stay vague, and sometimes promise features the mod doesn't have. Players skim for what it does and how to install it.

How to do it

1. Write the description yourself, even if it's short.
2. Cover what it does, what it needs, how to install it and what's still broken.
3. Use the AI for spelling if you like, then cut anything that doesn't sound like you.

Why it matters

Generated art on a mod page makes people wonder what else was generated. Your own pictures, even simple ones, show you cared.

How to do it

1. Build the banner from an in-game screenshot.
2. If you do use AI art, say so in the description.
3. Credit anyone whose art you used, with permission.

Why it matters

Mock-ups and generated pictures promise things the mod might not do. Real screenshots show players exactly what they're getting.

How to do it

1. Take screenshots in game with the mod running.
2. Show each feature the page talks about.
3. Retake them when the mod changes how it looks.