Fergus Bentley

> Other files represent it as an array of lines. Should we adopt that convention here as well? No. Actually, Rules seems to be a better example than other `desc`...

> My preference would be to converge behind a single Markdown string for all fields including `desc` project-wide, for all that the readability at a JSON level suffers as a...

A better solution imo would be to expand on the "Bonus Proficiency" feature, rather than the subclass itself. According to the SRD, the feature is what grants the proficiency, not...

> hmm, so proficiency property on feature object? This way, the data comes from feature, bot (sic) the subclass. Yes, exactly this! It would be better representative of the SRD...

I think your first thought was a good one. It's useful for users building VTTs, simulators, etc. to know the range of a weapon, whether or not the weapon is...

Forgive me, I was using "range" as a synonym for "reach" here. Just casual English, not rigid rules-based semantics. To answer the points listed, (1) yes I believe there should...

> I think, to the strict language of rules, these would be: > 1. melee weapon with reach > 2. melee thrown weapon with reach and range > 3. ranged...

> would this be the type shape that we'd want now that monsters have been split into their forms? @bagelbits Yeah, this looks good!

I don't like the idea that the consumer has to look at the equipment categories and properties to figure out what the weapon's range is. I understand that RAW, melee...

After some investigation, it looks like the issue isn't to do with the fact that the curly braces are escaped. In fact, if you load `openapi.yml` into something like `https://editor.swagger.io/`,...