About the project
A careful reference for a moving game.
Spire Ledger is an independent English-language reference project for Slay the Spire 2. It is built for players who need a current answer about a route, a rule, a catalog entry, or a version change.
The editorial boundary is simple: a page should show what it knows, where its certainty ends, and what a player can do with the information. Branch-specific, historical, and unresolved details stay labeled instead of being blended into one confident paragraph.
The project is not affiliated with Mega Crit. Slay the Spire 2 and its game assets belong to their respective rights holders. The visual material in this early build is official Steam game artwork used to identify the game and frame the reference pages.
Pages are reviewed when the game changes or when a catalog discrepancy affects the answer. Every article carries a visible update date.
How this guide is made
Four rules, applied to every page.
- Store fields first. Every factual claim traces to a field this project recorded from the public Steam listing for appid 2868840 (the store details and review endpoints) or to a developer-published patch note, with the read date written beside the value. Where a field is absent, the page reports the absence instead of papering over it.
- Version-anchored rather than version-blind. Slay the Spire 2 is in Early Access, and its balance has flipped inside single months; the July 31, 2026 beta undid earlier card reworks. So every claim is anchored to a build, the site-wide boundary is the newest dated entry, Beta v0.111.0 (August 14, 2026), and anything past that label is marked unverified.
- A blank field beats a plausible guess. No public achievement list, no console entry in the platform object, no party-size number; pages show what was checked and what it returned, and leave the gap visible rather than filling it with an invented value.
- Revisions are public. Every guide revision is dated and logged on the updates page, so the age of any answer can be checked before it is trusted, and reader corrections land within days through the contact page.
Why the project insists on checkable data
The rule exists because of how Early Access actually behaves. Balance has flipped inside single months, and the July 31, 2026 beta undid card reworks that guides had already treated as settled. In that environment, a claim without a build label and a read date cannot be repaired when it goes wrong: nobody can tell whether the game changed, the record changed, or the writer guessed. A traced claim ages visibly, which means it can be re-checked and corrected instead of quietly rotting.
The second reason is about what a blank field costs. A reader who finds a labeled gap loses a little time and nothing else. A reader who trusts an invented number loses a run, and then loses trust in every other number on the page. Reporting that a value was checked and returned nothing is slower to write and cheaper to trust, and the project considers that trade worth making on every page, not just the ones about catalog gaps.
The four rules above are the working form of this position. They make publishing slower: fewer numbers appear, some answers stay bounded instead of sweeping, and pages repeat their own limits. What they buy is a reference where every figure traces to a dated check, and every correction has a log entry. For a game that moves this fast, the project judges that trade to be the only sustainable one.
Last updated: September 7, 2026