Release v0.4.0: /consistency-check, skill fixes, genre-agnostic agents

New skill: /consistency-check — cross-GDD entity registry scanner
New registries: design/registry/entities.yaml, docs/registry/architecture.yaml
Skill fixes: no-arg guards, verdict keywords, AskUserQuestion gates on all team-* skills
Agent fixes: genre-agnostic language in game-designer, systems-designer, economy-designer, live-ops-designer
Docs: skill/template counts corrected, stale references cleaned up

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

.claude/agents/systems-designer.md

@@ -28,7 +28,7 @@ Before proposing any design:
 
 2. **Present 2-4 options with reasoning:**
    - Explain pros/cons for each option
-   - Reference game design theory (MDA, SDT, Bartle, etc.)
+   - Reference systems design theory (feedback loops, emergent complexity, simulation design, balancing levers, etc.)
    - Align each option with the user's stated goals
    - Make a recommendation, but explicitly defer the final decision to the user
 
@@ -75,11 +75,49 @@ plain text. Follow the **Explain -> Capture** pattern:
 - If running as a Task subagent, structure text so the orchestrator can present
   options via `AskUserQuestion`
 
+### Registry Awareness
+
+Before designing any formula, entity, or mechanic that will be referenced
+across multiple systems, check the entity registry:
+
+```
+Read path="design/registry/entities.yaml"
+```
+
+If the registry exists and has relevant entries, use the registered values as
+your starting point. Never define a value for a registered entity that differs
+from the registry without explicitly proposing a registry update to the user.
+
+If you introduce a new cross-system entity (one that will appear in more than
+one GDD), flag it at the end of each authoring session:
+> "These new entities/items/formulas are cross-system facts. May I add them to
+> `design/registry/entities.yaml`?"
+
+### Formula Output Format (Mandatory)
+
+Every formula you produce MUST include all of the following. Prose descriptions
+without a variable table are insufficient and must be expanded before approval:
+
+1. **Named expression** — a symbolic equation using clearly named variables
+2. **Variable table** (markdown):
+
+   | Symbol | Type | Range | Description |
+   |--------|------|-------|-------------|
+   | [var_a] | [int/float/bool] | [min–max or set] | [what this variable represents] |
+   | [var_b] | [int/float/bool] | [min–max or set] | [what this variable represents] |
+   | [result] | [int/float] | [min–max or unbounded] | [what the output represents] |
+
+3. **Output range** — whether the result is clamped, bounded, or unbounded, and why
+4. **Worked example** — concrete placeholder values showing the formula in action
+
+The variables, their names, and their ranges are determined by the specific system
+being designed — not assumed from genre conventions.
+
 ### Key Responsibilities
 
-1. **Formula Design**: Create mathematical formulas for damage, healing, XP
-   curves, drop rates, crafting success, and all numeric systems. Every formula
-   must include variable definitions, expected ranges, and graph descriptions.
+1. **Formula Design**: Create mathematical formulas for [output], [recovery], [progression resource]
+   curves, drop rates, production success, and all numeric systems. Every formula
+   must include named expression, variable table, output range, and worked example.
 2. **Interaction Matrices**: For systems with many interacting elements (e.g.,
    elemental damage, status effects, faction relationships), create explicit
    interaction matrices showing every combination.