Skeleton Forge: What Happens When You Build Game Modding Tools for AI Instead of Humans

I’ve been playing Kenshi for years. One guy built this game over 12 years while working night shifts as a security guard—and somehow created a massive open post-apocalyptic world where you can be an AI Robot (known as “Skeletons” in the Kenshi world), a human merchant, a Hiver warlord, or just get your legs eaten off by giant birds in the first hour. There’s no story pushing you forward. No tutorial. You’re just… there, trying to survive in a world that doesn’t care about you. It’s part survival game, part strategy, part base-builder, and completely unlike anything else. It’s my favorite game.

At first, like most Kenshi players, I wanted to mod my save. Give my character a rare artifact. Rename a squad member. Tweak some stats. The usual. And I don’t mind “cheesing” because my favorite way to play Kenshi is as a “cozy survival / base builder / rpg”.

The existing tools work fine. FCS (the official Forgotten Construction Set– an .exe included with Kenshi in the game folder) is powerful but opaque. Then I discovered OpenConstructionSet—a C# library that cracks open Kenshi’s data formats programmatically. No GUI needed. Just code talking directly to game data. Hmmmmm…

What if I built a reverse engineering toolkit designed for an AI to use instead of me clicking buttons?

Two days later, I had Skeleton Forge.

The Problem with Traditional Game Modding Tools

Most game development tools assume a human is driving. You get menus, dialogs, drag-and-drop interfaces. These have served us well and some people love them, but the complexity of the UI (and the game system itself) can create a lot of friction when you’re exploring unfamiliar territory.

When I want to figure out how weapon quality actually works in Kenshi’s save format, I don’t want to click through 47 menus. I want to ask a question and get an answer. And when the answer reveals something unexpected—like discovering that weapon quality isn’t a simple number, but a combination of manufacturer ID and material ID—I want to capture that knowledge permanently.

This is where AI-native architecture comes in.

What “AI-Native” Actually Means

Under the covers, every tool in Skeleton Forge is CLI-first with structured output:

dotnet run -- explore SearchItems "CPU of Cat-Lon"

That’s not just “AI can use it.” It’s “AI can build it.”

When I need a new capability, I simply describe what I want. Claude Code (or your agent of choice) writes the exploration code. I test it. If it works, it graduates to the permanent toolkit. If it doesn’t, we iterate. The whole cycle takes minutes.

The folder structure is the workflow made visible: _Session holds work-in-progress. _StagedForDeletion is the graveyard for explorations that answered their question and aren’t worth keeping. Everything else graduated—SearchItems.cs, InspectCharacter.cs, ReplaceInventoryItem.cs—tools that started as throwaway questions and earned their place.

Here’s video snippet of the actual session:

Me: “research: give Homestead the CPU of Cat-Lon”

Claude Code + Skeleton Forge + OCS-based tools:

1. Checks the knowledge base → knows the inventory swapping pattern
2. Searches items → finds two “CPU of Cat-Lon” with different StringIds
3. Writes ReplaceInventoryItem.cs → general-purpose tool
4. Runs it → success
5. Adds to index → now permanent capability

Plot twist: The recipe system didn’t recognize the item. Wrong StringId. We discovered and swapped to the other variant that the improved limbs mod was looking for—works perfectly. All of this took just a couple of minutes.

That lesson is now documented: “When duplicate items exist across mods, the specific StringId matters for recipe compatibility.”

The Knowledge Base That Grows

Here’s what compounds over time:

Knowledge/
├── KNOWLEDGE_INDEX.json           # Machine-readable, searchable
├── save-structure/
│   ├── inventory-items.md         # "You CANNOT add items, only modify"
│   ├── quick-save-research.md     # "~146KB trailing index corrupts on rewrite"
│   └── editable-save-fields.md    # Community research roadmap
├── quality-grades/
│   ├── armor-quality.md           # level: 5=Prototype...95=Masterwork
│   └── weapon-grades.md           # company_sid + material_sid system
└── modding/
    └── blueprint-unlocks.md       # enable armour/weapon references

Every discovery gets captured. The AI checks knowledge before exploring, preventing duplicate work. When I come back next week, I don’t rediscover that you can’t add items to Kenshi saves—the system knows, and works around it automatically.

This is spec-driven development applied to exploration.

What I Actually Built

Save File Surgery:

• RenameCharacter — Rename any character in a save
• BoostStats — Set minimum skill levels across entire squads
• ReplaceInventoryItem — Swap items in character inventories

Game Data Exploration:

• SearchItems — Find any item by name pattern across base game + 50 mods
• InspectItem — Deep inspection of game objects (values, references, relationships)
• InspectCharacter — Full character state from saves
• DumpVendorList — Vendor inventory analysis with spawn weights
• ListItemsByType — Browse all items of any type

Mod Generation:

• Programmatic mod creation via code-as-source generators
• Blueprint unlock mods (discovered: Ninja Rags is leather armor, not cloth—wrong crafting bench!)
• Vendor inventory modifications
• Custom game starts

The stack: C# on .NET 9, built on OpenConstructionSet (community library for Kenshi’s data format), with Claude Code as the AI agent.

The Research Protocol

This isn’t just organization—it’s a formalized workflow:

research: [question]  → Check knowledge → Check tools → Investigate if needed
cleanup               → Graduate useful code → Update knowledge → Delete scaffolding

“Research” is a command the AI understands. It triggers a decision tree: Do we already know this? Do we have tools that can answer it? Only if both fail do we write new exploration code.

“Cleanup” is equally important. Temporary code gets deleted. Useful patterns get promoted. Knowledge gets documented. The system stays lean while the capabilities grow.

Why This Matters Beyond Kenshi

I learned Kenshi’s internals faster by asking plain English questions than I ever could have clicking through FCS—and every answer stayed captured for next time. Now imagine modding communities sharing these knowledge bases. You pull down someone’s repo and inherit years of reverse engineering work.

Skeleton Forge is a proof-of-concept for what I’m calling “AI-native game tooling infrastructure” (Stardew Valley, you’re next!) The human provides direction and judgment. The AI provides speed and pattern-matching and builds tools and mods without writing a single line of code. The system captures learnings for compound growth.

A complete save surgery toolkit. A living knowledge base that compounds with every session. Programmatic mod generation. Skeleton Forge.

PS- I built this in two days.

Built with OpenConstructionSet and Claude Code. The skeleton squad remains undefeated.