# GameDesignOS stops the agent one gate short of a decision

> A local Python CLI that stores design work as Decision, Assumption, Evidence and Experiment files and halts at a decision accept gate. The workspace layout and the packaging are readable on the project page; the command reference is not.

**DY-2026/GameDesignOS** — Local-first game design OS for AI agents: turn sessions into evidence, experiments, reviewable decisions, and durable project memory—Human Gates and rollback.

- Repository: https://github.com/DY-2026/GameDesignOS
- Stars: 402 · Forks: 49
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/dy-2026-gamedesignos

## The demo stops one gate short of a decision

Cloning the repository and running the demo takes four commands, and none of them need an API key.

```bash
git clone https://github.com/DY-2026/GameDesignOS.git
cd GameDesignOS
python -m pip install -e .
python -m gamedesignos demo
```

What that last command produces is the whole argument in miniature. No model call happens in the run. Instead it writes a fresh `public-synthetic` Lighthouse workspace into the system temporary directory, fills the Decision, Assumption, Evidence and reviewed Experiment chain, and then stops before the `decision accept` Human Gate. The work is staged and unapproved when the process exits, which is the one behaviour here that most tools in this space do not offer.

Temporary placement also makes the first hour safe. Nothing lands in a project you care about, so there is no cleanup step, and a leftover synthetic workspace cannot contaminate real records later. The demo is a scratchpad that happens to use production file formats.

## The ask command names a skill and writes nothing

A workspace you keep needs a name and a destination, and the CLI takes both:

```bash
python -m gamedesignos start "Lighthouse Tactics" --destination ../lighthouse-designos
```

A console script named `gamedesignos` lands on the path with an editable install too, and it accepts a plain sentence instead of flags:

```bash
python -m pip install -e .
gamedesignos "I want to make a lighthouse tactics game"
```

That natural-language entry recommends a skill and writes nothing by default. Supply a destination or a workspace and it prepares the first Decision, the first Assumption, a three-minute validation Experiment, a VOI Gate and a workflow. `ask` behaves the same way, recommending the smallest suitable skill without writing unless told otherwise. Both commands keep file creation behind something you type, which is a deliberate constraint rather than a limitation of the implementation: the runtime is deterministic and local, and it treats disk writes as yours to authorise.

## Nine project directories, and a separate .gamedesignos/ for runtime state

A v1 workspace is nine directories: Inbox, Decisions, Assumptions, Evidence, Experiments, Design Assets, Workflows, Learning and Exports. Runtime state lives outside all of them, under a separate `.gamedesignos/` path, so cached or generated state never mixes with project assets. The template that creates the nine lives in `runtime/workspace-template-v1/`, which the layout treats as the durable-asset entry point.

Naming the stages is the design. Evidence sitting in the same file as a Decision would leave somebody later deciding which claim was which, and the Experiment stage exists so that something was tried before something was concluded. Inbox is the only name in the list that is not a lifecycle stage, so unsorted captures land there first.

Contracts hold those stages to a shape. The repository carries 19 contract schemas covering decisions, assumptions, evidence, experiments, UL state, learning, gates, workflows, issues, player promises, AI work orders and project assets. Validation runs on two dependencies, PyYAML and jsonschema, both pinned in pyproject.toml, so a malformed record fails at the schema rather than three sessions later when someone reads it.

## setup.py copies three trees into the wheel

The packaging shows the difference between a checkout and an installed runtime. `setup.py` subclasses setuptools' `build_py` and copies three trees into the built package: `contracts`, `runtime/workspace-template` and `runtime/workspace-template-v1`, each landing under `gamedesignos/_data/`. The hook's own comment says the repository copies remain the only editable sources and the wheel receives a generated snapshot, so an installed runtime does not need a source checkout beside it.

Nothing exotic in the metadata. The distribution name is `gamedesignos`, the version is read from `gamedesignos._version.VERSION` instead of being hardcoded, and Python 3.11 is the floor with classifiers for 3.11, 3.12 and 3.13. The console entry point is `gamedesignos = "gamedesignos.cli:main"`, package discovery is limited to `gamedesignos*`, and package data is declared as `gamedesignos = ["_data/**/*"]`, which is how the copied contracts travel. Style tooling is one line: ruff with a line length of 100. Dev extras add build, coverage and skills-ref, so a contributor working from a clone pulls all three.

## Each of the seven skills owns one specialist output

Seven specialist skills sit at the top level of the repository, one directory each: `game-concept-architect`, `game-experience-analyzer`, `game-experience-density-optimizer`, `game-design-proposal-writer`, `game-design-source-curator`, `game-design-book-translator` and `paranoia-ai-system-evolver`. Each owns a narrow output, and the contract layer keeps them from writing into each other's files. They stay independently installable, so you can lift one folder out and leave the operating layer behind.

Around them sit five workflow guides (idea to validation, media to diagnosis, weekly experience-density experiment, evidence to proposal, decision to information) and four host adapters: Codex, Claude Code, a runnable preview-first OpenAI-compatible reference host, and local harness notes. The host choice is worth settling early, because the runtime never calls a model and something has to.

Two worked examples ship under `examples/`, a `golden-lighthouse` case and a `hosts` directory, and the project counts two public proof cases built around evidence-linked game analysis and experience density, each with explicit source boundaries.

## Nothing becomes a decision without passing the gate

The pipeline the project draws is short enough to memorise: an idea, a gameplay sample, a research trail or a workflow problem becomes evidence, then an experiment, then a decision, then learning, with a Human Gate and rollback sitting above the whole chain.

```text
idea / gameplay / research / workflow
                  ↓
evidence → experiment → decision → learning
                  ↑
         Human Gate + rollback
```

v1.2.0 makes that gate explicit in workflow terms. Every workflow can preserve intent, VOI, RJR, Human Gate, rollback and candidate-learning references, and an Intent Work Order states the reality to change before any AI work starts. The most concrete artefact is a prompt you hand to the evolver skill:

```text
Use $paranoia-ai-system-evolver to audit this research or AI workflow with a Decision Object, current default action, decision boundary, EVPI/EVSI, signal-to-action map, the smallest high-VOI probe, and a stop rule.
```

A second prompt pushes the same tool toward RJR-AI, asking what AI may search or draft, what the workflow must constrain, which evals must test, what permissions block overreach and which residual judgements must stay with a person. That vocabulary is the real interface to an agent here: not a plugin API, a document the agent has to satisfy.

## v1.3.0.dev0 is a candidate while v1.2.0 is the tagged release

Two versions are in play and they are not the same thing. The tagged release is v1.2.0, `Intent Work Order & Workflow Governance`, published on 2026-07-23 and marked Latest on the releases page. The development candidate is v1.3.0.dev0, and the project page describes it in more detail than the release does: candidate wheels carry their own contracts and templates, `router.yaml` stays the only editable routing source, and UL (Uncertainty Ladder) gains a machine-readable `ul_state` schema spanning UL-L0 through UL-L5 with an optional workflow reference plus attribution and transfer regressions. Packaged behaviour fixtures cover 11 suites and 72 evals.

All seven skills still pass the Agent Skills reference validator on that candidate. The repository is not archived and its last push landed on 2026-08-17, under four weeks after the v1.2.0 tag.

Take the release when you want the runtime described by the changelog. Take the candidate when you need `ul_state`, and read the roadmap file the project points at before assuming routing behaviour is unchanged between the two.

## The README stops mid-word inside the third prompt

Here is the boundary of what can be checked from the project page. It stops mid-word inside the Intent Work Order prompt, right after `delivery failur`. Everything past that point is invisible: the Current Skills anchor the page links to, the proof cases section, and the details of `workflow-run.governance` are named but not described.

That gap covers exactly what a sceptical reader wants. What does `decision accept` write? Which files go into a review-safe pack, and what does it strip out? What does a health scan flag when a Decision has no Evidence behind it? None of it is answered on the page, and the runtime makes no model calls, so nothing local answers it for you either.

Four other files are named to fill some of those holes: `runtime/cli/README.md` as the package readme, `runtime/cli/commands.md` as the command reference, `releases/v1.2.0.md` for the release itself, and `docs/product/roadmap.md` for what comes next. Start with the command reference, since that file decides whether the CLI covers your workflow at all.

## Conclusion

Adopt GameDesignOS if your design work already scatters across chat logs, screenshots and one-off prompts, and you want every judgement on disk with a named approval step. Do not adopt it expecting a model inside the box: the runtime makes no model calls at all, and the seven skills are prompts for a host agent you already run. Verify two things first. Run the demo and confirm that stopping before the decision accept Human Gate is a boundary you actually want. Then read runtime/cli/commands.md, because the page naming that file as the command reference is cut off before it reaches the command list.

## FAQ

### What does GameDesignOS actually do?

It is a local Python CLI that creates v1 workspaces, manages Decisions, Assumptions, Evidence, Experiments, Gates, Workflows and Learning, and exports decision graphs, project health scans and review-safe packs. The runtime is deterministic and makes no model calls.

### Does GameDesignOS need an API key?

No. The demo command makes no model calls and needs no key. It writes a public-synthetic Lighthouse workspace into the system temporary directory and stops before the decision accept Human Gate.

### What is the Human Gate in GameDesignOS?

It is the point where agent output stops. The demo halts before the decision accept Human Gate, and v1.2.0 workflows can preserve intent, VOI, RJR, Human Gate, rollback and candidate-learning references so the approval boundary stays visible in the record.

### What does it take to install GameDesignOS?

Python 3.11 or newer, with PyYAML>=6.0 and jsonschema>=4.20 as the only runtime dependencies. An editable install from a checkout runs with python -m pip install -e . and adds a gamedesignos console script.

### Can GameDesignOS work with Codex or Claude Code?

The repository ships four host adapters: Codex, Claude Code, a runnable preview-first OpenAI-compatible reference host, and local harness notes. Because the CLI never calls a model itself, one of those hosts is what actually drives the skills.

## Sources

- [DY-2026/GameDesignOS on GitHub](https://github.com/DY-2026/GameDesignOS)
- [Issues](https://github.com/DY-2026/GameDesignOS/issues)
- [License: MIT](https://github.com/DY-2026/GameDesignOS/blob/main/LICENSE)
- [README](https://github.com/DY-2026/GameDesignOS/blob/main/README.md)
- [Releases](https://github.com/DY-2026/GameDesignOS/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dy-2026-gamedesignos