DSH HUB
HomePlugin StorePlugin PacksCommunityRankingsResourcesPublish Guide
Plugin source
Back to catalog

HYClub /

HYClub/deepseek-harness-game-studios

Verified

DeepSeek Harness port of Claude Code Game Studios (CCGS v1.1.2, MIT) — 83 skills, 49 agents, 14 rules, 19 hooks, studio status line, self-installing payload, and a playable one-shot pipeline.

★ 26 Stars0 Forks0 IssuesN/A Community rating0 Confirmed installs
View on GitHub
READMESource: main@7b77d28f

DeepSeek Harness Game Studios

License Version Agents Skills Hooks Rules Port of CCGS

English 简体中文

Install · What you get · A round of play · Status · Verification · License

Turn a single DeepSeek Harness session into a full game development studio. 49 agents. 83 skills. One coordinated AI team.

You describe the game; the studio asks the questions a real one would, writes the documents a real one writes, keeps the project's memory between sessions, and plays the result in a browser to see what broke. It is a port of Claude Code Game Studios (CCGS) — the skills, agents, rules and documentation come from upstream (MIT); this repository provides the DeepSeek Harness runtime: Node hooks, skill generation, machine-level install, and the plugin bridge.

Provenance

Upstream project Donchitos/Claude-Code-Game-Studios
Upstream version this port tracks v1.1.2 (commit b21fa0f, 2026-09-29)
Upstream license MIT (Copyright © 2026 Donchitos) — reused here
This repository deepseek-harness-game-studios (DSGS) v0.3.6
Port strategy Dual stack, one source: .claude/ is the content source (upstream text, kept verbatim); .dsh/** is generated by tools/build-dsh.mjs

Upstream targets Claude Code (.claude/, .sh hooks, bash one-liners, @path imports). None of that runs under DSH (no bash tool, piped child processes are denied by the sandbox, @path is not expanded), so DSGS generates a DSH-runnable equivalent instead of editing upstream content, and proves no content loss.

The plugin package bundles the framework under payload/ — you never need to look at it while using the plugin.

Install

① Web client

Plugins → Add plugin → paste https://github.com/HYClub/deepseek-harness-game-studios → Install → restart dsh web.

dsh plugin --profile web add https://github.com/HYClub/deepseek-harness-game-studios

② Desktop client

Open the desktop app, then Plugins → Add plugin → paste the same URL → Install → restart the app.

On first load the plugin installs the framework at machine level (~/.dsh/dsgs plus user-level bootstrap skills). After that:

new working directory → new session → type /start

/start checks whether the workspace is initialised; if not it initialises it first, then walks you through onboarding.

What you get

The numbers below are printed by the framework's own checks — run them yourself in any workspace: node tools/check-dsh.mjs and node tools/verify-fidelity.mjs.

83 skills every one of upstream's 78, plus 5 that only exist here (/statusline, /today, /dashboard, /update, /dsgs-install). Each is a slash command.
49 agents the studio's roles — design, art, audio, narrative, engineering, QA, release, live-ops — as role cards with delegation conventions.
14 rules coding and content standards, path-scoped upstream; here a hook injects the matching rule text after every write.
19 hooks every upstream hook (18 scripts) has a Node implementation, and all of them are registered: 0 pending. Reads, writes, the two registries, commits and pushes are checked.
Engines Godot 4.7, Unity, Unreal and Web reference docs (53 files) — the version a project pins is what every engine-specific skill reads.
Tooling config resolution, project state, the status line, the board, the update check, and the whole one-shot pipeline.

One command per job

You say It does
/start initialise this folder as a studio project, then onboard you
/brainstorm /map-systems /design-system turn an idea into a map of systems and section-by-section design docs
/create-architecture /create-epics /create-stories architecture, epics, and stories a programmer can pick up
/team-combat /team-level /team-narrative … run a whole department against one feature
/playtest-report /balance-check /qa-plan turn feedback and data into decisions
/cut propose what to cut so the game finishes — each cut is yours to pick — plus a polish list and dates
/today /statusline /dashboard what to do now, as a line, and as an offline board
/update compare the installed plugin with the newest release and update after you agree

A round of play

The one-shot pipeline is the shortest path from "an idea" to "a game someone can play", and it is the part most worth watching work:

/prototype          → one-shot-new    prototypes/<name>/ : page, config, provenance, brief
                      [/run]          → one-shot-run     headless Chrome plays it from a fresh start
                                                          and stops where it should, with a screenshot
/check              → one-shot-check  keep pins vs config, brief checklist, evidence, a check record
/tune               → one-shot-tune   a tuned number goes back into config.js with a feel-log line
/share              → one-shot-share  dist/ without the debug panel, and it fails if any file still names it
/grow               → one-shot-grow   guard → copy → replay: a Web project at the root, compared
                                      frame by frame with the original

A grow session, from installing the toolchain to the final comparison, looks like this:

npm ci                     → added 47 packages
npm run build:single       → dist-single/index.html 4.14 kB
replay --as reference      → errors 0 · exact yes
replay --as copy           → errors 0 · match yes
replay --as story          → against reference · match yes
accept                     → accepted.tsv + accepted.png

page-shot finds Chrome, Edge, Chromium or Playwright's headless shell, gives it a profile of its own, talks to it over the DevTools protocol with the WebSocket built into Node (nothing to install), and writes the screenshot. When no browser exists it says so and exits 3 — it never invents a pass.

Upgrade

Run /update inside an initialised workspace (0.2.1 and later):

/update

It reads the installed version and the newest release, shows the commands it will run, and runs them only after you agree. Restart the client afterwards — the new skills appear in a new session.

Is this workspace initialised? Yes when .dsh/skills/start/SKILL.md or .dsgs-installed.json exists in the project root. If neither is there, open the project in DSH, start a new session and type /start: that initialises it once, and every later session in the same project can use /update.

Coming from 0.2.0 or earlier? /update only exists from 0.2.1 on, so the first update is manual:

dsh plugin --profile web remove deepseek-harness-game-studios
dsh plugin --profile web add https://github.com/HYClub/deepseek-harness-game-studios

Desktop app users do the same through Plugins (see below). Every update after that is one /update.

Desktop app — the app owns its plugin profile, so the command line cannot change it. Open Plugins, uninstall deepseek-harness-game-studios, choose Add plugin, paste https://github.com/HYClub/deepseek-harness-game-studios, install, then restart the app. /update still reports the version and tells you when this is needed.

What the plugin writes to your machine (and how to undo it)

Path What
~/.dsh/dsgs/** framework payload (skills, agents, rules, hooks, scripts, engines, docs, instruction files)
~/.dsh/skills/dsgs-init/SKILL.md, ~/.dsh/skills/start/SKILL.md user-level bootstrap skills

It never touches a project directory and never overwrites project files. To undo:

Remove-Item -Recurse -Force "$env:USERPROFILE\.dsh\dsgs"
Remove-Item -Recurse -Force "$env:USERPROFILE\.dsh\skills\dsgs-init","$env:USERPROFILE\.dsh\skills\start"
# then uninstall the plugin and restart dsh web

Implementation status

✅ Implemented (all measured)

Item Status Notes
Skills ✅ all 78 upstream skills ported (plus 5 DSGS-only), each invocable as /name
Agent role cards ✅ 49, as .dsh/agents/<name>.md + delegation conventions
Rules ✅ 14, including an equivalent for upstream's path-scoped rule engine: a PostToolUse hook injects the matching rule text after each write/edit
Hooks ✅ 18 upstream hook scripts → 19 Node implementations, 0 pending; reads, writes, both registries, commits and pushes are checked
Hooks actually run ✅ with the official bridge package installed (npm install at the repository root): mount 10/10 · protocol 12/12; the live-event probe runs when the session can reach a model and reports SKIP otherwise — the framework itself never needs an API key
Config resolution ✅ project.yaml single source; Node ports of resolve_config / __call resolve_setting, plus config-set for writes with the enum, whitelist and dry-run checks
Helper scripts ✅ every upstream .sh has a Node port (.dsh/scripts/*.mjs) that runs inside the sandbox, including page-shot, write-guard, registry, cut-read/cut-apply, web-scaffold and the whole one-shot family
Content fidelity ✅ 377 files / 53,459 lines: 96.2% verbatim, 3.0% documented rewrites, 0.4% structural, 0.4% fuzzy, 0 unexplained loss
Machine-level install ✅ the plugin ships the payload (1471 files) and installs it on first load; /start then initialises an empty workspace from it
/statusline ✅ studio status line stage · posture · epic > story · Sprint n/m · engine (+13 unit tests)
Nested delegation ✅ subagent.maxDepth: 2 — parent → child → grandchild verified (DSH default is 1)
Shared rules reach a project ✅ the @path imports in CLAUDE.md are written out as "read this file" instructions, because this runtime does not expand them — without that, the standards documents were referenced but never read
Role tool boundaries ✅ every agent role card states the tools its role should stay within, in this runtime's tool names. Advisory: the runtime cannot enforce a per-agent tool set
One-package install ✅ one package = hook bridge + status line projection + payload self-install
/today ✅ three to five lines: the next story, what is blocked, the command to run
/dashboard ✅ one offline HTML board — overview · gaps · expected paths · roster · charts · commands — with three charts for 7 / 30 / 90 days and all time; the left navigation works without JavaScript, light and dark themes follow the system or a remembered choice, and printing stays readable
/update ✅ compares the installed plugin with the newest release and runs the two commands only after you confirm; a session-start line also says when a newer release is out
Script parity ✅ every ported script is compared with the bash original, byte for byte: all 7 pairs match with no skips
Playable checks ✅ a real headless Chrome runs a one-shot, records its scenes/state/timings, screenshots where it stops, and compares two runs row by row — the round trip from folder to grown project is covered by the test suite
DSGS-only skills ✅ statusline, dsgs-install, today, dashboard, update (not in upstream)

⚠️ Partly equivalent — works, with a stated limit

Item What works What does not, and why
3 hook events mapping implemented and unit-tested Notification, PreCompact, PostCompact have no DSH event source, so they are verified at mount level only (live coverage 6/9)
Per-agent tool allowlists every role card states the boundary in its body (工具边界 …:read, glob, grep, …), so a delegating model reads it DSH's subagent accepts no per-agent tool set and there is no agent registry, so the runtime cannot enforce it

| Scripted play without a browser | every non-browser row is produced (keep pins, checklist, evidence, emoji, brief words) | the play itself needs Chrome, Edge, Chromium or Playwright's headless shell; without one the rows say not_assessed and the command exits 3 |

❌ No equivalent — reason and substitute

Item Why Substitute
Docked status bar above the composer DSH's client roster only lists @deepseek-ai/* packages (measured: 60+ entries, ours absent even with a dsh.client declaration) /statusline skill + node .dsh/statusline.mjs; the runtime half (turns/tokens/cache/context %) is already covered by DSH's own status bar
Pre-action reminders on PreToolUse tools/pre-execute only carries allow/deny/cancel/ask; additionalContexts is read from the final tool result; agent.inject() mid-execution has no effect validate-commit / validate-push are also registered on PostToolUse (reminder arrives after the action); set the plugin row advisory: deny to block before the action
!cmd`` pre-execution lines DSH has no pre-execution rewritten as a "prerequisite command" block the model runs itself

Project Structure

.claude/                     # Upstream content source (MIT, kept verbatim)
  settings.json              # Hooks, permissions, safety rules
  agents/                    # 49 agent definitions
  skills/                    # 78 skills (one directory per skill)
  hooks/                     # 18 scripts — 17 event hooks + yaml-helper.sh
  rules/                     # 14 path-scoped coding standards
  engines/                   # engine table, the Web scaffold and its three starters
  docs/                      # workflow catalog, templates, guidance
.dsh/                        # Generated by tools/build-dsh.mjs — do not edit by hand
  agents/  skills/  rules/  hooks/  scripts/  docs/  engines/
tools/                       # Generator, verifiers, Node ports, plugin, installers
dsh-src/                     # Hand-written DSH-only overlay (merged into .dsh/)
DSGS Skill Testing Framework/  # QA for the skills and agents themselves
design/ src/ assets/ tests/ prototypes/ production/   # Your project

Testing your own customizations

DSGS is a template you are meant to edit. DSGS Skill Testing Framework/ is how you check that an edited or newly written skill still holds up — a catalog of all skills and agents, per-category quality rubrics, behavioral specs, and templates for writing specs of your own.

/skill-test static [name]     # structural linter
/skill-test category [name]   # category-specific quality rubric
/skill-test spec [name]       # behavioral spec assertions
/skill-test audit             # coverage report across skills and agents
/skill-improve [name]         # test-fix-retest loop; keeps or reverts on score change

It tests the framework, never your game — game tests live in tests/.

Verification

pwsh -File tools/verify-port.ps1        # 7 steps: generate → structure → refs → fidelity → hooks → mount → suites
node tools/check-dsh.mjs                # skills=83 agents=49 rules=14 hooks=19 errors=0 warnings=0
node tools/verify-fidelity.mjs          # unexplained 0 / no content loss (377 files, 53,459 lines)
node tools/verify-hooks-mount.mjs       # 10/10 mount cases (after npm install)
node tools/verify-hooks-bridge.mjs      # 12/12
node tools/verify-hooks-events.mjs      # live probe: 6/8 events when a model session is available, else SKIP
node tools/tests/parity/bash-vs-node.test.mjs  # 7/7 pairs match, 0 skips

The browser path has its own proof:

node .dsh/scripts/page-shot.mjs page.html out.png --wait 900   # real screenshot + console rows
node .dsh/scripts/one-shot-grow.mjs replay <name> --as reference --stop 200

Supporting this project (and upstream)

DSGS is a port; the original work — 78 skills, 49 agents, 14 rules and all the documentation — was written by the upstream author, and their own support links live in the upstream repository. If this project saves you time, please support them first. Issues and contributions about the DSH port itself belong in this repository.

License

MIT License — see LICENSE. Upstream copyright © 2026 Donchitos; the port layer (generator, Node hooks, plugin, installers, DSGS-only skills, the one-shot tooling) is released under the same license.

—/ 5

No ratings yet

Verified DSH bundle

Commit 7b77d28f79d6

Community comments

No comments yet. Be the first to write one.

DSH HUB

A community index for DSH plugins. Not an official GitHub or DeepSeek AI product.

CommunityResourcesAPIAbout