Build a native 8086 assembly remake of a console/arcade game (reference = a disassembly or source tree) as an os8088 package, the way apps/drmario (DrMarco), apps/1942 and apps/excitebike were made…
Install the "native-game-port" agent skill from https://github.com/jggonz/os8088/tree/main/.claude/skills/native-game-port into .claude/skills/native-game-port/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "native-game-port", then confirm the skill loads.
Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Type this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
skills CLI
$ npx skills add jggonz/os8088 --skill native-game-port -a codex
Project install goes to .agents/skills/; add -g for ~/.codex/skills/.
Install the "native-game-port" agent skill from https://github.com/jggonz/os8088/tree/main/.claude/skills/native-game-port into .agents/skills/native-game-port/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "native-game-port", then confirm the skill loads.
Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add jggonz/os8088 --skill native-game-port -a cursor
Project install goes to .agents/skills/; add -g for ~/.cursor/skills/.
Install the "native-game-port" agent skill from https://github.com/jggonz/os8088/tree/main/.claude/skills/native-game-port into .cursor/skills/native-game-port/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "native-game-port", then confirm the skill loads.
Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
skills CLI
$ npx skills add jggonz/os8088 --skill native-game-port -a gemini-cli
Project install goes to .agents/skills/; add -g for ~/.gemini/skills/.
Install the "native-game-port" agent skill from https://github.com/jggonz/os8088/tree/main/.claude/skills/native-game-port into .gemini/skills/native-game-port/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "native-game-port", then confirm the skill loads.
Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
GitHub CLI
$ gh skill install jggonz/os8088 native-game-port
Installs for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
skills CLI
$ npx skills add jggonz/os8088 --skill native-game-port -a github-copilot
Project install goes to .agents/skills/; add -g for ~/.copilot/skills/.
Install the "native-game-port" agent skill from https://github.com/jggonz/os8088/tree/main/.claude/skills/native-game-port into .github/skills/native-game-port/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "native-game-port", then confirm the skill loads.
GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add jggonz/os8088 --skill native-game-port -a opencode
OpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
Install the "native-game-port" agent skill from https://github.com/jggonz/os8088/tree/main/.claude/skills/native-game-port into .opencode/skills/native-game-port/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "native-game-port", then confirm the skill loads.
OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
Skill name
native-game-port
GitHub stars
104
Token cost
~2.9k tokens
SKILL.md length
1,510 words
Files
3
Skills in repo
7
Repo updated
First seen
Licence
MIT
At a glance
Build a native 8086 assembly remake of a console/arcade game (reference = a disassembly or source tree) as an os8088 package, the way apps/drmario (DrMarco), apps/1942 and apps/excitebike were made…
Works in 6 steps: Match the cartridge, depend on nothing -… → Intake → Preflight → …
The user asks to port
SKILL.md covers 0. Match the cartridge, depend…, 1. Intake, 2. Preflight and 3. Run the workflow, plus 3 more sections
Runs JavaScript scripts from its folder; calls git, codex and gh
What it does
Native Game Port is an agent skill from jggonz/os8088. Build a native 8086 assembly remake of a console/arcade game (reference = a disassembly or source tree) as an os8088 package, the way apps/drmario (DrMarco), apps/1942 and apps/excitebike were made - levels and look matched to the cartridge, committed assets made once (codex/imagegen art), NO build-time dependency on the reference, XT-4.77MHz-first speed. Drives one Workflow - five scouts, an architect plan, sequential waves (implement, three review lenses, fix, independent verify with one repair round), then a…
Its SKILL.md is about 2.9k tokens, which your agent loads only when the skill is triggered. The skill folder holds 3 other files (for example `LESSONS.md` and `workflows/port.js`).
It sits in Media & Creative, covering Image generation. The licence is MIT.
When your agent uses it
The user asks to port
Bring a NES/arcade/console game to os8088 as a fast native game
Example prompts
“/native-game-port”
Requirements
Node.js
Workflow steps
6 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit 95f7e97. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Ships script files (JavaScript), which the agent can run.
Shell commands in SKILL.md call:
git
codex
gh
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md. Its commands use git and gh, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Native Game Port loads about 2.9k tokens when it runs. Until then it costs about 202 tokens; SKILL.md has 1,510 words of instructions outside code blocks.
Always· name and description, kept in context so the agent knows when to use it
~202
When it runs· the whole SKILL.md, loaded when a task matches
~2.9k
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
Download SKILL.mdSave it as .claude/skills/native-game-port/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.
name
native-game-port
description
Build a native 8086 assembly remake of a console/arcade game (reference = a disassembly or source tree) as an os8088 package, the way apps/drmario (DrMarco), apps/1942 and apps/excitebike were made - levels and look matched to the cartridge, committed assets made once (codex/imagegen art), NO build-time dependency on the reference, XT-4.77MHz-first speed. Drives one Workflow - five scouts, an architect plan, sequential waves (implement, three review lenses, fix, independent verify with one repair round), then a completeness critic and a performance audit - and ends in a PR. Use when the user asks to port, remake or bring a NES/arcade/console game to os8088 as a fast native game. For porting a desktop PROGRAM written in C/other languages as a C package use port-to-os8088 instead.
Native game port (assembly, XT-first)
This is the technique that produced apps/excitebike/ (SPEC.md §102, PR #206)
in one orchestrated run on Sonnet 5.5 (53 agents, 7 waves, ~83 minutes of
wall clock). Agents inherit the session model - never pass a model
override - so whatever model you are running is the one that builds the game.
It was sized for that model; a larger one just needs fewer repair rounds.
What it makes: a native remake, not an emulator. The simulation is the
package's own code, ported routine by routine from the reference's rules. The
picture, courses and sound are the cartridge's, extracted once into committed
sources. The publisher's marks are replaced with generated art, and the game
carries its own name. The whole thing is priced against a 4.77MHz 8088 and
verified on MartyPC's cycle counter. Precedents to name in every agent brief:
apps/drmario/ (SPEC §100: splash, animation, embedded-art streams; its generated-art prompts are the model for section 5a),
apps/1942/ (SPEC §101: FSX pages, CRTC scrolling, compiled sprites, latch
copies, dirty rectangles), apps/excitebike/ (SPEC §102: horizontal scroll).
LESSONS.md beside this file is what the Excitebike run learned the hard way.
Read it before step 1.
0. Match the cartridge, depend on nothing - ask it first
Two requirements, both the user's, and they pull against each other only if
you confuse them:
The game matches the cartridge: the levels, tables and rules, and the
look and sound of the graphics and audio.
Nothing depends on the reference being present. A plain make on a
machine without it builds the whole game; no test requires it (comparisons
SKIP cleanly when it is absent); no ROM image, CHR dump, sample or note
stream is read at build or run time. Anything taken from the reference is
taken ONCE, at authoring time, by a one-off tool that make never runs
(tools/<name>_transcribe_once.py), and only the result is committed, in
our own format, with a provenance line in apps/<name>/art/README.md. A
fast-tier provenance gate (tests/unit/t_<name>_clean.py) fails the build
if a reference path or importer creeps into make. A drift row re-runs the
one-off tool when the reference IS present, requires the committed output
to be byte-identical, and SKIPs without it.
The publisher's marks are replaced, and no copyright line is shown. The
title logo, any publisher or sponsor plate drawn in the game, the game's
trademarked name wherever it is printed, and the copyright line are the
only things NOT kept. Replace the marks with art generated per section 5a,
quantized into the cartridge's own tile format and palette and hand-finished
in the committed tile source. The copyright row is left blank, and no screen
or splash carries one. Every replaced tile is listed in the provenance file.
The game takes a display name of its own (Dr. Mario → DrMarco, Excitebike →
8BitBike) and an 8.3 package stem from it.
Excitebike took three tries to reach this. The first launch planned
DrMarco's shape, a CHR importer read at build time, and the user stopped it:
"It shouldn't be that way." The second shipped all-original art (PR #206).
Then the user asked for "the original game graphics, levels, etc." without
relying on the source being available, and for the marks replaced with
generated art. That is artMode: extract plus requirement 3, and
excitebike_plan.md is the worked plan. So at intake ask, with
AskUserQuestion, what "match" means for graphics and audio (levels and
tables are always transcribed unless the user says otherwise):
Extract exactly, once (Recommended) - artMode: extract. A one-off tool
converts the cartridge's tiles, palettes, screens and sound data into
committed text sources in our own format: pixel-exact, and diffable. The
marks are still replaced (requirement 3). The licensing call is the user's;
say so in the PR.
Recreate the look - artMode: recreate. Same poses, sprite roles,
palette feel, layout, scale and animation timing, but every committed pixel
and note is newly made with the image generator (section 5a) and procedural
tools. Reference frames are studied, never attached as inputs or traced, and
their bytes are never committed.
Original designs - artMode: original. In the spirit of the game, not
copies.
Also ask for the display name (requirement 3), unless the user gave one.
Prove the match against the real game, recorded once. Where the reference
assembles into a ROM, a host emulator (agnes, MIT, for NES) runs it with
scripted controller bytes, and the recordings are committed as fixtures:
per-frame state, frame buffers and the APU note log. The gates compare the
guest against those fixtures on MartyPC, so they need neither the reference
nor the emulator. A mode that never reads the RNG is compared byte for byte
every frame; one that does gets the recorded RNG bytes injected. 1942's lesson
applies: port the ROUTINE that reads a table, not the table alone.
Levels, piece/obstacle grammar, speed and timing tables, par times and rules
are transcribed once into committed text sources (Excitebike's .trk files)
so the game plays the original's courses; deliberate deviations go in
tests/<name>_ref_deviations.txt with a reason each. Pass levels: "original" to skip that.
1. Intake
Reference path (default: a sibling checkout such as
../NES-Games-Disassembly/<Game>), the game's name, its display name
(section 0, requirement 3), and an 8.3-safe package stem taken from that
(8BitBike is 8BITBIKE.O88).
The art question in section 0. 3. Scope: which modes must ship; say what is
expected to be cut (Excitebike cut design mode, two-player, PCM - and said
so in the PR).
Read docs/INDEX.md, SPEC.md §100-§102 headings, and LESSONS.md.
Show full SKILL.md (632 more words)Show less
2. Preflight
git fetch origin
git worktree add -b game/<name> /tmp/<short> origin/main # SHORT path: sockets die past ~100 chars
mkdir -p /tmp/<short>-reports
cp -R <main>/build/martypc /tmp/<short>/build/martypc # a copy, not a symlink; `make marty` if stale
One worktree, one writer at a time. Other sessions dirty the main checkout and
run their own emulators: never pkill -f, never git add -A/-u, never touch
main.
3. Run the workflow
Workflow({ scriptPath: "<repo>/.claude/skills/native-game-port/workflows/port.js",
args: { repo: "<abs main repo>", worktree: "/tmp/<short>", ref: "<abs reference dir>",
name: "<Game>", stem: "<pkgstem>", reports: "/tmp/<short>-reports",
scope: "<what must ship / may be cut>", artMode: "extract", levels: "transcribe" } })
args can arrive as a STRING in some harnesses; the script parses it and has
defaults, so a bare launch with edited DEFAULTS also works. Phases (skipScout: true reuses existing reports):
phase
agents
output
Scout
5 parallel: game logic, graphics, audio, perf techniques, integration checklist
<reports>/scout-*.md
Plan
1 architect
docs/plans/<NAME>-PLAN.md and a wave list (4-7 waves, acceptance = a command or a measurement)
Waves
per wave: implement -> 3 lenses (8086/memory, XT performance, fidelity) -> fix -> independent verify -> one repair + re-verify
wave-N-impl/fix/repair.md, screenshots
Close
completeness critic (fixes mechanical gaps, runs make + test-full), perf audit (writes a PERFORMANCE.md Set)
close-*.md
Sequential waves are deliberate: each builds on the last and there is one
writer. Parallelism is inside a wave (the lenses) and in scouting.
While it runs, do not touch the worktree or start another make there (a
concurrent build fails make's wall-clock gate and clobbers build/).
4. Decide and report
Read the workflow's return plus close-critic.md and close-perf.md. Report
to the user: per-wave pass/fail with the measured numbers, the gaps the critic
left open, and anything the plan cut. Numbers come from MartyPC cycle
counters, never from wall clock or QEMU, and say which adapter.
5a. Art generation
Masters come from an image generator; production assets are derived from them
deterministically. In extract mode the generator makes only the replacements
for the marks (the logo, plates and name, sized to the tiles they replace) and
the desktop splash. A 144x16 wordmark is below what a generator draws well, so
treat the master as a guide: quantize it into the cartridge's tile format and
palette, hand-finish it in the committed tile source, and that edit is the art.
Probe in this order and use the first that exists:
codex CLI (tested on codex-cli 0.157.1, image_generation feature
stable): from a scratch directory,
codex features list | grep image_generation # must say true
codex exec --skip-git-repo-check --sandbox workspace-write -C <scratch> \
"Use your image generation tool to create <prompt>. Save the PNG into the current directory as <name>.png and print its path."
~100 s and ~12k tokens for one small image; it also leaves a copy under
~/.codex/generated_images/. Run it in the BACKGROUND (run_in_background)
and read the file when done. Run from outside the repo (it can hang in a
repo checkout), never --dangerously-bypass-approvals-and-sandbox, and do not
pass --image with cartridge frames in recreate mode.
The session's own image tool (mcp__mcp-image__generate_image, or the
built-in imagegen DrMarco and 1942 used).
No generator: procedural host drawing only (DrMarco's germs and checkerboard
are drawn that way) and say so in the PR.
Write prompts like apps/drmario/art/PROMPT.md: use case, asset type, the
logical grid (e.g. 320x240), exact pixel regions that must stay black for the
engine, palette list, "hard edges, no gradients or anti-aliasing", "no text,
logos or watermarks" (except the new name, spelled out, where it is the asset),
"no publisher wording, no original title, no copyright line", and in recreate mode the measurements and poses of
the original in words. Commit the master PNG plus the exact prompt
(art/PROMPT.md) and the derive tool; look at every generated image (Read the
PNG) before building on it, and check it survives 4-colour CGA and 1bpp
Hercules. Generators drift: pin assets by committing the master, never by
regenerating in make.
6. Ship
Commit with explicit paths (never -A): package dir, tools, tests, SPEC
section, plan, PERFORMANCE Sets, INDEX (regenerated), Makefile/suite/retired
edits, vm/xt-<name>/. Push to origin, gh pr create --base main, put the
measured table and the known gaps in the body. Attribution lines per the
session's commit/PR reminder. Do not merge; merges need --admin and are the
maintainer's call.
Native Game Port next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
Creates or analyzes quiet, paper-texture zine posters with big negative space, one color accent and experimental type, returning an image prompt and the generated poster.
Functionally verify a change on the glass before it merges - boot the built OS in QEMU, drive the actual UI the change proposes (mouse, keys, menus) over QMP, screenshot the evidence for every…
Port an existing program - written in C or in any other language - to os8088 as a C package (SPEC.md §73), the way apps/cword ported Microsoft Word 1.1a.
Bring one of the maintainer's own stale pull requests (a branch on jggonz/os8088 that main has moved past) back to mergeable - merge main into it in a scratch worktree, decide whether it is still…
Review an incoming pull request that comes from someone else's fork of os8088 - fetch it, merge main into it, review it with a team of agents for memory safety, lost-from-main regressions, redraw…
Give an os8088 package a COLOUR FACE on VGA/EGA - fewer redraws first, then a neater layout, styled panes and bevelled, picture-faced buttons with their captions inside - while the Hercules and CGA…
Build a native 8086 assembly remake of a console/arcade game (reference = a disassembly or source tree) as an os8088 package, the way apps/drmario (DrMarco), apps/1942 and apps/excitebike were made…. Native Game Port is an agent skill from jggonz/os8088.77MHz-first speed.
When should I use Native Game Port?
Native Game Port fits situations like: the user asks to port; bring a NES/arcade/console game to os8088 as a fast native game.
How do I install Native Game Port in Claude Code?
Run `npx skills add jggonz/os8088 --skill native-game-port -a claude-code`. Or copy the skill folder (.claude/skills/native-game-port in jggonz/os8088) into .claude/skills/native-game-port in your project. Claude Code loads it when a task matches its description.
How do I install Native Game Port in Codex?
Run `npx skills add jggonz/os8088 --skill native-game-port -a codex`. Or copy the skill folder (.claude/skills/native-game-port in jggonz/os8088) into .agents/skills/native-game-port in your project. Codex loads it when a task matches its description.
Can I use Native Game Port in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add jggonz/os8088 --skill native-game-port -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/native-game-port, .gemini/skills/native-game-port, .github/skills/native-game-port and .opencode/skills/native-game-port in your project.
What does Native Game Port need to run?
Going by SKILL.md and its folder, Native Game Port needs JavaScript for the scripts in its folder and the command-line tools its instructions call (git, codex and gh). Our summary lists: Node.js.
Does Native Game Port access the network?
SKILL.md contains no URLs. Its commands use git and gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Is Native Game Port safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Native Game Port use?
Native Game Port is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Native Game Port use?
About 2.9k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Native Game Port?
Skills that share tags, products or a category with Native Game Port: AI Image Generation and Editing (zhayujie/CowAgent, 47k stars), Structured Image Generation (bytedance/deer-flow, 84k stars), Canghe Comic (freestylefly/canghe-skills, 461 stars) and Generate Image (ynulihao/AgentSkillOS, 618 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Native Game Port?
jggonz (a GitHub user) maintains it in jggonz/os8088, which has 104 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on October 8, 2026.
Source: jggonz/os8088 on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.
