Fix output spacing and ASCII map cutoff

.agents/skills/plan-ablation/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: plan-ablation
+description: Simplify a coding plan by checking what can be removed while still meeting the task's requirements. Use after planning and before implementation.
+---
+
+# Plan ablation
+
+Review the proposed plan before editing code. Ablation means mentally removing a planned part
+and checking what would fail; it does not require implementing multiple versions.
+
+Check the requested outcome and acceptance criteria before removing work. Do not simplify by
+silently dropping required behavior. State any scope assumption that materially changes the result.
+
+- For each meaningful change, ask: if we omit this, which requirement or concrete correctness
+  risk goes unmet? Remove it if there is no concrete answer.
+- Look for a simpler solution using existing code and patterns. Question new abstractions,
+  dependencies, configuration, fallback paths, and work justified only by hypothetical future use.
+- Keep changes and checks needed for the requested behavior, safety, compatibility, and
+  repository requirements. Fewer lines alone do not make a solution better.
+
+Briefly state what to remove or simplify and why, then update the plan before proceeding.
+If nothing can be removed, say why the plan is already minimal. A sentence is enough for a
+small task; do not create a separate report or add an approval step.

.agents/skills/scopeguard/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: scopeguard
+description: >-
+  Keep an implementation within its agreed scope when a scope review is requested or work expands
+  into speculative design.
+---
+
+Complete only the current task within its agreed scope.
+
+Inspect the relevant code, tests, and config needed for the requested change; do not rely on
+snippets, guesses, or unverified premises. Resolve uncertainties that affect correctness or scope.
+For substantial work, briefly state: **Outcome, Non-goals, Files, and Proof**; use plan-ablation
+without duplicating it. Use one implementation path unless parts are truly independent.
+
+Reuse existing code, helpers, patterns, and tests. Fix root causes; preserve unrelated behavior; avoid speculative/future design; add abstractions, adapters, or config only for a second real caller or explicit requirement. Remove replaced code and retain old paths only for required compatibility.
+
+Read-only discovery is allowed. Continue with local edits and tests already authorized by the task,
+including requested API or schema changes. Ask before expanding into unrelated dependencies,
+frameworks, services, test infrastructure, or duplicate implementations, or before a consequential
+scope decision or action not already authorized. Obtain explicit authorization before destructive
+data operations, production mutation, discarding user work, rewriting history, or dropping data.
+
+Run the narrowest relevant existing tests and extend existing tests before creating new files. Add tests only for requested or uncovered changed user-observable behavior, with each test protecting a clear acceptance criterion or regression risk. Do not add unrelated coverage or use passing tests to justify extra scope.
+
+If the work grows into future-use layers, workaround stacks, unrelated cleanup, or unstated tests,
+remove unnecessary work and keep the requested behavior. Ask only for consequential scope expansion.
+
+Done means the requested behavior and acceptance criteria pass; exact commands/results are reported;
+every touched file is necessary; the diff contains nothing unrelated; no task-created debug or
+scratch artifacts remain in the deliverable; required recovery evidence and unrelated work are
+preserved and reported; and assumptions, limitations, and unverified runtime behavior are stated
+plainly.

.agents/skills/scopeguard/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Scope Guard"
+  short_description: "Keep work within agreed scope"
+  default_prompt: "Use $scopeguard when scope is expanding or a scope review is needed."

.env.example

@@ -0,0 +1,6 @@
+# Example Environment file for the application, copy as `.env` and fill in the values
+
+# if you want a player account with "Forger" (highest staff character)
+#   access ... this works for both production and local-dev
+GAME_MASTER_ACCOUNT=<account name>
+GAME_MASTER_ACCOUNT_PASSWORD=<account password>

.gitignore

@@ -44,4 +44,7 @@ Thumbs.db
 *_backup/
 
 # Local configuration
-*.local
+*.local
+
+# Environment files
+.env