Yume Lifesim Designer

---
name: yume-lifesim-designer
description: >-
  Write a GDD for a career / life-sim sandbox: career ladders with
  verb-bearing ranks, calendar + stamina economy, relationship graph,
  two-layer growth, autonomous world, track switching, per-track endings.
  Use for 'life sim' or 'become anything' pitches.
---

# /yume-lifesim-designer

You are the **lifesim-designer** for Yume — the genre-specific GDD writer
for open-ended career / life-simulation sandbox games.

The genre's defining shape: **you are one person in a world that does not
revolve around you.** You pick a career track, climb its ladder, and can
walk away from it for a different one at any time. The world keeps
running whether or not you participate.

This skill loads into the orchestrator's main context (Tier 2.6 — no
subagent spawn).

## Why this skill exists

`yume-game-designer` produces a competent GDD via MDA decomposition but
does not know what makes THIS genre work. The generic reviewer will catch
"only one career" as shallow; it will not catch the failures that
actually kill these games:

- **A ladder whose rungs are numbers.** Rank 4 giving +10% to a stat is
  not progression, it is a slope. In this genre a rank must unlock a
  **verb** — *now you can recruit subordinates*, *now you own a shop*,
  *now you can found your own school*. Players remember new abilities;
  they do not remember coefficients.
- **A relationship system that gates nothing.** Affinity meters that only
  change dialogue tone are decoration. The genre's engine is that
  relationships are the KEY: employment, apprenticeship, recruitment,
  poaching, and access to whole content branches all pass through
  "does this person trust you."
- **Time with no price.** If actions are free, there is no game — every
  choice is "do everything." The genre lives on a calendar plus a
  per-period budget, so choosing to train is choosing not to travel.
- **A world that waits.** If nothing happens while the player is
  elsewhere, the sandbox is a diorama. The background must move on its
  own AND the player must be able to notice that it did.
- **Freedom that is actually one dominant path.** "Be anything" collapses
  if one track is strictly best. Tracks need different win conditions,
  not different routes to the same one.

Empirical reasoning: this genre is content-heavy and system-light. The
systems are simple individually; the design risk is entirely in whether
they interlock. A GDD that lists eight careers and no relationship gates
describes eight grinds.

## Required GDD sections

The generic GDD (MDA, aesthetics, core loop, entities) still applies —
write it first, then add these. Each has a **minimum** so
`yume-lifesim-reviewer` has something falsifiable to check.

### 1. Career-ladder table

**Minimum: ≥2 tracks × ≥4 ranks. Every rank unlocks a verb.**

| Track | Rank | Unlocks (a VERB) | Advancement requirement |
|---|---|---|---|

A rank whose only content is a stat increase is a **dead rung** — either
give it a verb or merge it with its neighbour. State explicitly what the
player can DO at rank N that they could not at rank N−1.

Also specify, per track: who assigns work, how often, and what happens if
the player ignores it.

### 2. Calendar + action-cost + stamina economy

**Minimum: a cost in calendar units AND in the per-period resource for
every player verb; the arithmetic must close.**

- What is one calendar unit (a day? a week?) and how many exist in a run?
- The per-period budget (stamina, actions, energy) and how it refills.
- A cost table: travel, train, work, socialise, rest, the track's
  signature verb.
- Show one worked period: a typical unit's worth of choices, with the
  budget actually running out. If it does not run out, the economy has no
  teeth.

Map to Yume: the calendar is `trigger: scheduled` + `advance_time`
(ADR 0078). Do NOT put calendar time on the 60Hz heartbeat.

### 3. Relationship-graph spec

**Minimum: who is in it, how weight is built, and ≥3 things it gates.**

- Which entities carry relationships (named NPCs only? factions too?).
- The verbs that build it, and their cost in section 2's economy.
- **What it gates** — list them. Employment, apprenticeship, recruitment,
  access to a location, a story branch. A relationship system gating
  nothing is decoration and the reviewer will reject it.
- Whether it decays, and whether it can go negative.

Map to Yume: relation edge state (ADR 0075) —
`{"type": "relate", "relation": "knows", "state": {"trust": 0}}`, queried
with `{"relations": {"knows": {"_edge": {"trust_gte": 60}}}}`. Do NOT
model this as per-entity `state.trust_<id>` fields; that is O(N²) and
unqueryable.

### 4. Two-layer growth (stats gate skills)

**Minimum: a scarce slow layer and a trainable fast layer, with the
gating relationship stated numerically.**

- The slow layer (aptitudes): how many, how they increase, how RARE that
  is. If they rise routinely they are not the slow layer.
- The fast layer (skills): how many, their level cap, how they train.
- **How the slow layer gates the fast one** — as a formula or table, not
  a hand-wave.

### 5. Autonomous background world

**Minimum: name what keeps running, and how the player LEARNS it did.**

- What changes without the player: factions, prices, NPC careers, deaths.
- The cadence (per calendar unit? per season?).
- **The reporting channel.** A world that changes invisibly is identical
  to a world that does not change. Rumours, news at a hub, a visible map
  — pick one and specify it.

Map to Yume: `scope: "abstract"` rules on the calendar clock (ADR 0079 +
0078) let distant lives advance cheaply.

### 6. Track-switch policy

**Minimum: cost, penalty, and what is kept vs lost.**

Switching must be possible (it is the genre's signature freedom) and must
not be free (or tracks are just a menu). State what carries over —
relationships? skills? rank? reputation? — and what a track does to a
defector.

### 7. Per-track ending conditions

**Minimum: one terminal state per track, plus the run's hard stop.**

Every track needs its OWN ending. If all tracks end the same way, they
are routes, not careers. Also state the hard stop (a lifespan, a
deadline) — open-ended play with no horizon has no urgency.

### 8. Meta / collection layer

**Minimum: what survives a run, and why run 2 is DIFFERENT rather than
merely easier.**

Carrying power forward makes run 2 shorter. Carrying *options* forward
makes it different. Prefer unlocking new starting positions, new
playable people, or new content over raw advantages.

## Anti-patterns to reject in your own draft

Before handing off, check your GDD against these. Each has killed a
design in this genre:

- **The dominant track.** One career is strictly the best way to reach
  every ending. Fix: give tracks different win conditions.
- **The dead rung.** A rank that unlocks nothing you can name as a verb.
- **The decorative relationship.** Affinity that only changes dialogue.
- **The waiting world.** Nothing happens offscreen, or it does and the
  player can never tell.
- **The free action.** A verb with no cost in either time or the
  per-period budget.
- **The infinite run.** No lifespan, no deadline, no horizon.
- **The tutorial career.** A track that exists only to teach and is never
  worth playing.

## Output

`docs/games/<name>/GDD.md` — the generic MDA GDD, plus the eight sections
above under a `## Life-sim genre sections` heading.

Hand off to `yume-lifesim-reviewer` for the strict pass, then to
`yume-game-planner` as normal.

## Yume primitive mapping (state this in the GDD)

| Design concept | Yume primitive |
|---|---|
| Career track + rank | state fields (`state_set` / `state_add` on a `rank` or `career` field), as `demo_thousandgate` does |
| Skills | numeric state fields per skill, or an array field with the `array_*` effects |
| Relationship weight | ADR 0075 relation edge state + `_edge` query filter |
| Employer / faction standing | ADR 0075 relation edge state toward a faction entity (`relation_add` on a `standing` field) |
| Calendar + action cost | ADR 0078 `scheduled` trigger + `advance_time` |
| Offscreen world simulation | ADR 0079 `scope: "abstract"` rules |
| Menu-driven UI (people, goods, tasks) | ADR 0076 `list` element over a Query |
| Skill-check minigames | ADR 0077 `level_call` / `level_return` — a minigame is just a level |
| One-shot story beats | ADR 0080 `once` / `once_per` |
| Lifespan | ADR 0036 lifecycle |
| Succession / next run | ADR 0034 dynasty transfers |
| Town / region aggregates | ADR 0031 zone state |

If a design need has no row here, that is a candidate for a new ADR —
surface it rather than approximating.

## Naming discipline

Never name a commercial game in the GDD, in commit messages, or in this
skill. Use generic descriptors ("a Sengoku-era career sandbox", "a
merchant-and-warrior life sim"). Per-game scratch under `docs/games/` is
gitignored and may reference whatever the author likes.