spire-agent Plays Slay the Spire

spire-agent is AttemorySystem’s open-source Python project that runs an autonomous agent for Slay the Spire. It deals with a problem that shows up in games and ai coding alike: long-horizon decisions fall apart when the model has to remember, reason, and operate the interface all at once. The takeaway is simple: make deterministic tools do the boring exact work, then leave the language model to handle the few choices that still need judgment. For engineers asking about ai coding solutions roi for large teams, this is the useful lesson hiding inside a game bot: the value often comes from narrowing the agent’s job, not making it more magical.

The interesting part is the split

spire-agent is not just “an LLM plays a game.” It is a small agent framework wrapped around domain-specific tools for Slay the Spire, the deck-building roguelike by Mega Crit.

The project’s README describes a deterministic-first design. The harness handles interaction in a stable way. Pluggable tools carry complex game logic. The LLM acts as the glue when a choice needs open-ended reasoning, like weighing a card reward against the shape of the current deck.

That split matters because Slay the Spire punishes shallow autonomy. A run can span more than 50 floors, with hundreds of linked choices: route selection, card picks, relic synergies, potion timing, combat sequencing, and whether the deck can survive the Heart.

The trap is treating every step as a prompt. If a model has to inspect the screen, infer game state, remember deck strategy, calculate deterministic effects, and click the right button, it will eventually lose the thread. spire-agent’s more interesting move is to remove as many chances to drift as possible.

As of September 2026, the repository is small — 8 GitHub stars, MIT licensed, mainly Python, and last pushed on 2026-09-03. The reported results are still notable for a hobby-scale project: Ironclad has several Ascension 20 Heart wins, and the README says a 12-run sample averaged floor 38.6, with six runs reaching Act 3 and two reaching Act 4. Defect has reached Act 4 multiple times.

The run log is the product

The best detail in spire-agent is that every run is recorded and replayable. That turns an agent failure into test evidence instead of a vague memory of “the model made a weird choice.”

A replayable run lets the maintainer ask better questions. Did the agent misunderstand the game state? Did the deterministic tool rank the options badly? Did the LLM make a reasonable tradeoff that failed later? Those are different bugs.

This is the same reason serious ai software development work keeps moving toward evidence, not chat transcripts. A transcript is useful context. A replay, fixture, diff, benchmark, or failing test is something you can improve against.

The trap is celebrating one lucky win. Games with randomness are especially good at hiding weak policies. A single A20H clear is fun, but the more valuable artifact is the run history that lets the policy get less wrong over time.

That is also why this project connects cleanly to coding agents. A coding agent that “usually fixes the bug” is hard to trust. A coding agent that leaves a reproducible patch, tests, command output, and a reasoned handoff is much easier to review.

Why developers cared

The Hacker News interest was not only about Slay the Spire. It was about a familiar disappointment: general coding agents can be impressive in code, then look clumsy in another domain with different state, rules, and feedback loops.

The author’s framing is blunt: coding agents have matured faster than domain-specific agents. Using a general agent such as OpenAI’s Codex to play games can work poorly because the environment asks for stable interaction, long memory, and exact domain mechanics rather than code edits.

That objection cuts both ways. Some readers will look at spire-agent and ask whether it is “really” an AI agent if so much logic lives in tools. I think that is the wrong disappointment. The point of an agent is not to maximize model involvement. The point is to complete the task reliably.

A useful agent is a system with a boundary. On one side: deterministic state, calculations, commands, fixtures, and replay. On the other: judgment, prioritization, and ambiguous tradeoffs. spire-agent is interesting because it draws that line visibly.

You can see the same pattern in testing tools for coding agents. For example, Supercov Brings MC/DC Coverage to Coding Agents is a different story, but the rhyme is obvious: make the agent produce evidence that survives outside the chat.

Borrow the boundary in Claude Code

Claude Code, Anthropic’s coding agent, already works inside real repositories where tools, commands, and review habits matter. The spire-agent lesson is to make the agent’s boundary explicit before the task gets long.

Here is a small Claude Code workflow inspired by the project, without pretending your repo is a card game.

Create one slash command for long-running fixes, such as /investigate-flaky-test. The command should tell the agent to gather deterministic evidence first: failing test command, seed if available, affected files, recent commits, logs, and one minimal reproduction. Only after that should it propose a fix.

A good command workflow looks like this:

• Run the smallest failing command before editing.
• Save the exact command and output in the handoff.
• Change one hypothesis at a time.
• Re-run the same command after the patch.
• Leave a short receipt: what failed, what changed, what now passes, and what remains uncertain.

That is not glamorous, but it is where ai pair programming becomes easier to trust. The model still reasons, but the repo supplies the rails.

For the broader related training topic, this is also the cleanest way to reason about ai coding solutions roi for large teams: ask which agent decisions can be replaced by deterministic checks, fixtures, or commands. The return is rarely “the model writes more code.” It is usually “the model wastes less reviewer attention.”

The trap is putting every rule into a giant memory file. A concise CLAUDE.md can carry durable repo facts, but task mechanics belong closer to the workflow: slash commands, scripts, tests, and small checklists that produce evidence.

A fit / not-fit table for trying spire-agent

Use this table if you are deciding whether to study spire-agent, borrow its design, or run it yourself.

The most transferable habit is the last row. Do not start by asking the agent to be smarter. Start by making one failure replayable.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about ai coding?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That is the practical core of ai software development. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “spire-agent Plays Slay the Spire.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• spire-agent — source
• Claude — Agent
• OWASP — Top 10 for Large Language Model Applications
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.