Agent skill

KenshiCoop Save Orchestration

by nhoral in nhoral/KenshiCoop

Picks the right save file and script for a KenshiCoop debugging or validation session, and protects version-controlled fixtures from being overwritten.

AGPL-3.0Auto-check passedGame Development

Install KenshiCoop Save Orchestration

skills CLI
$ npx skills add nhoral/KenshiCoop --skill coop-save-orchestration -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install nhoral/KenshiCoop coop-save-orchestration --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/nhoral/KenshiCoop.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.cursor/skills/coop-save-orchestration .claude/skills/coop-save-orchestration && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
coop-save-orchestration
GitHub stars
285
Token cost
~2.4k tokens
SKILL.md length
1,103 words
Files
1
Skills in repo
2
Repo updated
First seen
Licence
AGPL-3.0

At a glance

Picks the right save file and script for a KenshiCoop debugging or validation session, and protects version-controlled fixtures from being overwritten.

  • Choosing which Kenshi save to load for a hands-on debugging session
  • SKILL.md covers How saves load, Pick the right orchestrator, Save catalog and Fixture store: repo-tracked…, plus 1 more section
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md
  • Validating one co-op scenario or running the full regression matrix

What it does

Explains how Kenshi saves auto-load from one shared per-user AppData folder that both the host's Steam install and the Kenshi-Join install read, triggered by an environment variable the orchestration scripts set automatically. Because NPC and squad sync requires both clients on the identical save, two players sharing one world use one save with partitioned ownership rather than two separate saves that would desync.

A small set of PowerShell scripts covers each job: hands-on debugging with no self-exit or screenshots, a timed single-scenario validation judged by oracles into a verdict file, a full regression matrix with one pass or fail result, baking a fixture by running a setup scene headlessly against a base save, restoring pristine repo fixtures over the live AppData copy before every validation run, and capturing a save from AppData back into the repo as the only sanctioned way to update a tracked fixture.

The scenario manifest file is the single source of truth for which save and setup each named scenario uses, so adding or changing a scenario means editing that manifest rather than hardcoding a save name inside a runner script. Validation fixtures are restored fresh before every run specifically because a prior co-op session's live world sync can otherwise permanently drift the fixture.

When your agent uses it

  • Choosing which Kenshi save to load for a hands-on debugging session
  • Validating one co-op scenario or running the full regression matrix
  • Baking a new fixture save from a setup scene
  • Capturing an updated save from AppData back into the tracked repository

Example prompts

  • “Run the duel1 scenario validation and show me the verdict.”
  • “Bake a new fixture from the camp setup scene and promote it into the repo.”
  • “Launch a manual debugging session on the together save with inhabit mode.”

Requirements

  • PowerShell
  • Kenshi with the KenshiCoop plugin and Kenshi-Join installed

What it can do on your machine

Read from SKILL.md and the folder at commit 5a761e1. 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

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    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

KenshiCoop Save Orchestration loads about 2.4k tokens when it runs. Until then it costs about 176 tokens; SKILL.md has 1,103 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~176
When it runs · the whole SKILL.md, loaded when a task matches
~2.4k

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.

SKILL.md

The full file from nhoral/KenshiCoop at commit 5a761e1, republished under its AGPL-3.0 licence (© nhoral). 1,103 words, ~2,413 tokens.

Download SKILL.mdSave it as .claude/skills/coop-save-orchestration/SKILL.md (or your agent's skills folder).
name
coop-save-orchestration
description
Load and orchestrate Kenshi saves for KenshiCoop debugging and validation. Covers how saves auto-load (env vars + %LOCALAPPDATA%\kenshi\save), which script drives which job (manual_session.ps1 for hands-on debugging, run_test.ps1 / regress.ps1 for validation, bake_scene.ps1 for fixtures), the catalog of named saves and their uses (sync, squad1, duel1, camp, separate, together, ...), and the rule that validation saves must never be overwritten because the host connect-push bakes the live world over the loaded save and clobbers the fixture. Use when launching a co-op session, picking a save for a scenario, baking a fixture, or before doing anything that loads/writes a save.

KenshiCoop Save Orchestration

How saves load

  • Saves live in %LOCALAPPDATA%\kenshi\save\<name>\ (one folder per save, containing quick.save). Both the host Steam install and the Kenshi-Join install read this SAME per-user folder, so a save is visible to both clients with no copy step.
  • The plugin auto-loads a save from the title screen via env var KENSHICOOP_SAVE=<name>. The orchestration scripts set this for you.
  • Validation fixtures are version-controlled under fixtures/saves/<name>\. run_test.ps1 restores the pristine repo copy over the AppData copy right before every run (via deploy_saves.ps1), so a prior co-op run's connect-push / stream-commit can never permanently drift a fixture - drift is discarded each run. See the fixture workflow below.
  • Identity is resolve-by-hand: NPC/squad sync REQUIRES both clients on the IDENTICAL save. Two different saves mint different hands and desync. For two players sharing one world, use one save + partitioned ownership (-Inhabit), not two distinct saves.

Pick the right orchestrator

JobScriptNotes
Hands-on debugging / playscripts/manual_session.ps1Launches host+join, NO self-exit, NO screenshots. You drive and watch.
Validate ONE scenarioscripts/run_test.ps1 -Scenario <name>Timed, self-exits, judged by oracles → verdict.json. Save/setup default from the manifest.
Full regression matrixscripts/regress.ps1 [-Tier smoke|full]Builds once, runs the manifest matrix, single PASS/FAIL + history.jsonl.
Bake a fixture savescripts/bake_scene.ps1 -Setup <s> -BaseSave <b> -BakeSave <out> [-Promote]Headless: load base, run setup scene, auto-write the fixture. -Promote captures it into the repo.
Restore fixture(s) repo -> AppDatascripts/deploy_saves.ps1 -Save <name> (or -All)Mirrors the pristine repo copy over AppData. run_test.ps1 calls it automatically.
Capture a save AppData -> reposcripts/capture_save.ps1 -Save <name>The ONLY sanctioned way to update a tracked fixture (review the git diff).

The scenario manifest scripts/scenarios.psd1 is the single source of truth for which save + setup each scenario uses. When adding/altering a scenario, edit it there — do not hardcode saves in the runners.

Debugging: manual_session.ps1
powershell -ExecutionPolicy Bypass -File scripts/manual_session.ps1 -Save "together" -Inhabit

Common flags:

  • -Inhabit — shared save, partitioned squad ownership (host owns rank 0, join owns the rest). The supported two-player path; forces shared save + no autospawn.
  • -Sync — mirror the host save into the join install first (only needed for a real second machine; same-machine installs already share the folder).
  • -SkipBuild — reuse the current DLL (still deploys it).
  • -DebugMarkers — colored authority labels on the join (green DRV / red HID / yellow LOC).
  • -AutoSpawn N — host spawns N distinct-hand squad members to exercise cross-client render.
Validation: run_test.ps1 / regress.ps1
powershell -ExecutionPolicy Bypass -File scripts/run_test.ps1 -Scenario combat_kill
powershell -ExecutionPolicy Bypass -File scripts/regress.ps1 -Tier smoke

Save catalog

VALIDATION saves are referenced by scripts/scenarios.psd1 and must stay stable (see the golden rule below). DEBUG saves are for manual/exploratory sessions.

SaveClassUse
syncvalidationBar town + 2-tab squad + armed NPCs. The workhorse "live town": npc_sync, player_combat, assault_town, combat_crowd/battle/win, and most probe/sync scenarios.
squad1validationBaked 2-tab squad. coop_presence, inventory, medical, KO, stats, carry, sneak_pose, squad_sync.
squad2validation (fixture)Two squads whose PCs WEAR backpacks (itemType 46): inv_backpack_drop, inv_nested_bag, inv_dump_all(_forget/_transient). The only fixture with a worn container - squad1 has none, so those gates read have=0 there.
cvalidationcombat_probe / spike captures.
duel1validation (fixture)Two nearby non-squad NPCs for a duel: combat_order, combat_kill. Baked via bake_scene.
down1validationdown_order, death_order.
craft1validationDense town with node-anchored crafters: craft_order.
bedcage1validation (fixture)Baked Camp Bed + Prisoner Cage: bed_*, cage_*, chain_put.
pole1validation (fixture)Baked standing Prisoner Pole: pole_put.
campvalidationDense prison save (many NPCs): camp_approach, world_parity, shackle_*.
splitfar1validation (fixture)The pair SPLIT ~5200 u apart with NPCs at BOTH ends: split_far. Baked with bake_scene.ps1 -Setup splitfar -BaseSave separate, which parks the non-leader tab at a measured populated point. Re-make it that way, never via capture_save.ps1 - see the capture-after-a-run warning below.
jailedvalidationJoin PC caged: jail_probe / jail_soak.
rebirth1validation (fixture)Rebirth: the JOIN's whole squad is caged as slaves, with the two squads co-located and a zone-cell boundary a short walk away. Drives lockpick_escape and escape_cohesion, and is the co-location bed for authority A/Bs (tools/authority_ab.ps1).
coopresumevalidation (auto-written)Coordinated save/load transfer target (protocol 31/32). Written by the tests — never hand-edit.
zoomdebugOutside town, camera far out — long-run pop/snap inspection.
separatedebugThe pair SEPARATED — testing independent actions across distance.
togetherdebugThe pair TOGETHER — testing independent actions co-located.

Other saves in the folder (battle10/20/40, slaves save, cage2, on-pole, etc.) are ad-hoc testbeds; confirm intent before reusing them.

Show full SKILL.md (420 more words)Show less

Fixture store: repo-tracked pristine saves

Validation fixtures live under fixtures/saves/<name>\ (full save folder: quick.save, platoon/, zone/, portraits_texture.png) - the pristine source of truth. The tracked set matches the saves in scripts/scenarios.psd1: sync, squad1, squad2, c, duel1, down1, craft1, bedcage1, pole1, camp, jailed, coopresume, splitfar1, rebirth1. Debug saves (together, separate, zoom) are NOT tracked; drift there is fine.

  • Restore (automatic): run_test.ps1 restores the scenario's save from the repo over AppData before every launch, so regress.ps1 (which calls run_test per scenario) is self-healing. Restore manually with scripts/deploy_saves.ps1 -Save <name> or -All.
  • Update a fixture (deliberate only): re-make/bake the save, then promote it:
    • baked fixtures: bake_scene.ps1 -Setup <s> -BaseSave <b> -BakeSave <name> -Promote
    • hand-made saves: scripts/capture_save.ps1 -Save <name> Both mirror AppData -> repo; review the git diff and commit.

Why drift can't persist (and where it comes from)

When the host runs under save-sync and a peer connects, armConnectPush() (src/plugin/Plugin.cpp) bakes the live world with saveGameAs(<currentGame>) — i.e. it writes the CURRENT world state OVER the folder of the save that is loaded; the join also stream-commits the received world into the same folder. Both mutate the AppData copy in place. Historically this silently corrupted pole1 / duel1 mid-regression and made combat_order / combat_kill fail for reasons unrelated to the code under test. The repo fixture store fixes this: the game only ever writes AppData, which run_test.ps1 overwrites from the pristine repo copy each run, so drift is discarded.

Rules:

  • Do co-op experiments on a DEBUG save (separate, together, zoom, or a throwaway you create), not a validation/fixture save. (Even if a fixture drifts, the next run_test.ps1 restores it - but keep manual play off fixtures anyway.)
  • NEVER hand-edit fixtures/saves/* directly. Change a fixture only via bake_scene.ps1 -Promote or capture_save.ps1, then commit the reviewed diff.
  • Do NOT capture_save.ps1 a save that a CO-OP run just used to record the scene that run set up. armConnectPush bakes the live world early, before scenario positioning, so the captured folder holds the pre-scenario layout rather than the one you watched. This produced a splitfar1 with the squads together when the whole point was to have them 9800 u apart. Positioned scenes must be built by a bake_scene.ps1 SETUP (single host, no connect-push, explicit write).
  • To (re)create a baked fixture, use bake_scene.ps1 deliberately - that is the ONLY sanctioned way to write a fixture folder. After baking, spot-check that the scenario it feeds still passes, then -Promote / capture it.
  • If a functional test regresses for no code reason, suspect fixture rot in the REPO copy: re-bake (or re-make) the save, promote it, and re-run.

© nhoral, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .cursor/skills/coop-save-orchestration of nhoral/KenshiCoop.

Open the folder on GitHubat commit 5a761e1

Compare with similar skills

KenshiCoop Save Orchestration 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.

KenshiCoop Save Orchestration compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
KenshiCoop Save Orchestration this skillnhoral/KenshiCoop285—~2.4kAutomated safety check: PassAGPL-3.0
Godot Testing Patternsthedivergentai/GD-Agentic-Skills821—~2.9kAutomated safety check: PassLGPL-3.0
Game Boy ROM Playthrough Drivertrekawek/coffee-gb1.2k—~1.3kAutomated safety check: PassMIT
ScreenshotRandallLiuXin/GodotMaker5501 repos~1.5kAutomated safety check: PassCustom licence
Godot Testingjame581/GodotPrompter805—~2.4kAutomated safety check: PassMIT
Gm ScaffoldRandallLiuXin/GodotMaker550—~1.9kAutomated safety check: PassCustom licence

Similar skills

  • Godot Testing Patterns

    thedivergentai/GD-Agentic-Skills

    Expert testing decision trees for GdUnit4: unit vs scene vs CI gates, headless runners, snapshots, and mock networks.

    821 GitHub stars~2.9k tokensUpdated 1 mo ago
    Testing & QAAuto-check passed
  • Plays an authorized Game Boy or Game Boy Color ROM in one persistent headless Coffee GB session, inspecting frames and keeping an action trace for replay or tests.

    1.2k GitHub stars~1.3k tokensUpdated 10 days ago
    Game DevelopmentAuto-check passed
  • Screenshot

    RandallLiuXin/GodotMaker

    Capture gameplay screenshots using godot-e2e for visual verification.

    550 GitHub starsUsed in 1 repo~1.5k tokens
    Game DevelopmentAuto-check passed
  • Godot Testing

    jame581/GodotPrompter

    A skill your agent uses when writing tests for Godot projects — TDD workflow with GUT and gdUnit4, covers both GDScript and C

    805 GitHub stars~2.4k tokensUpdated yesterday
    Game DevelopmentAuto-check passed
  • Gm Scaffold

    RandallLiuXin/GodotMaker

    Scaffold a new Godot project: project.godot + addons + base directories + e2e/conftest.py + initial git commit.

    550 GitHub stars~1.9k tokensUpdated 23 days ago
    Game DevelopmentAuto-check passed
  • Ship Web Games

    nirholas/three.ws

    Package, deploy, and verify a playable Three.js or web game.

    229 GitHub starsUsed in 1 repo~284 tokens
    Game DevelopmentAuto-check passed

More from nhoral/KenshiCoop

  • Launches two KenshiCoop clients side by side on an ultrawide monitor, booted to the title screen, so one person can play host and join and connect manually through F2.

    285 GitHub stars~835 tokensUpdated 2 mo ago
    Auto-check passed

Questions about KenshiCoop Save Orchestration

What does KenshiCoop Save Orchestration do?

Picks the right save file and script for a KenshiCoop debugging or validation session, and protects version-controlled fixtures from being overwritten. Explains how Kenshi saves auto-load from one shared per-user AppData folder that both the host's Steam install and the Kenshi-Join install read, triggered by an environment variable the orchestration scripts set automatically. Because NPC and squad sync requires both clients on the identical save, two players sharing one world use one save with partitioned ownership rather than two separate saves that would desync.

When should I use KenshiCoop Save Orchestration?

KenshiCoop Save Orchestration fits situations like: choosing which Kenshi save to load for a hands-on debugging session; validating one co-op scenario or running the full regression matrix; baking a new fixture save from a setup scene; capturing an updated save from AppData back into the tracked repository.

How do I install KenshiCoop Save Orchestration in Claude Code?

Run `npx skills add nhoral/KenshiCoop --skill coop-save-orchestration -a claude-code`. Or copy the skill folder (.cursor/skills/coop-save-orchestration in nhoral/KenshiCoop) into .claude/skills/coop-save-orchestration in your project. Claude Code loads it when a task matches its description.

How do I install KenshiCoop Save Orchestration in Codex?

Run `npx skills add nhoral/KenshiCoop --skill coop-save-orchestration -a codex`. Or copy the skill folder (.cursor/skills/coop-save-orchestration in nhoral/KenshiCoop) into .agents/skills/coop-save-orchestration in your project. Codex loads it when a task matches its description.

Can I use KenshiCoop Save Orchestration 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 nhoral/KenshiCoop --skill coop-save-orchestration -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/coop-save-orchestration, .gemini/skills/coop-save-orchestration, .github/skills/coop-save-orchestration and .opencode/skills/coop-save-orchestration in your project.

What does KenshiCoop Save Orchestration need to run?

SKILL.md names no scripts, command-line tools or credentials: KenshiCoop Save Orchestration is instructions for the agent only. Our summary lists: PowerShell; Kenshi with the KenshiCoop plugin and Kenshi-Join installed.

Does KenshiCoop Save Orchestration access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is KenshiCoop Save Orchestration 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 KenshiCoop Save Orchestration use?

KenshiCoop Save Orchestration is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does KenshiCoop Save Orchestration use?

About 2.4k tokens (SKILL.md is roughly 9.7k 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 KenshiCoop Save Orchestration?

Skills that share tags, products or a category with KenshiCoop Save Orchestration: Godot Testing Patterns (thedivergentai/GD-Agentic-Skills, 821 stars), Game Boy ROM Playthrough Driver (trekawek/coffee-gb, 1.2k stars), Screenshot (RandallLiuXin/GodotMaker, 550 stars) and Godot Testing (jame581/GodotPrompter, 805 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains KenshiCoop Save Orchestration?

nhoral (a GitHub user) maintains it in nhoral/KenshiCoop, which has 285 GitHub stars. The repository holds 2 skills in this directory. The repository was last updated on August 10, 2026.

Source: nhoral/KenshiCoop on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.