Mod a Game with Claude Code

Use Claude Code to build, test, and record a reversible offline game mod.

Introduction

30 Second Summary

A favorite game can invite ideas for new colors or artwork. Changing its files can feel risky when your saves are on the line.

In this project, you will use Claude Code with universal-modder to create a safe visual mod for an offline PC game you own. You will prove the loading route with a deliberately crude placeholder before replacing it with original local art.

What You'll Build

You will launch your chosen game offline to see your original visual asset working inside the same scene you tested.

By the end of this project, you'll have:

A before-and-after visual mod that starts as a loud placeholder before becoming original local art.
A reusable local field note that records the tested route plus the exact restore path for your game.
A 15-second showcase clip that proves the mod works inside the running game.
Secret Mission: Create a second locally generated visual variant that you can deploy through the same tested route.

Are there any prerequisites?

You need a Windows 10 or newer PC.

Eligible Claude Code access with internet connectivity is also required.

Your installed game needs a short offline single-player route that avoids bypasses or native reverse engineering.

Before We Start

A tiny reversible visual change keeps your first mod focused on reaching the running game. Before any tools or files change, choose one owned single-player PC game and commit to testing it offline.

Set Up the Windows Modding Toolkit

Your first mod already has a clear offline scope. Claude Code now needs a Windows PowerShell toolkit that can inspect the game safely.

A managed Python runtime supports the modding workflow. FFmpeg provides the video tooling you use later.

The universal-modder plugin connects these tools inside Claude Code. A fresh session can then discover installed game libraries on your Windows PC.

In this step, get ready to:

Install the Windows command-line tools plus a managed Python runtime.
Install Claude Code plus verify eligible account access.
Activate universal-modder plus list detected game installs.

Install the Windows toolchain

Windows Package Manager installs the shared tools from PowerShell. Git for Windows gives Claude Code the Windows support it expects.

uv installs a managed Python runtime for universal-modder. FFmpeg prepares your PC for the proof clip later.

Press the Windows key to open the Windows search bar.
Type PowerShell into the search bar. Press Enter to open it.

Allow a few minutes for the three downloads. A quiet pause between installers is normal.

Install Git for Windows, FFmpeg, plus uv by running these commands:

winget install --id Git.Git -e --source winget
winget install ffmpeg
winget install --id=astral-sh.uv  -e

What do these installations provide?

Git for Windows supplies the source-control tools that Claude Code uses on native Windows.
FFmpeg supplies the media tools used for the showcase recording.
uv manages Python runtimes without a global package setup.

You should see WinGet finish each package installation. This confirms that Windows has added all three tools.

Did an installation fail?

Check which package stopped before its installation completed. Rerun only that package's command from the block above.

Use the installation output to identify any network or permissions issue. Help me troubleshoot the failed WinGet installation.

Close the current PowerShell window.

The closed window clears the old command path. The next window reads the newly installed tools.

Press the Windows key to open the Windows search bar.
Type PowerShell into the search bar. Press Enter to open a fresh window.

Verify Git for Windows by running this command:

git --version

What does this check prove?

Git prints its installed version when PowerShell can find the executable. This proves the fresh window received the updated command path.

You should see a Git version in the output. Git for Windows is now ready for Claude Code.

Verify FFmpeg by running this command:

ffmpeg -version

What does this check prove?

FFmpeg prints its build information when the media executable is available. This confirms the later recording workflow can reach it.

You should see FFmpeg version details. The media tool is available outside the installer session.

Is a verification command unavailable?

Make sure each WinGet installation completed before you opened the fresh PowerShell window. Rerun the matching installation command if one package was missing.

Help me restore the missing Windows command.

The Python download can remain quiet while uv fetches the runtime. Give it a few minutes before treating the pause as a failure.

Install the latest managed Python runtime by running this command:

uv python install

What does this command do?

uv downloads a managed Python runtime. The runtime stays separate from other Python installations on your PC.

This gives universal-modder the environment it needs without manual global package management.

You should see download progress followed by installation information. That output confirms the managed runtime reached your PC.

List the available Python runtimes by running this command:

uv python list

What does the runtime list show?

The list shows which Python runtimes are installed. Universal-modder requires Python 3.10 or higher.

✔️ I see version 3.10 or higher

Good work. Your uv-managed Python runtime is ready for universal-modder.

ⓧ I see an older version

Universal-modder needs Python 3.10 or higher. Use uv to install the latest managed runtime.

Install the latest Python runtime by running this command:

uv python install

What changes now?

uv downloads the latest managed runtime. Existing runtimes remain available for other software.

Refresh the runtime list by running this command:

uv python list

What should the new list confirm?

The refreshed list should show an installed Python runtime at version 3.10 or higher. That runtime satisfies universal-modder's requirement.

ⓧ I see no installed runtime

uv is installed. The Python download did not complete.

Retry the managed Python installation by running this command:

uv python install

What happens during the retry?

uv fetches the latest Python runtime again. A completed command prints installation information.

Check the runtime list again by running this command:

uv python list

What should the new list confirm?

The new list should show an installed Python runtime. Its version should be 3.10 or higher.

Still missing a Python runtime?

Check the output from the latest installation attempt for a network or permissions issue. Keep the full output available so the failed download can be identified.

Help me fix the uv-managed Python installation.

Set up Claude Code access

Claude Code coordinates the reconnaissance workflow from your Windows PC. Its native installer makes the command available in fresh PowerShell sessions.

Install Claude Code by running this command:

irm https://claude.ai/install.ps1 | iex

What does this installer do?

PowerShell downloads the native Claude Code installer from Anthropic. The installer adds the Claude Code command to your Windows environment.

Native installations receive background updates after setup.

You should see installation information in PowerShell. This confirms that the native installer completed.

Did the installer stop?

Check the PowerShell output for a network or permissions issue. Rerun the installer after resolving the reported cause.

Help me troubleshoot the native Claude Code installer.

Close the current PowerShell window.

The installer has finished changing the command path. A fresh window can now load that path.

Press the Windows key to open the Windows search bar.
Type PowerShell into the search bar. Press Enter to open a fresh window.

Verify the Claude Code installation by running this command:

claude --version

What does this check prove?

Claude Code prints its installed version when PowerShell can find the native command. A version result proves the installation works in new sessions.

You should see a Claude Code version number. The command is ready for authentication.

Is the Claude command unavailable?

Make sure the native installer completed before you opened the fresh PowerShell window. Rerun the installer if the command is still unavailable.

Help me restore the Claude Code command.

Check your Claude access

Claude plan or Console usage charges can apply when you use Claude Code. Check your account terms before starting the session.

The free claude.ai plan does not include Claude Code access. This project stops here until an eligible account is available.

The next command starts an interactive Claude Code session. Your browser handles authentication when sign-in is required.

Start Claude Code by running this command:

claude

What happens during sign-in?

Claude Code starts an interactive terminal session. It opens a browser flow when your account needs authentication.

The terminal receives confirmation after the browser approves access.

Complete the browser sign-in with your eligible account.
Return to PowerShell after authentication succeeds.

✔️ Claude Code opens

That access check is complete. Claude Code is installed plus authenticated on your Windows PC.

ⓧ My account has no access

Your current account cannot continue with this project. Claude Code requires eligible access.

Stop the setup before starting a paid session.
Resume the project after eligible Claude Code access is available.

Need help understanding access?

Keep account credentials plus billing details private. Help me understand the eligible Claude Code access options.

Connect universal-modder to Claude Code

The plugin route installs the modding skills plus exposes the toolkit inside Claude Code sessions. A manual repository clone adds setup that this beginner workflow does not need.

Why use the plugin route?

The plugin includes the same modding skills as the repository route. Its session hook also places the universal-modder toolkit on the command path.

This keeps reconnaissance inside the Claude Code session you already authenticated.

Add the universal-modder marketplace in the current Claude Code session by entering:

/plugin marketplace add rehan-remade/universal-modder

What does this command do?

This registers the marketplace hosted at rehan-remade/universal-modder. Claude Code can then install the plugin published there.

You should see confirmation that Claude Code added the marketplace. The plugin is now available to install.

Install universal-modder from the new marketplace by entering:

/plugin install universal-modder@universal-modder

What does this command do?

This installs universal-modder from the marketplace you just added. The plugin contributes its modding skills plus toolkit launcher to Claude Code sessions.

You should see a plugin installation summary. Read that summary for the activation status.

Plugin activation is easy to miss in the installation summary. Look for Run /reload-plugins to activate. before starting a fresh session.

Run the activation command below only when the installation summary requests it:

/reload-plugins

What does reloading change?

Reloading activates the newly installed plugin in the current Claude Code environment. The next fresh session receives the universal-modder command path.

You should see Claude Code reload the installed plugins. Universal-modder is now ready for a fresh session.

Close the PowerShell window containing the current Claude Code session.

Closing the session gives the plugin startup hook a clean run next time. That hook makes the toolkit available to Claude Code.

Press the Windows key to open the Windows search bar.
Type PowerShell into the search bar. Press Enter to open a fresh window.

Start a fresh Claude Code session by running this command:

claude

Why start a fresh session?

A fresh session runs the plugin's startup hook. The hook adds universal-modder to the command path before Claude begins working.

Before you submit the discovery prompt, do you expect Claude Code to find your installed game library or fail to reach the toolkit?

Ask Claude Code to scan the supported game libraries by submitting this prompt:

Run um scan --list and show me the installed games you can detect.

What does this scan prove?

The prompt asks Claude Code to run universal-modder's game discovery command. The scan checks for installed Steam, Epic, or Xbox games.

This scan only lists detected installs. It does not modify your game or its files.

You should see detected Steam, Epic, or Xbox game installs. That list proves the fresh session can reach universal-modder.

Can't universal-modder list games?

Check that both marketplace commands completed successfully. Review the plugin installation summary for the activation instruction.

Reload the plugin when requested. Start another fresh Claude Code session before retrying the scan.

Help me restore universal-modder game detection.

Your Windows modding toolkit can now discover installed games without changing them. Next, you will identify the safest route for your chosen offline visual mod.

Find the Safest Modding Route

Your toolkit can now detect installed games. Detection alone cannot prove that your chosen game has a beginner-safe modding path.

In this step, you will inspect the game before changing it. You will finish with a reversible visual mod running offline.

In this step, get ready to:

Complete reconnaissance for your chosen game.
Create the safety package for the selected route.
Deploy a high-contrast visual placeholder in offline play.

Scan the game and rank safe routes

The Claude Code session guides the investigation. The universal-modder toolkit inspects the game before the first file changes.

Game reconnaissance maps the installation before any edits begin. The resulting plan ranks safe routes for the detected game engine.

Switch back to the fresh Claude Code session from earlier.
Send this reconnaissance brief:

Game: [[GAME_NAME="your chosen game name"]]

Create a separate game-specific working folder outside the game folder. Tell me its full path before continuing.

Find my installed copy, search the universal-modder knowledge base, scan the game, identify its engine and version, check for anti-cheat and online-only risks, rank the available modding routes, and write MODDING_PLAN.md. Use an official mod surface, data or asset override, or established loader. Stop and recommend another installed game if this route needs an anti-cheat or DRM bypass, native reverse engineering, or more than about 20 minutes of game-specific setup.

What does this reconnaissance do?

The scan identifies the game installation before any files change.
The route ranking keeps the smallest safe option visible.
The rejection gate stops the session before prohibited bypass work begins.
The separate working folder keeps your own files away from the installed game.

Claude should report the install location. It should also create MODDING_PLAN.md inside the new working folder.

Review the identified install location.
Confirm the reported engine.
Confirm the reported game version.
Accept the route only when it uses an official mod surface, data or asset override, or established loader.
Switch to another detected game if Claude reports a rejection criterion.
Record the game-specific working folder path here: <working-folder>.

Good, the route is now chosen on evidence instead of guesswork.

Can't approve a safe route?

Confirm that the chosen game appears in the detected game list from earlier.
Ask Claude to explain any missing engine or version evidence.
Choose another detected offline game if every ranked route fails the safety gate.

Help me interpret my game reconnaissance results.

Back up every file at risk

A backup turns the selected route into a reversible change. The restore command must exist before the first modded launch.

A loader can place files beside the game executable. You keep control by reviewing every proposed addition before approval.

Send this backup brief in the same Claude Code session:

Create MODLOG.md in the working folder. Record every path and version. Back up the save, profile, configuration, and any files you plan to touch with um backup create. Write the exact restore command into MODLOG.md before the first modded launch. If the selected route needs a loader, explain every file you will add and wait for my approval before installing it. Show me the backup locations and restore command when finished.

Why record the restore path now?

The backup snapshot preserves the state that existed before the mod.
MODLOG.md keeps the relevant paths beside the recovery instructions.
The exact restore command removes guesswork if the game stops loading.
The approval pause prevents a loader from adding unexplained files.

Claude should show the completed backup locations. It should also display the exact restore command recorded in MODLOG.md.

Compare every proposed game path with MODDING_PLAN.md.
Confirm the backup set covers the relevant save files.
Confirm the backup set covers the relevant profile files.
Confirm the backup set covers the relevant configuration files.
Confirm the backup set covers every game file the route may touch.
Check that MODLOG.md contains the backup locations.
Check that MODLOG.md contains the exact restore command.
Approve a required loader only after every added file has been explained.

Is the backup plan incomplete?

Ask Claude to compare the planned edits with the completed backup set.
Require Claude to add any uncovered path before continuing.
Keep the game unmodified until the restore command is recorded.

Help me check my mod backup plan.

Deploy one loud visual change

A high-contrast placeholder acts as a diagnostic signal. Its job is to prove that the selected route can load your local asset.

Send this build brief in the same Claude Code session:

Build the smallest reversible visual mod the selected route supports. Create an unmistakable high-contrast placeholder locally. Save it as [[WORKING_FOLDER="<working-folder>"]]\assets\placeholder.<format>. Use the exact dimensions and file format required by the route. Do not copy an extracted game asset into the working folder. Deploy the placeholder through the selected route. Report every deployed file when finished.

Why start with a placeholder?

The placeholder isolates the delivery pipeline from visual polish. A clearly visible result proves that the game loaded the deployed asset.

Keeping extracted game assets out of the working folder also keeps your project focused on original local work.

Claude should report the placeholder dimensions. It should also report the deployed files used by the selected route.

Review Claude's list of deployed files.
Confirm the placeholder exists at <working-folder>\assets\placeholder.<format>.
Confirm that no extracted game asset appears in the working folder.
Confirm that the deployed file list matches the selected route.

Before you launch it, which outcome do you expect: a blended asset or an obvious contrast? Your prediction gives you a result to test.

Ask Claude to launch the deployed mod by sending:

Launch the modded game through the selected route. Stop before sending input.

Why launch the real game?

A successful deployment only proves that files reached their destination. The running game proves whether the selected route actually loads them.

Take control when the game window opens.
Select offline single-player mode.
Load the save or profile covered by the backup.
Navigate to the object, texture, or color chosen for your tiny change.
Check the changed visual element in the running game.

You should see the chosen element stand out from the unmodified scene. This confirms that the selected route loads your local placeholder.

The placeholder should look deliberately out of place beside the game's real art. That visible mismatch is the intended limitation you will improve after testing the route.

That is the hard part done: your modding route is reversible, documented, and visible in the real game.

Don't see the placeholder?

Ask Claude to compare the deployed path with the route recorded in MODDING_PLAN.md.
Ask Claude to confirm the placeholder dimensions and file format.
Check that the game launched through the selected loader or override route.

Help me trace why my placeholder is missing.

Your safe route now works in offline play. Next, you will test the same scene carefully and document why the placeholder still looks unfinished.

Test the Mod in the Real Game

Your loud placeholder is visible in the owned game from earlier. The next goal is to prove that the same mod survives a repeatable launch.

Produced files only confirm that the build created something. Running the real game can expose a wrong scale or placement. It can also reveal a broken loading path or behavior.

In this step, get ready to:

Capture evidence from the running game.
Perform your own in-game safety check.
Resolve functional failures or document a safe stopping point.

Capture Claude's in-game evidence

The running game is the final source of truth for this test. Claude Code can repeat the launch path from earlier. universal-modder can capture the loaded scene as evidence.

Before Claude repeats the launch, do you expect the placeholder to load in the same scene again?

Switch back to the Claude Code session from earlier.
Run the evidence pass by pasting this prompt:

Repeat the launch path recorded in MODDING_PLAN.md. Keep the game offline in single-player mode. Inspect the game log for loading failures. Use um win shot to capture the changed scene. Read the screenshot to confirm that the placeholder is visible. Save the evidence as <working-folder>/evidence/placeholder-test.png. Record the game-log review and screenshot path in MODLOG.md.

What does this evidence prove?

Repeating the recorded launch path proves that the mod can be tested consistently.
Inspecting the game log can reveal loading problems hidden behind a successful build.
Reading the screenshot proves that the captured file contains the changed scene.
Saving the image in the working folder keeps the evidence beside the mod records.

Ask Claude to open <working-folder>/evidence/placeholder-test.png after the evidence pass finishes.
Confirm that the image shows the high-contrast placeholder in the selected offline scene.

You should see the changed game scene in placeholder-test.png. Claude should also report that it inspected the game log instead of treating the image file alone as proof.

Is the screenshot missing or unclear?

Ask Claude to return the game to the exact scene where the placeholder appears.
Keep the game window visible while Claude captures the scene again.
Ask Claude to verify that the final image exists at <working-folder>/evidence/placeholder-test.png.

Help me troubleshoot why um win shot did not capture clear evidence of my placeholder mod in the running offline game.

Good, you now have visual evidence from the real game instead of relying on generated files alone.

Verify the mod yourself

Claude's evidence confirms what its tools observed. Your own check confirms that the game remains playable with the mod deployed.

Before you take control, do you expect the placeholder to remain visible while the normal save and controls still work?

Return to the running game window from Claude's evidence pass.
Load the expected save or profile.
Revisit the same offline scene.
Confirm that the placeholder remains visible.
Test the normal movement controls.
Confirm that the expected progress appears in the save or profile.
Identify one specific reason the placeholder looks unfinished.

If every functional check passes, the mod has survived your independent test. The rough appearance remains the intentional limitation you improve later.

Did a functional check fail?

Keep the backup set unchanged.
Describe the exact failed check to Claude.
Preserve the current game log for the next diagnosis.

Help me diagnose a failed visibility, control, or save-loading check in my offline modded game.

Resolve failures and record the result

A functional failure affects visibility, controls, or save loading. The specific visual limitation stays in place as evidence that the placeholder still needs polish.

Your next move depends on the result of your own in-game check.

✔️ The mod passes every check

Your placeholder is visible. The controls work. The expected save or profile loads.

Ask Claude to record the game-log review in MODLOG.md.
Ask Claude to record the path to <working-folder>/evidence/placeholder-test.png.
Ask Claude to record your confirmation that the placeholder is visible.
Ask Claude to record your confirmation that the controls work.
Ask Claude to record your confirmation that the expected save or profile loads.
Ask Claude to record the specific visual limitation you identified.
Ask Claude to show the completed test entries in MODLOG.md.

You should see a passing test record backed by the game log, screenshot evidence, and your own observations.

ⓧ I found a functional issue

A fix can touch deployed mod files. Your backup and recorded restore command protect the known-good starting point.

Tell Claude the exact failed check.
Ask Claude to inspect the game log for the cause.
Ask Claude to trace the failure through the selected route in MODDING_PLAN.md.
Approve the proposed fix only after Claude explains every file it changes.

The next launch tests whether that route-specific fix solved the observed failure.

Ask Claude to deploy the approved fix.
Return to the same offline scene.
Confirm that the placeholder appears.
Test the normal controls.
Load the expected save or profile.
Ask Claude to recapture <working-folder>/evidence/placeholder-test.png with um win shot.
Ask Claude to read the fresh screenshot.

A clean retest turns the failure into useful evidence for the local mod record.

Ask Claude to record the failed behavior in MODLOG.md.
Ask Claude to record the cause and fix.
Ask Claude to record the passing retest evidence.
Ask Claude to record the placeholder's specific visual limitation.

ⓧ The same failure happened three times

Three repeats trigger the circuit breaker. Stopping here protects the backup from random changes that could move beyond the selected safe route.

Stop the retry loop.
Preserve the backup set from earlier.
Ask Claude to record all three failed attempts in MODLOG.md.
Ask Claude to record the exact blocker.
Ask Claude to record the evidence gathered before the stop.
Keep anti-cheat protections untouched.
Keep DRM protections untouched.

Your safe result is a documented blocker with the restore path preserved. No bypass attempt belongs in the mod record.

A passing path now has one last repeatable check. A three-attempt blocker finishes with the documented stopping point from its tab.

If your mod is in a passing state, before the final check, do you expect the game and MODLOG.md to tell the same story?

Return to the same offline scene for one final test.
Confirm that the placeholder is visible.
Test the normal controls.
Confirm that the expected save or profile loads.
Ask Claude to show the final test entries in MODLOG.md.

You should see the placeholder in the running game while the controls and expected save still work. MODLOG.md should name the game-log review, screenshot evidence, learner verification, and one specific visual limitation.

Did the final state change?

Return to the functional issue tab above for a new safe failure.
Use the three-attempt stopping path if the same failure has now repeated three times.

Help me reconcile a final in-game result that no longer matches my recorded passing test.

You did the check that catches hidden mod failures: the placeholder now has evidence from Claude's tools and from your own play test.

Next, you'll replace the deliberately crude placeholder with original local art while keeping this proven route intact.

Replace the Placeholder with Local Art

Your placeholder has already proved that the selected route reaches the running game. The passing screenshot gives you a stable comparison point.

The placeholder still clashes with the game's visual style. In this step, Claude Code uses Python with Pillow to create an original local replacement that fits the requirements the game actually loaded.

In this step, get ready to:

Record the technical requirements of the loaded visual asset.
Replace the placeholder with original local art through the existing route.
Verify the polished asset in the same offline game scene.

Create art from the loaded asset requirements

Claude reads the loaded file's technical properties before generating anything. Your new artwork uses those constraints without copying extracted game art.

Return to the Claude Code session from the previous step.
Give Claude the game-specific constraints by sending this prompt:

Inspect the visual asset that the game actually loaded. Record its dimensions in MODLOG.md. Record its transparency behavior in MODLOG.md. Record its palette constraints in MODLOG.md. Record its required name in MODLOG.md. Record its file format in MODLOG.md.

Use Python with Pillow to create one original local visual in the existing assets folder. Name it polished-local and use the required extension. Build it from new shapes, original text, or a new palette. Do not copy an extracted game asset into the working folder. Show me the final path and a preview.

What does this prompt produce?

The dimensions preserve the space that the game reserves for the visual.
The transparency behavior prevents unwanted backgrounds or edges.
The palette constraints keep the replacement readable in the selected scene.
The required name and file format let the existing route load the new asset.

Review Claude's requirement summary in MODLOG.md.
Inspect the preview that Claude shows.

You should see an original visual made from new shapes, text, or palette work. Its proportions should match the loaded asset requirements.

Does the preview look distorted?

Ask Claude to compare the generated file against the dimensions and transparency behavior recorded in MODLOG.md. Regenerate the local visual after correcting the mismatched property.

Keep extracted game art outside the working folder. Use it only as an inspected source of technical properties.

Help me correct my polished local asset.

Deploy the polished asset

The polished file becomes useful when the selected route loads it successfully. Keeping the same route isolates the visual asset as the single changed part.

Preserve the working placeholder while deploying the replacement by sending this prompt:

Keep the first working placeholder recoverable in the existing backup or version history. Convert polished-local to the exact format that the selected route expects. Replace the deployed placeholder with the converted asset. Rebuild through the same route. Deploy through the same route. Do not change the route. Update MODLOG.md with the loaded asset requirements and deployment result. Show me the exact source file and deployed destination.

Why keep the route unchanged?

The placeholder already proved that the route works. Reusing it makes the artwork the single variable in this test.

The recoverable placeholder gives you a known working state if the polished file needs another pass.

Review Claude's deployment summary.

You should see the polished local file listed as the source. The summary should also confirm that the first working placeholder remains recoverable.

Did the conversion or deployment fail?

Compare the generated extension with the file format recorded in MODLOG.md. Check the required asset name separately.

Ask Claude to rebuild through the route already documented in MODDING_PLAN.md. Keep the original backup untouched during the retry.

Help me fix the polished asset deployment.

Verify the improved mod in-game

A successful deployment still needs proof from the running game. Using the same scene makes the placeholder screenshot a direct visual baseline.

Before you relaunch, do you expect the polished asset to appear in the same position as the placeholder?

Run the final in-game check by sending this prompt:

Launch the same offline single-player scene through the documented route. Ask for permission before driving the mouse or keyboard. Use um win shot to capture the polished asset. Save the screenshot as evidence/polished-test.png. Read the screenshot. Compare it with evidence/placeholder-test.png. Check its size. Check its alignment. Check its transparency. Check its contrast. Report the result.

What does this verification prove?

The matching scene keeps the camera context consistent with the placeholder test. The new screenshot shows whether the game loaded the replacement through the established route.

Claude checks the captured frame for visible defects. You complete the test by checking motion and gameplay yourself.

Input automation can feel invasive. Claude asks permission first and keeps its actions limited to the foreground game.

Approve input control only when Claude requests the minimum scene actions.

You should see the polished asset where the placeholder appeared. Its new design should fit the scene more closely.

Take control of the game.
Move through the repeatable test scene.
Confirm that the polished asset remains readable during motion.
Load the expected save or profile.
Test the controls in the same scene.
Tell Claude the results of your motion and gameplay checks.
Ask Claude to record the passing verification in MODLOG.md.

The expected save should load normally. The scene and controls should behave exactly as they did during the placeholder test.

Does the polished asset break the scene?

Use the documented route to restore the working placeholder. Compare the failed replacement with the requirements in MODLOG.md.

Correct one mismatched property before redeploying. Repeat the same offline scene check after the new build.

Help me diagnose the in-game asset problem.

That is the visual upgrade complete. Your game now loads original local art through the same reversible route.

Your polished mod is working in the running game. Next, you'll record a short proof clip and preserve the route in a reusable local field note.

Record the Proof and Field Notes

Your polished local asset now works in the exact offline scene you tested. This final step turns that result into proof you can replay.

A working mod is difficult to show without a clean clip. It is difficult to repeat without a record of the exact route that worked.

In this step, get ready to:

Plan a repeatable 15-second gameplay action.
Record the polished mod in the game window.
Complete the local mod log and reusable field note.

Plan a repeatable showcase

A short proof clip needs a controlled starting state. A repeatable action keeps the polished asset visible during the recording.

Giving Claude temporary input control can feel risky. The permission gate keeps every automated action under your control.

Return to your Claude Code session from earlier.
Ask Claude to prepare the recording plan by entering:

Plan one repeatable 15-second action that reveals the polished mod immediately.
Restore the clean test state if needed.
Hide debug overlays.
Ask my permission before you drive the mouse or keyboard.
Keep the game offline and single-player.

What Does This Prompt Prepare?

The fixed starting state makes separate takes comparable.
The short action reveals the polished asset before the viewer loses context.
The permission gate keeps input control in your hands.

Review Claude's plan for a repeatable starting state.
Confirm the planned scene stays offline.
Approve temporary input control when the game is ready.

You should see a plan that names the starting state. It should also name the exact gameplay action that reveals the polished mod.

Is the Showcase Plan Unclear?

Ask Claude to shorten the action if the mod appears too late. Ask it to choose a more reliable starting state if the scene changes between takes.

Keep the game offline during every attempt. Stop before recording if the plan enters an online mode.

Help me make my offline showcase action repeatable.

Record and verify the clip

The universal-modder recording tool captures the game window with its audio. FFmpeg can trim or repeat the take until the proof lasts about 15 seconds.

Ask Claude to record the approved showcase by entering:

Use um win record to capture only the game window and game audio while you perform the approved action.
Save the final clip as showcase.mp4 in the game-specific working folder.
Trim or repeat the take with FFmpeg as needed so the final clip is about 15 seconds.

What Does This Recording Prompt Do?

The recording stays focused on the game window.
The approved action gives the clip a clear beginning.
The final file becomes the local proof for this mod.

Allow Claude to record the approved action.
Wait for Claude to report the path to showcase.mp4.

You should see showcase.mp4 inside the game-specific working folder. Claude should also report whether it trimmed or repeated the take.

Before you play it, do you expect the polished mod to remain clear throughout the proof action?

Ask Claude to play the finished clip by entering:

Open showcase.mp4 and play it from start to finish.

What Does Playback Prove?

Playback verifies the exported file itself. It catches a loading screen or desktop capture that an in-game test cannot reveal.

Watch the entire playback without skipping.

You should see approximately 15 seconds of offline gameplay in the game window. You should hear game audio while the polished mod remains visible during the planned action.

That is the proof captured. Your mod now has a local demonstration that someone else can understand without entering the game.

Does the Clip Miss the Mod?

Record another take if the clip shows a loading screen or desktop window. Start the recording from the clean state in your approved plan.

Ask Claude to adjust the trim if the action starts too late. Keep the original game files out of the recording folder.

Help me fix my local showcase clip.

Complete the local field notes

A field note turns this one successful mod into a route you can reuse. The restore command keeps that route reversible.

Ask Claude to finish the local records by entering:

Finish MODLOG.md.
Record the exact game build, engine, selected route or loader, changed files, backup locations, restore command, placeholder and polished-asset test evidence, screenshots, clip verification, failures, fixes, and gotchas.
Create FIELD_NOTE.md as a reusable local field note with the exact game build, engine, selected route or loader, versions, changed files, restore command, verification evidence, failures, fixes, and gotchas.
Keep both files local.
Do not open a public pull request or publish game files.

What Do These Records Preserve?

The completed mod log preserves the detailed history of this build.
The field note captures the route you can reuse for future local work.
The restore command records the safe path back to the original state.

Review Claude's completion summary for MODLOG.md.
Review Claude's completion summary for FIELD_NOTE.md.

You should see confirmation that both local files contain the game build. You should also see the selected route plus the tested restore path.

Are Details Missing From the Notes?

Compare the notes with MODDING_PLAN.md if the engine or selected route is missing. Compare them with the earlier evidence files if either test result is unclear.

Keep the notes local if they mention game paths or changed files. Remove any extracted game content before considering future sharing.

Help me complete my local mod field note.

Before you run the final check, do you expect Claude to find every required field and all three final artifacts?

Ask Claude to audit the finished local evidence by entering:

Audit MODLOG.md and FIELD_NOTE.md against every required field.
Confirm that showcase.mp4 exists in the game-specific working folder.
Confirm that the clip verification records game-window playback, game audio, the polished mod, and an approximately 15-second duration.
Report every missing item without publishing anything.

What Does the Final Audit Check?

The audit checks the two written records against the finished video. It also confirms that the proof remains local.

Read Claude's audit summary.

You should see confirmation that showcase.mp4 exists. You should also see that MODLOG.md and FIELD_NOTE.md contain every required detail.

Did the Audit Find a Gap?

Ask Claude to fill only the missing field from the existing local evidence. Do not let it guess a version or restore command.

Replay showcase.mp4 if the clip verification is incomplete. Record what you personally observe in the local notes.

Help me resolve the missing audit item.

That closes the loop. Your mod now has a replayable demonstration plus a private record of the route that worked.

Secret mission

Create a Second Local Variant

Your first polished asset proves that the game can load original local art through a safe route. Create a second visual design with the same technical requirements, add a reversible way to switch variants, and prove the result in the same offline scene.

Clean Up Your Resources

Every project-specific resource stays on your Windows PC, so there are no ongoing cloud or fal costs. Decide whether to keep the mod active, pause it for later, or restore the game and delete the project files.

Claude usage costs

Claude plan or Console usage charges can still apply when you use Claude Code during cleanup. Your local game files do not create cloud resource charges.

Resources you used:

Reversible selected mod route, including the project-added files or loader configuration documented in MODLOG.md.
Backup set containing the relevant save, profile, configuration, touched game files, and recoverable placeholder state.
Game-specific <working-folder> containing MODDING_PLAN.md, MODLOG.md, FIELD_NOTE.md, local assets, evidence screenshots, and showcase.mp4.

Keep everything running

No action is needed. Choose this if you want to keep using both visual variants or continue experimenting with the tested route.

Leave the selected mod route enabled for offline single-player use.
Retain the backup set and exact restore command recorded in MODLOG.md.
Keep <working-folder> with its assets, evidence, showcase clip, and field note.
Keep the shared Windows toolkit installed for future local projects.

Pause - I'll come back to this later

Disable the deployed mod while keeping every project file needed to resume later. Your backup, variants, evidence, and field note remain on the Windows PC.

Return to Claude Code from earlier.
Ask Claude Code to read the disable or switch instructions in MODLOG.md.
Review the proposed paths against the changed-files list in MODLOG.md.
Approve only the steps that disable the selected mod route.
Launch the chosen game in offline single-player mode.
Load the same scene used for your mod tests.

You should see the unmodified visual while the expected save or profile still loads. Your clean game state is back, while the complete mod remains ready inside <working-folder>.

Delete - I don't want to use this again

Deleting the project files is final, but restoring the game first protects your original save and touched files. The backup stays in place until you confirm the restored game works.

Return to Claude Code from earlier.
Ask Claude Code to read the exact restore command from MODLOG.md.
Ask Claude Code to show the complete restore plan before it changes any files.
Review every restore path against the backup locations and changed-files list in MODLOG.md.
Approve the restore plan only when every path matches your records.
Launch the chosen game in offline single-player mode.
Load the same scene used for your mod tests.

You should see the original visual while the expected save or profile loads normally. That is the safety checkpoint done: your original game state is back before the backup or evidence is deleted.

Exit the game.
Ask Claude Code to list every project-added file outside <working-folder>.
Ask Claude Code to list every backup location recorded in MODLOG.md.
Review the proposed removal list against the selected mod route.
Approve removal only for the project-added files and confirmed backup locations.
Ask Claude Code to confirm that each approved path no longer exists.
Delete the game-specific working folder by running this command in PowerShell:

cmd.exe /c rmdir /s /q "[[WORKING_FOLDER=\"<working-folder>\"]]"

What does this command remove?

This command recursively removes only the working-folder path you enter. That folder includes your plans, logs, field note, local assets, screenshots, and showcase clip.

The command does not uninstall the shared Windows toolkit. Those installations remain available for other projects.

Ask Claude Code to confirm that the working-folder path no longer exists.

You should receive confirmation that <working-folder> is gone. Your owned game remains installed in its restored state.

Working folder still present?

Close the game because an open asset or video can lock the folder.
Check that the path entered for WORKING_FOLDER points to the game-specific working folder.
Rerun the removal command after closing any editor or video player using files from that folder.
Help me safely remove my locked game-modding working folder.

Nice Work!

You did it! Your owned offline game now runs a reversible visual mod built with Claude Code and universal-modder.

You've learned how to:

Used game reconnaissance to identify the engine. Ranked the supported routes before selecting a safe offline path.
Created a backup and restore path before changing the game. Replaced the loud placeholder with original local art through the same reversible route.
Verified the polished mod in the running game. Recorded a 15-second showcase clip. Saved the exact workflow in a reusable local field note.
Secret Mission: Created a second local visual variant with a distinct design. Documented the switch instructions. Verified both variants in the same offline scene.

Ready to quiz yourself?