---
name: power-system
description: Define and preserve power-system rules, resources, costs, limitations, ranks, progression, techniques, counters, and exceptions, and distinguish raw power from skill, strategy, and circumstance. Use for magic, cultivation, murim, supernatural, and technological capability design and auditing.
---
# Power System v2.1

Design adaptable systems — magic, cultivation, murim, or custom — using explicit rules, resources, costs, limitations, ranks, progression, techniques, counters, exceptions, exploits, and known unknowns.

## Record

The authoritative register is `power_system/POWER_SYSTEM.md` — rules, costs, limitations, ranks, progression, techniques, matchups, counters, exceptions, known exploits, and unknown mechanics. Keep it current; a power system documented in the prose but not here cannot be audited.

## A system is rules plus costs

Every capability needs a cost, a limit, and a condition for failure. A power with no cost cannot generate tension, because nothing is at stake in using it. Record the cost as concretely as the effect: what is spent, what is damaged, what cannot be done for some time afterwards.

Limits should be operational rather than rhetorical. "It is extremely powerful" is not a limit; "it cannot be used within an hour of another working of the same kind" is.

## Scaling dimensions

Power scaling must distinguish:

- raw power
- skill and technique
- experience
- strategy and adaptation
- matchup
- environment
- injuries and accumulated cost
- temporary or borrowed effects

A lower-ranked character may win only when the context provides a credible reason from this list, and the reason must be visible in the scene. Rank is not destiny; unexplained rank victories are the most common and most damaging scaling failure.

The full dimension table, the cost-design requirements, the exploit taxonomy, and the audit checklist are in `references/SCALING_AND_EXPLOITS.md`.

## Progression

Define how advancement works, what it costs, and what it does not fix. Progression that solves every previous problem removes the reason for tension, so specify which earlier weaknesses persist.

Ranks should change capability, not simply numbers. If a higher rank only has more of the same, the progression is cosmetic.

## Exceptions

Exceptions are the point at which systems break. Record every exception as a proposal with its justification, and never introduce one mid-scene to rescue a plot problem. An unexplained exception retroactively cheapens every previous constraint.

## Rules

- Do not invent new abilities or system exceptions without recording them as proposals until accepted.
- Distinguish what the system permits from what a specific character can currently do. Permission is not capability.
- Unknown mechanics are legitimate — the world may not be fully understood — but must be marked as unknown rather than left ambiguous.

## Coordination

Use `power-exploit` to stress-test for loopholes and stacking, `battle-choreography` for spatial and tactical application, `consequence-engine` for what power use costs the world, and `canon-manager` for rule changes, which are HIGH-risk.