Brawlore

A browser action role-playing game modelled on Diablo II, written in plain JavaScript against a canvas. Random endless dungeons, nine monster types and six bosses, a skill tree that branches twice per skill, ten equipment sets of six pieces each, ten chapter quests, a grid inventory and a stash, gambling, respec, achievements and an auto-battle mode. It saves to IndexedDB and needs no build step. It is also the fullest example in this archive of a large project made without its author reading the code — what he wrote instead was a set of instruction files and three project skills that tell the agent where things live and what not to break.

Who built itBased in Ningbo, listing the company Ehafo. His profile describes reaching “the stage where I can make whatever looks fun”, and his fifty repositories bear that out: a Rust Markdown preview and editor with 271 stars, an agent-hosting platform with 33, a surviving-in-the-wilderness shooter and a Godot motorcycle combat game. Three of his repositories are games, which is unusual here — most builders in this archive arrived at a game from tooling rather than the other way round.

1. 01

   What is actually in it

   This is not a sketch of a game. The changelog runs to version 7.13, and the entry for 8 September 2026 alone contains eighteen separate changes. The feature list covers the shape of the genre properly: dungeons generated fresh on every descent, a town hub with merchants, a healer and quest non-player characters, attributes allocated on level-up, a talent shop opened on each new floor, and skill trees in four schools — fire, lightning, ranged and, added later, shields — each with three stages where the second and third offer a fork rather than an upgrade. There are ten equipment sets of six pieces, named in the style of the original, with drop rates that vary by monster class. There are thirty inventory slots, a thirty-six slot stash, a belt for quick potions, gambling, ten chapter quests running from the cave to the fortress, nine ordinary monster types and six bosses, and monster behaviours that include raising the dead, shooting arrows and passing through walls. Some of it is invented rather than borrowed — a blessing system that fires every five levels with six types, three affixes each and three effects per affix. The whole thing is one canvas and a set of scripts loaded in order by `index.html`, with no framework and no build.

2. 02

   The name it goes by, and the name it ships under

   Three different names are in play and it is worth separating them. The repository is `diablo-web`, its description says it is Diablo II written through vibe coding, and the README is headed “Diablo Web Remake”. The instruction file inside the repository, however, opens with “Brawlore”, and the deployed game at maikami.com is titled Brawlore too, with its own description text about an ARPG adventure and no mention of Blizzard anywhere. The repository is explicit about what it is paying tribute to; the thing users actually load is not. That is a reasonable line to draw and it is drawn deliberately, but it means the project has one name for the people reading the code and another for the people playing it.

3. 03

   The instruction file is the real artefact

   `AGENTS.md` is where the project’s rules live, and the first thing it does is correct a wrong assumption a reader would otherwise make: the modules are loaded in order by `index.html` and share global state, so do not assume a single-file architecture and do not reorder the loads. From there it gives a navigation table of twenty-odd files with one line each on what they are responsible for — the main loop, constants, enemy and combat tactics, auto-battle, IndexedDB saves and migrations, items and set items, skill branches, the abyss, daily quests, UI panels, audio, sprite rendering, three separate 3D effect modules, the online and market code. Then constraints, each of which reads like a bug that was fixed once and must not come back: bump the asset version in `index.html` after touching JavaScript or CSS so the browser does not serve the old file; handle missing fields when changing saved player state rather than resetting the user’s data to hide the problem; do not reintroduce the monster teleport-on-hit; keep object cleanup and quality tiers intact in effects code; expect audio to need a user gesture; keep coordinates distinguished between pixels and tile indices. `CLAUDE.md` is 164 bytes and contains one thing: an import of `AGENTS.md`, plus a note that project constraints are maintained in that file only and not copied here. One set of rules, two agents reading it.

4. 04

   Three skills, and a tool budget on each

   The repository carries three project skills, duplicated into `.claude/skills/` and `.agents/skills/` so that both agent tools find them. Each declares which tools it may use, and the budgets are the interesting part. `add-game-content` gets read, search and write — it is a recipe book, and it is specific: where in which file to add a monster, an item, a set, a skill or a quest, with a filled-in template for each, the rarity and item-type constants to use instead of magic numbers, and a note that a new set must be checked against the function that recognises equipped sets. `code-review` gets read and search only, and is a checklist aimed at canvas games rather than code in general: allocate in a pool rather than inside the loop, filter an array in place instead of calling `.filter()` every frame, compare squared distances instead of taking square roots, cache DOM references instead of querying each frame. It also carries the project’s own integrity checks, with file and line references, and a section on validating save data — including deleting `__proto__` and `constructor` off anything loaded from storage, which is the kind of thing a project this size would normally never think about.

5. 05

   The skill that just argues with you

   The third is `game-master`, and it has read and search access only — no writing at all. It is a persona panel rather than a code tool: the model is told to answer design questions as a committee of named figures from the industry, each with a stated specialism and a representative quote. Shi Yuzhu of Zhengtu fame is there for player psychology, described as focused on how to make players addicted “but with a bottom line”; Chen Tianqiao for operations and the long life of a game; a Blizzard design director in the Jay Wilson mould for combat feel and the loot loop, carrying the quotation “Shut up, PvP guy”; Ding Lei for art direction; Miyamoto for level design and delight, with the line about a delayed game eventually being good; and Miyazaki for death and learning curves. John Carmack appears in the example as the one who prices everything in lines of code, and a QA lead asks what needs measuring. The worked example is a designer asking whether floor-ten bosses are too hard, and the panel answers as a panel: the Blizzard director wants the attack interval raised rather than the health lowered so the pressure survives; Shi Yuzhu argues that being stuck is fine as long as the player feels they nearly won; Miyamoto would rather teach a new technique than lower the difficulty; Miyazaki asks whether the player knows why they died, and says the problem is feedback rather than numbers. The skill ends with four concrete recommendations and a rule against hand-waving: every suggestion has to account for what it costs to implement.

6. 06

   Some of the instructions are not in the repository

   The largest omission is deliberate and worth naming. `AGENTS.md` says the file is the single source of truth for project rules, and then immediately points outside the project: shared engineering discipline lives at a path on the author’s own machine, under an agent-flow directory, and the repository deliberately does not copy it. Verification is the same — the project defers full checking to a PowerShell script under that same machine-local directory, which runs syntax checks, a non-live regression pass and sprite asset checks, and there is a second command that runs verification and a guard pass together. One line in the instruction file refers to a canvas library being needed by some of those checks. So a reader who clones this repository gets the game, the rules about the game, and the skills — but not the pipeline that was used to check any of it, because that pipeline is not a project artefact. It is a personal one, shared across the author’s projects, and the repository is written on the assumption that it exists. There is no way to run the project’s own verification from what is published.

7. 07

   What the numbers look like

   Two hundred and thirteen commits from one author, in a repository of three hundred and thirty-seven files and two hundred and thirty-four megabytes, most of it sprite atlases shipped in both PNG and WebP. The commits are unevenly spread: seventy-eight in December 2025, eight in January, sixteen in April, eighty-six in May, three in June, and twenty-two in September 2026, with nothing at all in February, March, July or August. Twenty-three of them carry a co-author trailer, nineteen naming Claude Opus 4.5 and four naming Claude generally. The README says the work started with Gemini 3.0 Pro and later moved to Claude Code, naming Opus 4.5, Sonnet 4.5 and Kimi k2, and that no line of the code was read. The visible history begins on 6 December 2025 with a commit message reading “Clean project without large video files” rather than an initial commit, so the repository was created on 26 November and its first surviving commit removes things rather than adding them. Both pull requests and issues are nearly empty: four pull requests, all opened by the author for his own features and all closed, and one open issue, which reads, in full, “no bug to report, just wanted to say bro you’re handsome”. At one star, that is the entire inbound contribution history. The repository also carries no licence of any kind, which is worth stating plainly: the source is public, and nothing in it grants anyone permission to reuse it.