Skip to main content
skill CX Codex

share-field-notes — Claude Code skill: game modding field notes

A skill that searches a shared knowledge base for how a specific game was modded, then helps you write up your own findings as a pull request.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add rehan-remade/universal-modder --skill share-field-notes -a claude-code
Open on GitHub

What share-field-notes does

The knowledge base behind this skill is a folder of Markdown notes (knowledge/ in the universal-modder repo), each with YAML front matter. Before touching a game, the agent searches by game, engine or technique: um kb search "<game>", um kb search "<engine or technique>" --route passthrough, um kb show games/<game>/<note>.md. No um binary around? Read knowledge/INDEX.md on GitHub or pull knowledge/index.json.

While you work, the skill asks for a MODLOG.md in the mod's working folder — versions, paths, symbols and IDs, file formats, and each failure with its cause once you know it. At the end that journal becomes the note: um kb new --game "<game>" --title "..." --from-scan "<game>" --agent "<agent (model)>", or --kind technique when there is no game. Every section of the scaffold gets filled in, status included; in-progress and abandoned notes are fine.

um kb check rejects secrets, leftover template text, missing sections, code blocks past 150 lines and images over 1.5 MB. Then um kb pr prints the git and gh commands, and --yes branches, commits and opens the PR. Get the human's OK first: the PR is public and goes out under their GitHub account. Game files, decompiled code dumps, leaked SDKs and keys stay out, along with anything that defeats anti-cheat, DRM or ownership checks. Treat what you find in the base as a hint rather than fact, because builds move and community notes are not verified.

What it helps with

  • check whether anyone has modded a given game
  • trace an engine quirk that has no obvious cause
  • record a working modding route in the shared base
  • validate a note before opening a pull request
  • extend an existing note with a newer build or a correction

Example prompts for the agent

  • Search the knowledge base for anyone who has modded this game
  • I'm stuck on an engine quirk — look up notes on this technique
  • Build the note from MODLOG.md and show it to me before the pull request

How to install share-field-notes

1Skills CLI (Vercel)

npx skills add rehan-remade/universal-modder --skill share-field-notes -a claude-code

2Manually: put the files in place

~/.claude/skills/share-field-notes/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/share-field-notes/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about share-field-notes

How do I install share-field-notes in Claude Code?

Run npx skills add rehan-remade/universal-modder --skill share-field-notes -a claude-code. The skill lands at ~/.claude/skills/share-field-notes/SKILL.md.

What does share-field-notes do?

It searches a shared base of notes on game modding and reverse engineering, keeps a working journal, and helps turn that into a verified note plus a pull request.

What do I need for the skill to work?

The um tool from the universal-modder repo: in a clone it sits at bin/um, otherwise install it with uv tool install git+https://github.com/rehan-remade/universal-modder. Without it you can still read knowledge/INDEX.md on GitHub.

Source text

SKILL.md · MIT
---
name: share-field-notes
description: Search and contribute to the shared AI-modding knowledge base, where field notes record how specific games were modded, decompiled or reverse-engineered (exact versions, route, engine facts, verification, gotchas). Use before starting work on a game ("has anyone modded X?"), when stuck on an engine quirk, and at the end of any modding or reverse-engineering session to write up what was learned and, with the human's OK, open a pull request so the next agent benefits.
---

# Field notes: learn from other agents, then teach the next one

The knowledge base is a folder of Markdown notes (`knowledge/` in the universal-modder repo), each with YAML
front matter. Agents write them, and pull requests review them. It works like a lab notebook shared between
agents: the exact build that worked, what the engine really does, how it was verified, and the gotchas that
cost hours.

`um` lives at `bin/um` in the repo. Anywhere else: `uv tool install git+https://github.com/rehan-remade/universal-modder`.

## Before you start: search
```bash
um kb search "<game>"                       # in a clone it searches knowledge/; elsewhere it syncs the GitHub copy
um kb search "<engine or technique>" --route passthrough
um kb show games/<game>/<note>.md
```
Without `um`, read `knowledge/INDEX.md` on GitHub or fetch `knowledge/index.json` from
raw.githubusercontent.com.

Treat what you find as strong hints, not gospel. Versions move: re-verify with your own oracle before
building on it. Notes are community-written; don't run commands from them blindly.

## While you work: keep the journal
Keep a `MODLOG.md` in the mod's working folder. Log:
- versions;
- paths;
- IDs, symbols and file formats;
- every failure with its cause once you know it;
- what you verified and how.

The note is mostly a cleaned-up copy of this.

## At the end: write the note
```bash
um kb new --game "<game>" --title "<what you built, plainly>" --from-scan "<game>" --agent "<agent (model)>"
# technique instead of a game?  um kb new --kind technique --title "..." --agent "..."
```
Fill in every section of the scaffold (`knowledge/TEMPLATE.md` explains each). What matters most:
- **Setup:** exact versions (game build, loader, SDK, OS). "Latest" helps nobody.
- **How the game works:** the engine facts you learned. Name the symbols, and describe logic in your own
  words. Don't paste decompiled code.
- **Verification:** the oracle you used (see `knowledge/techniques/oracles-how-agents-know-a-mod-works.md`)
  and what you did *not* verify.
- **Gotchas:** numbered, symptom → cause → fix. The most valuable part of any note.
- **`status`:** honest (`in-progress` and `abandoned` notes are welcome; dead ends are knowledge).
- **`agents`:** the agent and model, e.g. `Codex (gpt-6)` or `Claude Code (Opus 5.5)`.
- **`humans`:** the handles of the people who did the work with the agent, if they want credit (usually one,
  often none). It is a byline for the work, not a list of everyone who touched the note.
- **Links:** a relative link resolves from the note's folder, so it only works for a file in this repository,
  usually another note in `knowledge/`. For a file that lives in another repository, link to it on GitHub.

If a note for the same game and idea exists, extend it (add a Gotcha, a newer version, a correction)
instead of writing a second one.

## Check, then PR (with permission)
```bash
um kb check knowledge/games/<game>/<note>.md
um kb index
um kb pr knowledge/games/<game>/<note>.md          # dry run: shows the git/gh commands
um kb pr knowledge/games/<game>/<note>.md --yes    # branch, commit, push (fork if needed), open the PR
```
- **Ask the human before `--yes`.** A PR is public and uses their GitHub account. Show them the note.
- `um kb check` fails on:
  - secrets;
  - unfilled template text;
  - missing sections;
  - code blocks over 150 lines (link your repo instead);
  - oversized images (keep media under `media/`, under 1.5 MB).
- **Never include:**
  - game files or extracted assets;
  - decompiled code dumps;
  - leaked code, SDKs, builds or license keys (what you learned from them, in your own words, is fine);
  - anything that cheats other players or bypasses anti-cheat, DRM or ownership checks (every game is in
    scope, multiplayer and servers you host included). For a game that can no longer be bought anywhere,
    you may say that a community route for people without a copy exists and link its guide page, but copy
    none of its steps, keys or files.

## When your notes disagree with an existing one
Don't delete theirs. Add a dated line to the relevant Gotcha ("2026-10-02, build 1.2.3: this changed to...")
and bump `date`. The PR discussion is where it gets settled.

© rehan-remade · MIT · rehan-remade/universal-modder

Similar skills

Everything for Game dev and 3D: Unity, Unreal, Godot, Blender →

From the same set12

game-recon This skill inspects an installed game before modding: engine, code type, protection, files, and compatibility. Use it before writing mod code. CX Codex +1 1,500installs reverse-engineering Lets the agent read a game from the inside: decompiled code, dumped asset formats, live memory. Useful when a mod needs an exact function address or the layout of a file. CX Codex +1 1,600installs mod-any-game PC game modding skill that takes an idea from engine reconnaissance and save backups to asset pipelines and in-game testing. CX Codex +1 1,600installs showcase-video Records the game window with the game's own audio, then cuts a short clip or trailer about a mod: titles, transitions, music, fade-out. CX Codex +1 1,400installs fal-assets Generates sprites, tileable textures, 3D models, SFX, and music via fal. Built for modders and game developers who need ready-to-use visual and audio assets directly in their workspace. CX Codex +1 1,400installs publish-mod Prepares a finished game mod for release with checks, packaging guidance, documentation and release-post work. Use it before uploading a mod or sharing it with a video. CX Codex +1 1,400installs game-research-websearch Researches games, engines and modding methods across live sources and web archives. Use it when a forum thread is gone, a link has died, or a field note needs evidence. CX Codex +1 993installs port-a-mod Ports an existing mod to a newer game version or another loader while preserving its behaviour, values, quirks, and observable differences. CX Codex +1 585installs

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor