# spec-system > Define and maintain mechanism rules and boundaries under spec/system/ (magic/tech/power systems, triggers, costs, limits, failure modes, counters). Use when establishing the story’s “fair tools”, or when plot solutions feel like author fiat / sudden power-ups. - Author: qwl - Repository: qWaitCrypto/Novelaire - Version: 20260107174605 - Stars: 0 - Forks: 0 - Last Updated: 2026-02-06 - Source: https://github.com/qWaitCrypto/Novelaire - Web: https://mule.run/skillshub/@@qWaitCrypto/Novelaire~spec-system:20260107174605 --- --- name: spec-system description: Define and maintain mechanism rules and boundaries under spec/system/ (magic/tech/power systems, triggers, costs, limits, failure modes, counters). Use when establishing the story’s “fair tools”, or when plot solutions feel like author fiat / sudden power-ups. --- # spec-system ## Use when (proactive triggers) Call this skill without being asked when you observe any of the following: - The story uses a mechanism/system (magic/tech/power/protocol/institution-as-system) that needs fairness boundaries. - Plot solutions feel like author fiat / sudden power-ups (临时开挂/硬解). - You need explicit costs/limits/failure/counters to constrain outline decisions. ## Quick start 1) Read existing `spec/system/` entries and summarize confirmed mechanics + boundaries. 2) If anything is missing/ambiguous, ask only the minimum questions (see `references/QUESTIONS.md`). 3) Draft in-chat, confirm with the user, then create/update entries via the spec workflow: - use `spec__propose` (one entry per id) and follow the template `assets/templates/system-rule.md` (structure only; do not copy its sample YAML into `body`) - apply only after explicit approval via `spec__apply` 4) Keep rules **checkable**: trigger → cost → limits → failure → counters. ## Tooling (Novelaire) - Use `spec__query` / `spec__get` to find and read existing entries before creating new ids. - Use `spec__propose` to generate a reviewable diff; apply with `spec__apply` only after approval. - Do not write canon artifacts into this skill directory; `assets/` is for templates only. ## Purpose `spec/system/` is the **fairness layer**: it defines what characters can do, what they cannot do, and what it costs. It exists to: - prevent “author solves it by inventing a new button” (临时开挂/硬解) - make tension credible via limits, trade-offs, and failure modes - keep escalation honest: new capability must be paid for (training, resources, risk, sacrifice, exposure, etc.) ## Module contract (Owns / Requires / Provides) **Owns** - Canon rules for mechanisms that solve problems (magic/tech/power/protocol): trigger/procedure, costs, hard/soft limits, failure modes, and (optional) counterplay. - Anti-loophole constraints: what the system cannot do, what it cannot bypass, and what always has consequences. **Does not own** - World baselines and institutions → `spec/world/` (system rules can imply consequences; world records them). - Character-specific capabilities → `spec/characters/` (characters reference system rules; they do not redefine them). - Object-specific constraints → `spec/objects/` (objects may interface with the system; don’t duplicate mechanics here). **Requires (upstream)** - Preferably `spec/premise/` so “fairness” matches the reader promise. - Preferably `spec/world/` so you can state plausible consequences (monitoring, scarcity, enforcement). - If `spec/narrative/` constrains reveal discipline (mystery/suspense), system entries must not force early spoilers. **Provides (downstream)** - A stable rulebook used by outline/fine-outline/chapters to judge “allowed vs cheating solutions”. - Constraints that downstream modules must obey: character abilities, object interfaces, and module fairness rules. **Conflict resolution** - If a scene “needs” a new capability, treat it as FAIL unless you first add a system rule (with cost/limit/failure) and get explicit user approval. ## Definition of done (minimum viable) At minimum, `spec/system/` should include: - One entry per *problem-solving* mechanism the story relies on (not every lore detail). - For each mechanism: trigger/procedure, costs/trade-offs, limits/caps, failure modes. - A clear “cannot / must not / cannot bypass” boundary list for anti-cheat. - If the system risks overpowering: at least one counterplay/vulnerability pattern (no infinite negation). ## What belongs here (and what doesn’t) Belongs in `spec/system/`: - mechanisms (magic/tech/power/protocol/institution-as-system) that enable solutions across many scenes - triggers/procedures, costs/trade-offs, limits/caps, failure modes - counters/vulnerabilities boundaries (when they exist) Does **not** belong in `spec/system/`: - world baseline facts and institutions → `spec/world/` - specific characters’ personal truths/resources → `spec/characters/` - plot beats / “how chapter X resolves” → outline/fine-outline ## Outputs - Spec entry files under `spec/system/` (one rule/object per file), each beginning with YAML frontmatter containing a stable `id`. - Use `assets/templates/system-rule.md` as the default structure. ## How to write system entries - Prefer explicit constraints (“If X then Y; cannot exceed Z; costs C”) over vibe language. - Make “failure” and “counterplay” explicit enough to generate tension without cheating. - Use the spec workflow tools (`spec__propose` / `spec__apply`) instead of editing spec files directly. ## Downstream use (anchors) When outline/fine-outline depends on a system mechanic (a trick, a limit, a cost, a counter), add an anchor `@spec:` pointing back to the relevant system entry. Anchors are **constraints**, not provenance. ## References - Questions to ask (minimal): `references/QUESTIONS.md` - Common pitfalls + fixes: `references/PITFALLS.md` - System Gate checklist (PASS/WARN/FAIL oriented): `references/GATE.md` ## Self-check - Can you say “this solution is allowed” or “this violates the system” from these entries alone? - Are costs/limits/failure modes strong enough to prevent omnipotence? - Did you accidentally encode plot beats or world baseline facts as “system rules”?