# Claude Code Build Prompt — Corporate Ladder Game MVP

Copy everything below the line into Claude Code as your starting prompt.

---

I want to build a browser-based career simulation game called (working title)
"Corporate Ladder." This is a **minimum viable prototype** — please treat this
as the first phase of a larger project, and follow a research/plan-first
approach before writing code: propose a file/folder structure and data schema
first, surface any open questions, and get my explicit go-ahead before you
start implementing.

## Core Concept

A turn-based career sim. The player starts in the mailroom of a modern
corporate office. Each turn (treat a turn as one day), the player is shown a
short scripted scenario and picks from 2–3 choices. Choices affect the
player's money, a skill stat, and relationship stats with two NPCs (a boss and
a coworker rival). The game has no fixed length — the player can keep taking
turns indefinitely — and at any point can trigger a "wrap up my career"
retrospective screen summarizing what happened.

This is explicitly a **prototype/foundation**, not the full game. The most
important requirement is that everything be **data-driven**: characters,
events, and choices should live in data structures (JSON or equivalent) that
a generic engine reads and processes. Do not hardcode character-specific or
event-specific logic in the engine — the engine should not need to change to
add a new character or event, and eventually should not need to change to
support an entirely different theme/setting (e.g. Wild West instead of
corporate office). Please design the schema with that future flexibility in
mind, even though this build only needs to ship the corporate/mailroom
content.

## Tech Stack

- Fully client-side: plain HTML, CSS, and JavaScript. No required backend —
  it should be able to run by opening a static HTML file (or via a trivial
  static file server for local dev).
- Keep dependencies minimal. Avoid heavy frameworks unless you think there's
  a strong reason — I'd rather this stay simple and easy to reason about.
- No database, no accounts. State lives client-side.

## Required Features for This Build

### 1. Core Turn Loop
- Player starts a new game in the mailroom with starting values for money,
  one skill (e.g. "negotiation"), and neutral relationship stats with the two
  NPCs.
- Each turn presents a short text scenario and 2–3 choices.
- Choices apply effects to money / skill / relationship stats.
- Some choices may require a minimum skill level to be available (a simple
  gating mechanism).
- No fixed number of turns — the player can keep playing.

### 2. Two NPCs
- A boss and a coworker rival.
- Each has: name, a short flavor description (personality/appearance text,
  purely for color), a role-type tag (`boss` / `rival`), and three numeric
  relationship stats toward the player: `likes_you`, `fears_you`,
  `wants_to_help_you`.
- Design the character schema so additional role types (e.g. `mentor`,
  `peer`) could be added later without changing engine code.

### 3. Random Events
- Implement a small handful (4–6) of simple random events using the *same*
  data structure as regular scripted turns — i.e. an event is just another
  entry in the event/turn data with a tag marking it as a random event and
  some trigger condition (e.g. a probability or a stat threshold). Do not
  special-case these in the engine logic.

### 4. Soft Failure State
- If money drops below zero (or some defined threshold), don't end the game.
  Instead, surface a distinct "hard times" branch of choices — e.g. take out
  a loan (debt that must be paid down over time) or do a demeaning favor for
  the rival (which affects relationship stats and possibly unlocks money).
  The player should be able to work their way back out.

### 5. Retrospective / Ending Screen
- A "wrap up my career" action the player can take at any time.
- Shows: final money, final relationship stats with each NPC, and a short
  list of notable moments/events from their playthrough (pull from a simple
  history log kept during play).
- This screen's structure should be the same regardless of how the
  playthrough went — it's a summary, not a win/lose screen.

### 6. Save System
- Auto-save to browser local storage as the player progresses.
- An explicit "Export Save" button that downloads the current game state as a
  JSON file, and an "Import Save" option to load one back in.

### 7. Feedback & Logging System
- On every turn screen, include a small, always-visible (for now) feedback
  widget: thumbs up / thumbs down / neutral buttons, plus an optional
  free-text comment box. The player is never required to interact with it.
- Also include an optional field where the player can note "something I
  wanted to do that wasn't an option here."
- Log every turn's chosen action and its effects, along with any feedback
  given, to a **separate log** that is exportable independently from the game
  save (a separate "Export Feedback Log" button/JSON file). This should not
  be mixed into the save-game file.

## Data Schema (Starting Point — feel free to refine, but keep me in the
loop on changes)

```
Character:
  id: string
  name: string
  role_type: string        // e.g. "boss", "rival"
  description: string      // flavor text
  likes_you: number
  fears_you: number
  wants_to_help_you: number

TurnEvent:
  id: string
  stage_tag: string         // e.g. "mailroom" (for future level filtering)
  is_random_event: boolean
  description: string
  options: [
    {
      label: string
      effects: { money?: number, skills?: { [name]: number },
                 relationships?: { [character_id]: { likes_you?: number,
                 fears_you?: number, wants_to_help_you?: number } } }
      requires?: { skill: string, min: number }
    }
  ]

PlayerState:
  money: number
  skills: { [name]: number }
  relationships: { [character_id]: { likes_you, fears_you,
    wants_to_help_you } }
  history: [ { turn_id, event_id, choice_label, timestamp } ]

FeedbackLogEntry:
  turn_id: string
  action_taken: string
  rating: "up" | "down" | "neutral" | null
  comment?: string
  desired_but_unavailable_action?: string
```

## What NOT to Build Yet

- No promotion mechanic or second tier/level — mailroom only for this build.
- No AI/LLM integration of any kind yet — this build is fully scripted.
- No AI-generated images or video.
- No multiple themes/settings — corporate/mailroom only, but keep the schema
  theme-agnostic in spirit (i.e. don't bake "mailroom" assumptions into the
  engine logic itself, keep it in the data).
- No multiplayer — this is a permanent design decision, not just an MVP gap.
- No account system or server-side persistence.

## Process

Please:
1. Propose a project structure and confirm the data schema with me before
   writing implementation code.
2. Flag any open questions (e.g. exact starting stat values, exact effect
   magnitudes) rather than guessing silently — reasonable defaults are fine
   but call them out.
3. Build incrementally, and let's check in after the core turn loop works
   before layering on the feedback system, save/export, and random events.
4. Keep commits small and incremental rather than one giant commit at the
   end.

Let me know once you've reviewed this and have a proposed structure, or if
you have clarifying questions before we start.