sts2-run-operator

What This Skill Does

This skill standardizes how to operate this repository as a long-running Slay the Spire 2 agent workspace.

It is for sessions where the goal is not just to inspect the game once, but to keep building a reliable run loop with durable memory.

When To Use It

Use this skill when you need to:

1. connect to the local STS2MCP API;
2. inspect the current game state;
3. issue a single documented game action;
4. save state snapshots or action responses into the active run folder;
5. update persistent lessons and known issues after discoveries or failures.

Source Of Truth

Read these files first:

1. README.md
2. docs/architecture.md
3. docs/operations.md
4. memory/lessons.md
5. memory/issues.md
6. prompts/developer_agent.md
7. prompts/player_agent.md

Implementation entrypoints:

1. src/sts2_agent/main.py
2. src/sts2_agent/api.py
3. src/sts2_agent/journal.py

Working Rules

1. Prefer the smallest correct next step.
2. Do not assume undocumented endpoints or payloads when the live API can be queried.
3. Save evidence of failures instead of paraphrasing them from memory.
4. After every meaningful discovery, update either memory/lessons.md or memory/issues.md.
5. Treat menu automation and in-run automation as separate problems unless the live API proves otherwise.
6. Respect the role split: developer agent handles lifecycle; player agent handles active gameplay.

Standard Workflow

1. Ensure A Run Record Exists

Create a run record if there is no active run folder for the current session:

python -m src.sts2_agent.main init-run

2. Probe The API

Use this first when the game may not be running or when the API shape needs confirmation:

python -m src.sts2_agent.main probe-api

Expected confirmed singleplayer entrypoint:

• GET /api/v1/singleplayer
• POST /api/v1/singleplayer

3. Read Live State

Use JSON for programmatic work:

python -m src.sts2_agent.main read-state --save