The AI skills behind Inselnova
TL;DR: I build Inselnova with a stack of Claude Code skills sitting in the repo. A skill is a small file that tells the AI how to do one job the way I want it done. Most of the time I run them in roughly the same order on a ticket: open a version, scope it, check the economy, check the cascade, stress-test the plan, write a failing test, build, commit. The rest are content skills, consistency rules, and a release pipeline. The point of all of them is the same. A skill is a decision I only had to make once.
What a skill is
A skill is a markdown file the AI reads before it starts a job. Mine carry the rules, the file paths, the tone, the balance math, the gotchas. When I ask for a new affair, one of those events that pops up on your island with a choice to make, the AI doesn’t guess how affairs work. It reads the affair skill, finds the folder, follows the format, and keeps the choices balanced.
The first time I built an affair, I had to figure out where the file lives, what fields it needs, and how to balance the choices. I didn’t want to figure that out again every time. So I wrote it into a skill. There are a few dozen of these now, grouped by job. Here they are.
The order I run them on a ticket
A normal ticket runs through roughly the same chain, top to bottom. The middle three, economy, impact-check and grill, aren’t fixed to that order. I reach for them whenever a change calls for it, sometimes more than once in a session.
| # | Skill | What it does |
|---|---|---|
| 1 | worktree | A fresh worktree per version, not per feature, so a few can run at once. One might improve the Black Tide, one might be a prototype I bin. |
| 2 | ticket | Pulls the ticket from the tracker and gives me the overview, so the session is anchored to one piece of work. |
| 3 | economy | If the change touches resources or prices, it balances first. Everything anchors on the value of a coin. Numbers have to hold or it doesn’t go in. |
| 4 | impact-check | Walks the cascade before I commit to a change. More on this below. |
| 5 | grill | If I’m still not sure, it interviews me about the plan until nothing vague is left. |
| 6 | test | Test-driven. I ask for the red light first, watch it fail for the right reason, then it builds until green. The test stays in as a regression test. |
| 7 | commit | Closes the ticket, written the way the repo expects. |
Checking the cascade before I change a number
Game mechanics cascade, and it’s easy to change one number without seeing what it knocks over two steps later.
Say I write a god’s curse that removes food from an island. That looks like one change. It isn’t. Less food raises the island’s unhappiness, higher unhappiness lowers the army’s attack and defence, and that changes how a raid against that island lands. One curse reaches three systems away. The impact-check skill walks that chain for me: the code that depends on the number, the handbook pages that quote it, the tests pinning the old value, and what it does to worlds that are already live. Then it asks, in effect, are you sure, because this also hits that. I’ve changed my mind more than once on the answer.
Skills that write the game’s content
These expand the game without breaking it. Each one knows the file format so the content loads, and the balance rules so it can’t wreck the economy on the way in.
| Skill | What it does |
|---|---|
affair | Island events and their choices. |
condition | The chronic pressures that build up on a settlement. |
expedition | The long sea voyages and their storylets. |
alliance-quest | The co-op goals alliances work on together. |
characters | Helps me pick which character fits, and carries each one’s voice so the dialogue sounds like them. |
tone | Keeps any text on screen in the game’s voice, not a generic one. Pairs with characters: one is who’s talking, the other is making them sound right. |
Skills that keep everything consistent
These keep the codebase consistent as it grows, so it doesn’t rot.
| Skill | What it does |
|---|---|
backend-conventions | Where backend code goes, what to name it, how big a file can get before it splits. |
frontend-conventions | The same rules for the React side. |
database | Keeps queries and migrations consistent across the two databases the game runs on. |
style | The real palette and component patterns. New screens match the old ones, down to the buttons and dialogs. When one’s wrong I fix it and tell the skill to update. |
i18n | Any new screen ships translatable from day one, instead of bolting it on later when it hurts. |
The wiki is the game bible
The in-game handbook is the single source of truth. If the game knows something, the player should be able to know it too.
| Skill | What it does |
|---|---|
wiki | How a handbook page is built, for adding or editing one. |
reconcile | Keeps the handbook and the game honest with each other. Change a mechanic and it reconciles up into the handbook. If the handbook’s right and the game’s drifted, it pulls the game back the other way. |
Shipping a version
A tight group that gets a version live, in sequence.
| Skill | What it does |
|---|---|
readiness | Runs every check and reviews the diff. Has to come back green or I can’t continue, sometimes after three or four rounds. Every report gets stored under the releases directory. |
reminder | A note I pin days ahead, like a migration I’m not ready to run yet. Readiness surfaces it at the right moment so it doesn’t get forgotten. |
prepare | Gets the release ready and lines up the social post. |
release | Ships it. |
hotfix | The emergency cousin of worktree. When production’s broken, it gets a small fix out on its own without disturbing the version I’m building. |
health-sweep | The version-to-version tidy-up, running general cleanups and surfacing telemetry problems. |
Reading the data
The last group connects to data, carefully.
| Skill | What it does |
|---|---|
live | Reads the production database for a real number or to diagnose a player’s report. Gated: runs through a script, read-only, explicit permission, and it cannot write to live by design. |
staging | The same, pointed at staging. |
Why write any of this down
You could do all of this with careful prompting every time. The problem is that prompting doesn’t persist. You explain your conventions, the session ends, and tomorrow you explain them again. Switch models and you start over. Come back after a week and you’ve forgotten half of them yourself. I didn’t plan any of these out. I threw a rough version in the first time I needed it, then tweaked it whenever it got something wrong.
A skill is the fix. The knowledge stops living in my head and in throwaway prompts, and starts living in the repo where the AI reads it fresh every time. Generated content can’t break the balance because a content skill won’t let it. The code stays consistent because the conventions are written down. I see a cascade before I cause it, and shipping a version goes the same way every time. None of that is the AI being clever. It’s me having made each decision once, on purpose, and never having to make it again.
I build Inselnova, a free browser strategy game, this way. Play here.
