Your Codex Skills Should Evolve With Your Project (Ion Viper Part 2)

How I Used 8 Codex /goal Runs to Build a Browser Game From Scratch ended with a line I’d been sitting on for the whole post: “Part 2 is where it gets interesting.”

Let me deliver on that.

Seven more /goal runs. ~133 minutes of autonomous Codex time. Boss fights, three enemy archetypes, a power-up system, randomized waves, and a New Game Plus loop that keeps escalating difficulty. The game that was fun for 90 seconds now has a real ending — and a reason to keep playing past it.

Here’s the thing, though.

The more important story is what had to change in the skill before any of that was possible.

webg-spec-to-goal from Part 1 could scaffold a brand-new project and generate all its goals in one pass. Powerful for a greenfield build. Useless for extending a game that already had a working codebase and dozens of passing tests.

It needed to learn a second mode.

.

.

.

Where Part 1 Left Off

Quick recap for context:

Part 1
Goals	8
Autonomous time	~78 minutes
Tests	39
Skill	webg-spec-to-goal — scaffold + generate all goals at once
Result	Playable, fun for ~90 seconds

The previous post covers the full foundation — what /goal is, how goals are structured, and how each goal builds on the last. Read it here if you haven’t.

This post assumes you have.

.

.

.

You Can’t Plan Everything Upfront

The original webg-spec-to-goal skill had one mode: start from scratch.

Write a paragraph describing a game. Get a starter project, a plan, and all goals. Run them in sequence. Done.

That works for an MVP.

It breaks the moment you want to add features to an existing codebase.

The first time I tried to add features to Ion Viper after Part 1, I instinctively reached for the same skill. It took about ten seconds to realize the problem — the skill’s first step was scaffolding, which would overwrite the entire project I’d just built.

After Part 1, Ion Viper was a working project — code, tests, game systems all in place. The codex goal command had built it, and the skill had no way to continue from it.

Three concrete problems:

1. No project awareness. The skill always scaffolded a new project. Running it again would overwrite everything — scenes, tests, config, all of it.
2. No goal continuation. Goal numbering started at 00. There was no mechanism to pick up from 08 and continue the sequence.
3. No awareness of existing game state. New goals needed to know what systems already existed. Without that awareness, they’d duplicate work or introduce conflicts with existing tests.

If you use autonomous coding tools long enough, every project hits this moment. The initial plan is exhausted, the codebase is substantial, and the tool needs to extend what’s there rather than start over.

The solution: teach the skill a second mode.

.

.

.

Teaching the Skill to Extend

Two changes turned webg-spec-to-goal from a one-shot scaffolder into a tool that grows with the project.

Extend mode. When the user asks to add features to an existing game, the skill switches behavior:

• Reads the existing project to understand what’s already built
• Skips scaffolding entirely (the project already exists)
• Continues goal numbering from the highest existing goal
• Appends new goals to the existing plan
• Generates only the new goal folders

QC Checkpoint. A new goal type that always lands last in any extension sequence.

It adds no features. Instead, it validates the full gameplay loop from start to finish and catches integration bugs that individual goals might miss.

(More on this one later — it earned its own section.)

Under the hood, the skill now branches early.

It detects whether you’re starting fresh or extending, and adjusts accordingly — skipping the scaffolding step and generating only the new goals while leaving everything else intact.

Here’s what makes extend mode reliable: it reads the existing plan before generating anything. That document captures the genre, the progression so far, and what’s already been built. The skill doesn’t guess what’s already there — it reads the evidence.

.

.

.

The Enhancement Prompt

The enhancement description was six features in plain English:

1. Rebrand from “Raiden Shooter” to “Ion Viper”
2. Ion Blast power-up — timed multi-projectile firing
3. Boss fight — multi-phase, health bar, victory screen
4. New Game Plus — difficulty escalation on restart
5. Enemy archetypes — at least 3 types with unique behaviors
6. Randomized wave positioning

Compare that to Part 1’s four-sentence game description.

The enhancement prompt is longer because it describes specific features to add to a game that already exists. Adding to a working system demands more precision than describing one from scratch.

The skill took those six features, confirmed scope in one clarification round (“Go with your recommendations” — same as Part 1), and generated 7 new goals (08–14) in a single 14-minute invocation.

Here’s what it produced:

#	Goal	What it adds
08	Rebrand to Ion Viper	Game identity and metadata
09	Ion Blast Power-Up	Timed multi-projectile pickup
10	Enemy Archetypes	Drifter, shooter, charger — three distinct behaviors
11	Randomized Waves	Balanced random spawn positions and timing
12	Boss Fight	Multi-phase boss, health bar, victory screen
13	New Game Plus	Difficulty loop, multipliers, clean restart
14	QC Checkpoint	Full-loop validation and integration testing

.

.

.

Goals 08–13: The Enhancement Assembly Line

Same pattern as Part 1.

Paste the /goal command, swap the folder name, press enter, walk away.

Goal 08 — Rebrand to Ion Viper (7m 15s, 42 tests). A metadata pass — updated the game title, browser tab, and package info. Lightweight by design. Confirms the codebase is stable before real feature work begins.

Goal 09 — Ion Blast Power-Up (19m 36s, 47 tests). The first real feature addition. A timed pickup grants multi-projectile firing for a limited window. At 19 minutes, this was the longest non-QC goal — adding a brand-new game system on top of an existing one takes more work than extending a familiar pattern.

Goal 10 — Enemy Archetypes (14m 30s, 53 tests). Three enemy types replaced the single drone from Part 1. Basic drifters float downward predictably. Shooters fire projectiles back at the player. Chargers telegraph with a flash, then rush. Each type has its own health, speed, score value, and behavior — and the system is designed so adding more types later is a config change, not a rewrite.

Goal 11 — Randomized Waves (15m 30s, 57 tests). Spawn positions, timing, and lane spacing are now randomized within fair bounds. Players can’t memorize patterns anymore. The randomization layer plugs into the existing wave and spawning systems without replacing them.

Goal 12 — Boss Fight (13m 57s, 62 tests). After all waves clear, a multi-phase boss spawns with a visible health bar. Three attack phases, each with different patterns. Defeat it and you reach the victory screen. The game finally has a real ending.

Goal 13 — New Game Plus (16m 58s, 65 tests). The victory screen now offers a restart into a harder loop. Enemies get faster, tougher, and the boss scales up — all through multipliers that layer on top of the base difficulty. Loop 2 is harder than loop 1. Loop 3 escalates further.

The test count across the six goals tells the story: 42 → 47 → 53 → 57 → 62 → 65. Each goal adds its own automated tests and runs every previous test too. By Goal 13, every system from foundation to New Game Plus is covered.

.

.

.

Goal 14: The QC Checkpoint — Where the Bugs Were Hiding

Stay with me on this one, because it changed how I think about autonomous goal chains.

The QC checkpoint is a different kind of goal.

Goal 14 adds no mechanics, no art, no content.

It runs the full gameplay loop — boot, menu, play, waves, boss, victory, New Game Plus, restart, lose, game over, restart — and checks that everything reports correctly through every transition.

I expected Goal 14 to be a formality. A quick pass, green tests, done in five minutes. Instead it ran for 31 minutes and surfaced four bugs I hadn’t noticed during any of the previous six goal runs.

~31 minutes.

The longest goal in the entire project, longer than Part 1’s 26-minute polish goal.

What the QC checkpoint caught and fixed:

• Stale game-over state. Game data wasn’t clearing properly on restart. A player who died and restarted carried ghost data from the previous run.
• Ion Blast firing edge case. The SPACE key needed hardening to prevent firing during pickup collection — a timing conflict between the weapon system and the power-up system.
• Wave projectile cleanup. Enemy projectiles from cleared waves weren’t cleaning up on scene transition. They accumulated silently across wave boundaries.
• Final wave timing. Timing adjustments were needed to ensure wave completion triggers the boss reliably instead of leaving the player in a dead state.

Every one of these is an integration bug. Each individual goal passed its own tests. But when the full loop ran — menu to waves to boss to victory to restart to game over to restart again — transitions between systems exposed assumptions that no single goal’s tests would catch.

👉 The QC checkpoint tests the seams between goals.

67 tests at the end. All passing. Including a new end-to-end test that exercises both the full win path and the full loss path.

When seven autonomous goal runs build on each other without human review between them, compound integration risk is real. Catching it automatically — before manual playtesting — makes the entire chain trustworthy.

.

.

.

Does It Actually Work?

Same instinct as every post in the series: close the terminal and play it.

Part 1’s version was fun for 90 seconds.

Part 2’s version kept me playing for longer than I’d admit.

Open the browser. Menu screen, now branded “Ion Viper.” Press SPACE.

Enemies descend — but they’re not uniform anymore. Drifters float down predictably while shooters fire back. Chargers telegraph with a flash, then rush straight at you. Spawn positions are randomized, so every playthrough arranges differently.

A glowing pickup drops. Collect it — Ion Blast activates. Your ship fires a spread of projectiles for a limited window. Clear the waves fast.

And then the boss arrives. Health bar at the top of the screen. Three attack phases. Dodge patterns change as the boss takes damage. Beat it — victory screen. “Continue to New Game Plus.” Accept.

Loop 2 starts.

Enemies are faster and tougher. The boss has more health. Die — game over, final score, restart option.

(I restarted four times before I remembered I was supposed to be writing this post.)

What Part 2 added: Ion Blast power-up, 3 enemy archetypes, randomized wave positioning, boss fight with phases, victory screen, New Game Plus difficulty loops.

What’s still absent: multiple power-up types, more than one boss, mobile controls, persistent leaderboards.

The game is playable.

It has a real ending, replayability through difficulty escalation, and it delivers what the enhancement prompt asked for.

Play it yourself: https://stunning-paprenjak-6fc3dd.netlify.app/

.

.

.

The Numbers

Part 2 build summary:

• Skill invocation: 1 (extend mode — generated 7 new goals)
• Goal runs: 7 (Goals 08–14)
• Total autonomous time: ~133 minutes (~14 min skill + ~119 min goals)
• Total human input: one enhancement paragraph + “Go with your recommendations” + 7 /goal pastes
• Tests: 67 (up from 39 at end of Part 1)
• Source files: 28 (up from 18)
• Lines of game code: ~3,265 (up from 1,463)
• Assets: 19 files (images + audio + data)

Combined totals (Part 1 + Part 2):

	Part 1	Part 2	Combined
Goals	8	7	15
Autonomous time	~78 min	~133 min	~211 min
Tests	39	67	67 (cumulative)
Lines of code	1,463	3,265	3,265 (cumulative)

Series comparison (all four posts):

Post	Domain	Goals	Autonomous time	Tests
1	WordPress plugin	1	28 min	browser checks
2	CLI tool	2	80 min	35
3	Browser game (Part 1)	8	78 min	39
4	Browser game (Part 2)	7	133 min	67

Worth noting: Part 2’s per-goal average (~17 minutes) is higher than Part 1’s (~10 minutes). Feature goals on an existing codebase are more complex than greenfield goals — more existing code to understand, more systems to coordinate, more tests to run. The codex goal command does the same thing in both cases, but the surrounding context is heavier.

.

.

.

Skills Are Living Documents

Three posts ago, wp-spec-to-goal generated one goal. Two posts ago, cli-spec-to-goal detected that a project needed splitting and generated goals one at a time. One post ago, webg-spec-to-goal generated all goals at once from a single paragraph.

This post: the same skill learned a second mode.

The pattern across the series is consistent.

Each skill starts simple and gets smarter based on what the project demands. Domain knowledge accumulates in the skill — in its instructions, its templates, and its logic for deciding when to scaffold versus when to extend.

What webg-spec-to-goal knows now that Part 1’s version didn’t:

• How to read an existing project’s state before generating goals
• How to continue goal numbering from an existing sequence
• How to inherit existing game state without duplicating it
• That a QC checkpoint at the end of a long chain catches integration bugs that individual goals miss

None of this was planned in advance.

The skill evolved because the project demanded it.

Here’s what changed in how I think about this: the investment in the skill compounds. Build webg-spec-to-goal once for Part 1, extend it for Part 2, reuse the extend mode and QC checkpoint for the next game after that. The codex goal command executes what the skill produces — and the skill keeps getting better at producing the right thing.

The skill is open source at github.com/nathanonn/agent-skills. The game repo is at github.com/nathanonn/ion-viper. Clone it, run npm install && npm run dev, and play the version that 15 autonomous goal runs built.

What’s next: skills for other domains.

The three sibling skills (wp-spec-to-goal, cli-spec-to-goal, webg-spec-to-goal) share the same structural patterns but each one carries domain knowledge the others lack.

The question is where that pattern goes next.