Abilities & Reusable Powers

Some powers are one-of-a-kind — a spell here, a single monster's quirk there. Others are recurring: the backstab many a thief relies on, the turn-undead every cleric and paladin wields, the resistance a whole folk shares. This system gives recurring powers their own home, the Abilities type, and learning to use it well is one of the cleanest bits of craft in the whole project.

Why a separate type

Look in the Abilities folder and you will see the pattern at a glance: Backstab.ability.json, Turn Undead (Cleric).ability.json, Dwarven Resistance.ability.json, Lay on Hands.ability.json. Each of these is a discrete power that more than one class or race wants to grant.

The point of splitting them out is single-sourcing. If a dozen classes each pasted in their own copy of the backstab rules, the text would drift — one class would edit it, another would not, and the same-named power would quietly disagree with itself across the compendium. Instead the power lives once, and every class that grants it points at that one entry. Edit it in one place and it updates everywhere it is used.

How it connects

Abilities are the small components that classes and races pull in through their specialAbilities fields. When you build a class or race and it grants a power that already exists, point at the existing ability rather than rewriting its text. Turn Undead (Cleric) and Turn Undead (Paladin) can be one shared power used by both classes, or two entries tuned differently — the system supports both, and your choice should follow the truth of the rules: if the paladin's version turns at a different effective level, it earns its own entry; if it is the same power, share one.

Building a good ability

A good ability entry is a self-contained contract, like a spell that never runs out:

• Name it as a power, not a flavor tag — "Backstab," "Lay on Hands," "Weapon Specialization" — so a referee can look it up by what it is called at the table.
• Specify the mechanics completely. How does it work, when may it be used, what is the cost or limit, what does the player roll? An ability with a sheet-dependent number (a damage multiplier, a saving throw, a chance in percent) must state it. The whole reason it is reusable is so no class has to explain it again — only a fully-specified power can be relied on that way.
• Let it be shared or tuned. If the power plays identically for everyone, keep it one entry. If a class bends it (the paladin turns undead at a lower effective level, the thief's backstab scales with level), decide whether that is one entry with a variable knob or several distinct entries — and make the choice legible in the entries themselves.

The design intent

Abilities are how this project avoids the two classic failure modes of compendium building. The first is copy-drift, which single-sourcing kills — one true version per power. The second is re-invention: the temptation for every class to write its own bespoke version of a common power until the same-named thing means six different things across the roster. When you set out to give a class a special ability, the first question is never "what should I write?" — it is "does a usable version already exist, and does it fit?" Reuse it when it fits; build fresh only when the new power genuinely does something the existing ones do not.

When you finish

Add the power to a test class or race the way a player will see it: does the class's specialAbilities actually pull the ability in, and does the ability's text fully answer how it works at the table? Ask whether you have duplicated a power that should be shared, or forced a share where the rules truly differ. Done well, your abilities become the project's shared vocabulary of powers — the same backstab every thief trusts, the same resistance every dwarf carries — and that consistency is exactly what makes a sprawling compendium feel like one coherent game.