@battlegrid/mcp-server 31.2.4 → 31.2.6

package/README.md

@@ -874,22 +874,30 @@ Install the BattleGrid skills for AI agent instructions:
 npx skills add playbattlegrid/battlegrid-mcp
 ```
 
-Two skills ship from this repo, and both are inside the npm tarball (`SKILL.md`, `skills/`):
-
-- **`battlegrid`** — connection, scopes, game play, and the strict compile → review → apply
-  strategy workflow.
-- **`battlegrid-strategy-studio`** — full-power strategy authoring, for agents that would
-  otherwise compile bare template strategies: custom report sections and system-generated header
-  grammar, benchmark sections, condition trees (verdict precedence, `required` enforcement
-  gates, `N_OF`/`NOT` groups, condition references), tiered signal weights and the
-  weighted-aggregate gate math, ATR trade levels, and post-entry position management. Its
-  `references/` carry five validated desk-grade playbooks (volatility-compression breakout,
-  crowded-positioning fade, benchmark-gated relative-strength rotation, HTF trend pullback,
-  perp/spot flow divergence at structure), copy-adaptable recipes, and process-for-process
-  ports of the most popular TradingView community scripts (Squeeze Momentum [LazyBear],
-  Supertrend/UT Bot, Chandelier Exit, MACD + 200 MA, golden cross, RSI-2, VWAP reversion,
-  Donchian/Turtle, ICT FVG/order blocks) with honest named substitutions where the grammar
-  lacks a primitive. Shapes are binding; vocabulary stays live-discovered.
+Nine skills ship from this repo, all inside the npm tarball (`SKILL.md`, `skills/`).
+
+**`battlegrid`** (repo root) is the connection skill and is authored here: how to connect, the
+`{ account, request }` envelope, the two scopes, and where to go for everything else.
+
+The eight `skills/battlegrid-*` are **exported from BattleGrid's server repository** — they are the
+same instructions BattleGrid's own in-app Commander runs on, which is why they name the same tools
+you reach over MCP:
+
+| Skill | Teaches |
+|---|---|
+| `battlegrid-agent-management` | Commission and govern intelligence agents: interview and create one against a committed strategy and an approved model, change configuration and risk limits, rebind, halt, resume, archive, and act on live positions |
+| `battlegrid-arena-play` | Enter Market Grid sessions: find an open session, read its coin pool and live market context, compose a grid with real per-coin reasoning or have an agent generate it, submit, then read results and the reasoning journal |
+| `battlegrid-market-analysis` | Read the current crypto market — regime, funding and open interest, leaders and laggards, a deep-dive on any named coin — and close with the levels worth watching |
+| `battlegrid-radar-deployment` | Put agents on standing duty: per-coin Radar policies that fire on confirmed regime flips, and per-preset Arena deployment policies, previewed before they are written and un-deployed with the blast radius stated |
+| `battlegrid-strategy-authoring` | Build a strategy from a plain-English idea: gather evidence, lock the spec, compile against the platform grammar, review exactly what will run, apply only on confirmation. Also fork, tune, restore, archive, preview |
+| `battlegrid-strategy-doctor` | Diagnose an agent that is not doing what was expected — why it has not traded, why it stopped, whether it is healthy — from typed fields, then rank the fixes with the exact lever each needs |
+| `battlegrid-strategy-examples` | Full-surface composition patterns: custom report sections and header grammar, benchmark sections, condition trees with verdicts and enforcement gates, tiered signal weights and the aggregate gate math, routing gates, ATR trade levels, position management, plus validated desk-grade playbooks and TradingView process ports |
+| `battlegrid-trade-analysis` | Read your own trading position: where the money is, whether each agent is doing its job, what is open and how close it sits to its protections, and whether the automation is actually running |
+
+> **`skills/battlegrid-*` is generated — do not edit it here.** It is written by
+> `server/scripts/export-mcp-skills.mjs` in `playbattlegrid/battlegrid-app` and arrives by pull
+> request; `skills/EXPORT.json` records a hash per file and `src/__tests__/skill-provenance.test.ts`
+> fails CI on a hand edit. Change the skill upstream and let the export lane bring it here.
 
 ## License
 

package/SKILL.md

@@ -7,6 +7,26 @@ description: MCP skill for BattleGrid — play crypto prediction games (Market G
 
 BattleGrid is a real-time cryptocurrency prediction gaming and trading platform. This MCP server gives AI agents access to play games, author trading strategies, and run strategy-bound intelligence agents.
 
+## The other eight skills
+
+This skill covers **connection**: how to reach BattleGrid, the request envelope, and what each scope
+grants. Everything about *using* the platform lives in the eight skills installed beside it, exported
+from BattleGrid's own server so they name exactly the tools you reach here:
+
+| For | Activate |
+|---|---|
+| Playing Market Grid sessions | `battlegrid-arena-play` |
+| Building or changing a strategy | `battlegrid-strategy-authoring` |
+| Composing beyond a bare template — conditions, weights, gates, trade levels, playbooks | `battlegrid-strategy-examples` |
+| Creating and governing intelligence agents | `battlegrid-agent-management` |
+| Putting an agent on standing duty (Radar, Arena presets) | `battlegrid-radar-deployment` |
+| Reading the market — regime, funding, leaders, a coin deep-dive | `battlegrid-market-analysis` |
+| Reading your own position, agents, and open trades | `battlegrid-trade-analysis` |
+| Working out why an agent has not traded or has stopped | `battlegrid-strategy-doctor` |
+
+Those eight carry the working arcs and the exact contracts. What follows here is the minimum needed
+to connect and to know which one to open.
+
 ## Discover the live surface first
 
 **Tools, prompts, and resources are discovered live from this MCP connection.** Always read the current `tools/list`, `prompts/list`, and `resources/list` before acting — a cached capability list is not authoritative after a server deployment. This skill teaches the workflows and the strict request contracts; it deliberately does not copy the server's tool catalog, metric/transform vocabulary, signal IDs, formulas, or default values. Discover those from the live tools (`list_strategy_categories`, `list_strategy_vocabulary`, `list_strategy_signals`, `get_strategy_signal_definition`, …). Never guess a metric, transform, parameter, template, signal, or enabled-timeframe fact.
@@ -25,70 +45,38 @@ Never put `account` inside `request`, and never flatten request fields beside it
 - `mcp:read` — strategy discovery **and** non-financial configuration writes (author strategies, edit agents, customize signals). Treat it as configuration authority, not view-only.
 - `mcp:wager` — financial actions (submit paid entries, accept/cancel entry decisions, deployment policies). Enable **Server-Signed Wagers** in Profile → MCP to grant it. Pending entry decisions come from the conversational surface, which waits for approval; an agent deployed to a radar coin or a trading-enabled arena slot executes without one.
 
-## Author a strategy: compile → review → apply
-
-Strategies are authored through one strict, whole-plan workflow. **Compilation changes no strategy, agent or revision; `apply_strategy_plan` is the only write to the strategy itself** — but compile is not read-only either: it parks the plan its own apply reads, and each call mints a distinct record and token, so compile once per reviewed payload and never retry or parallelise it. Review the exact returned plan before confirming.
-
-1. **Choose the operation and revision.**
-   - `list_strategies({ includeInactive? })` — visible SYSTEM and owned PRIVATE strategies with lifecycle, quota, usage, and revisions. Use `includeInactive:true` to prepare a RESTORE.
-   - `get_strategy({ strategyId, includeInactive? })` — the complete report, dense signal scorecard, gates, usage, and current `revision`. Thread every returned revision into the next revisioned call.
-2. **Discover the report vocabulary progressively.**
-   - `list_strategy_categories()` → `list_strategy_vocabulary({ category })` → `get_metric_construction_hints({ metric })` → `get_strategy_column_contract({ column, sectionTimeframe? })`.
-   - `get_strategy_section_template({ request })` for a listed template; `preview_strategy_report(payload)` for a point-in-time rendered preview.
-3. **Discover signals at the strategy timeframe.**
-   - `list_strategy_signals({ module?, query? })` → `get_strategy_signal_definition({ signalId, timeframe })`. Availability is structural, not a promise of a live trigger.
-4. **(Optional) review draft-only guidance.**
-   - `derive_strategy_rule_view({ sections, rules? })` returns report perception, server defaults, and suggestions without reading or writing a strategy. Suggestions/resets only shape the next plan input; they persist only through `apply_strategy_plan`.
-5. **Compile one complete plan.**
-   - `compile_strategy_plan({ request })`, where the nested request contains exactly one strict branch plus a bounded `coinSelection`, `intentSummary`, and `assumptions`:
-     - **CREATE** — supplies the full new aggregate.
-     - **UPDATE** — supplies at least one changed axis and `expectedRevision`. **Send only the
-       axes that change.** The server preserves every axis you omit and every signal you do not
-       name, and it re-derives the complete post-state, scorecard and diff itself. Restating the
-       whole post-state changes nothing about the result and the account pays for those tokens on
-       this call and on every later step of the conversation. Three fields are *not* axes and are
-       required on every compile regardless — `intentSummary`, `assumptions` and `coinSelection`;
-       omitting one is a typed error, not a saving.
-     - **RESTORE** — targets an owned inactive revision and may include repair axes.
-   - Signal overrides are sparse: an omitted signal/axis stays unchanged; omitted `params` preserves canonical params byte-for-byte; present `params` replaces them only after strict validation.
-   - **`required` needs a weight.** A rule with `required: true` at `allocation: 0` is rejected (contract 34): the scorecard's triggered set excludes Off, so the flag could satisfy no gate and block no trade. Either raise the allocation or leave `required: false` — the server picks neither for you. The refusal names every offending signal in `details.inertRequiredSignalIds`, and it can fire on rules you did not touch: a strategy authored before contract 34 may hold the pair, and the merged post-state is what gets checked.
-6. **Review before confirming.**
-   - `approvedPlan` — complete post-state, proposed revision, dense scorecard, viability, canonical diff, expiry, and bound-agent impact.
-   - `reviewContext` — exact column contracts, point-in-time report preview and coin scope, open-position observation, and provisional quota/name admission (advisory until the write). Open positions are awareness only and do not block an edit.
-   - The plan token expires after five minutes. Recompile after expiry, catalog drift, revision drift, or a changed bound-agent fence.
-7. **Apply the plan the server already holds.**
-   - After explicit user approval: `apply_strategy_plan({ request: { planToken, confirm: true } })`. **There is no `plan` member** — one is rejected as an unknown key. The server keeps the plan its own compile approved and reads it back, so nothing is copied from the compile response and nothing can be mistyped, truncated or half-reconstructed in transit.
-   - Forward `planToken` byte-for-byte exactly as compile returned it. It is an opaque signed value: never retyped, paraphrased, abbreviated or rebuilt from memory. A mangled token addresses no approved plan and is refused.
-   - Refusals and their recoveries: `PLAN_APPROVAL_NOT_FOUND` means no approved plan answers to this token — it was already applied, it lapsed, or it was never issued; compile again. `TOKEN_EXPIRED` means the five minutes ran out; compile again. Anything else — a quota, a name collision, a bound agent that changed, a moved catalog — **leaves the plan applicable**: clear the cause and confirm again with the same token while it lives.
-   - Changed configuration reaches every bound agent immediately. Report the returned strategy, committed revision, changed axes and applied impact exactly as given, and use that returned revision for the next mutation.
-
-**Focused edits & lifecycle:** `update_strategy_signal_rule({ request })` is the thin one-rule edit (requires `required`; omit `params` to preserve them; `required: true` needs `allocation > 0`). `fork_strategy` requires `sourceRevision`; `archive_strategy` requires `expectedRevision` and `confirm:true`; `restore_strategy` is only the thin unchanged-content path — if it reports `REPAIR_REQUIRED`, use the RESTORE compile/review/apply flow instead.
-
-**Author the full surface, not a template.** A bare compile — a few platform sections, no conditions, untouched signal weights — uses a fraction of the studio: the strategy aggregate also owns typed conditions (verdicts + `required` enforcement gates), tiered signal allocations with per-signal params, routing gates (`minAggregateScore`, `minRequiredCount`, `minAtrPct`), the ATR stop band + risk-reward floor, post-entry position management (break-even / trailing / time-decay), and marker-bearing Market Read prose. The companion **`battlegrid-strategy-studio` skill** (shipped beside this one) carries the capability map plus validated desk-grade playbooks and recipes for all of it — activate it whenever a strategy is being created or upgraded.
-
-## Strategy-bound agents
-
-Bind a strategy to an agent at creation time — there is no direct strategy-creation tool.
-
-1. `list_approved_models()` — valid `modelId` values for agent creation/update.
-2. `list_strategies()` — pick the `strategyId` to bind.
-3. `create_intelligence_agent({ …, modelId, strategyId })` — create a strategy-bound agent (avatar is server-minted).
-4. `update_intelligence_agent({ agentId, … })` — update config; rebinding via `strategyId` requires `confirm:true`.
-5. `get_agent_journal({ agentId })` / `get_agent_automation_status({ agentId })` — monitor performance and deployments.
+## Author a strategy, and bind it to an agent
 
-## Play a game (Market Grid)
+**The arc lives in `battlegrid-strategy-authoring`** — activate it, and `battlegrid-strategy-examples`
+alongside it when the strategy goes beyond a bare template. Do not compose a plan from this document;
+it states only what the *proxy* adds to that arc.
+
+Three facts about transport, which are this skill's to state because they are about the wire rather
+than about authoring:
 
-Predict UP or DOWN for each coin in the pool; exactly one coin is your **Captain** (2x score multiplier). Drive it from the live tools:
+- **The envelope is `{ request }`, or `{ account, request }` on a multi-account proxy** (see above).
+  It applies to `get_strategy_section_template`, `update_strategy_signal_rule`,
+  `compile_strategy_plan` and `apply_strategy_plan`.
+- **`planToken` is opaque and is forwarded byte-for-byte.** Never retype, paraphrase, abbreviate or
+  rebuild it from memory — the proxy passes the bytes through unchanged, and a mangled token
+  addresses no approved plan and is refused. It lives five minutes.
+- **`apply_strategy_plan` carries no `plan` member.** One is rejected as an unknown key: the server
+  reads back the plan its own compile approved, so nothing is copied out of the compile response and
+  nothing can be truncated or half-reconstructed in transit. Send
+  `{ request: { planToken, confirm: true } }` and nothing else.
 
-1. `get_account_state()` — balance, rank, agent slots, wager status.
-2. `list_market_grid_sessions({ status: "PENDING" })` — find an open game (a `$0` entry fee is risk-free).
-3. `get_market_grid_session({ sessionId })` — coin pool, timeframe, payout structure.
-4. `get_market_context({ sessionId })` — indicators, rankings, and trends for the session.
-5. `check_market_grid_submission({ sessionId })` — avoid duplicate submissions (`update_market_grid` to modify).
-6. `submit_market_grid({ sessionId, grid, reasoning, confidenceScore, modelName, pickReasoning })` — submit predictions.
-7. `get_market_grid_results({ sessionId })` — results once the session is `SETTLED`.
+Agents bind to a strategy at creation (`create_intelligence_agent({ …, modelId, strategyId })`);
+there is no direct strategy-creation tool. **`battlegrid-agent-management`** carries commissioning,
+reconfiguration, rebinding and intervention; **`battlegrid-radar-deployment`** carries putting an
+agent on standing duty; **`battlegrid-strategy-doctor`** carries diagnosing one that is not trading.
+
+## Play a game (Market Grid)
 
-**Grid validation:** grid size matches the coin pool; each coin appears once; positions are sequential (0,1,2,…); exactly one cell is `isCaptain: true`.
+Predict UP or DOWN for each coin in the pool; exactly one coin is your **Captain** (2x score
+multiplier). **The arc lives in `battlegrid-arena-play`** — activate it to find a session, read its
+market context, compose a grid with real per-coin reasoning, submit it, and read the results.
+**`battlegrid-market-analysis`** carries the market read that informs the picks, and
+**`battlegrid-trade-analysis`** carries reading back how you have done.
 
 The `play-market-grid` prompt (discover via `prompts/list`) provides a guided end-to-end workflow.
 

package/dist/index.d.ts

@@ -49,7 +49,7 @@ import { type Implementation, type Prompt, type Resource } from '@modelcontextpr
  * being asked. Move it for a change to THIS package — a proxy fix, a dependency bump, a docs
  * correction. Never move it to track the server.
  */
-export declare const PACKAGE_VERSION = "31.2.4";
+export declare const PACKAGE_VERSION = "31.2.6";
 export declare const DEFAULT_URL = "https://mcp.battlegrid.trade/mcp";
 export interface EnvConfig {
     apiKeys: string[];

package/dist/index.js

@@ -52,7 +52,7 @@ import { ListToolsRequestSchema, CallToolRequestSchema, ListPromptsRequestSchema
  * being asked. Move it for a change to THIS package — a proxy fix, a dependency bump, a docs
  * correction. Never move it to track the server.
  */
-export const PACKAGE_VERSION = '31.2.4';
+export const PACKAGE_VERSION = '31.2.6';
 export const DEFAULT_URL = 'https://mcp.battlegrid.trade/mcp';
 const MAX_RETRIES = 3;
 const RETRY_DELAYS_MS = [2000, 4000, 8000];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@battlegrid/mcp-server",
-  "version": "31.2.4",
+  "version": "31.2.6",
   "description": "BattleGrid MCP server — play crypto prediction games from AI agents",
   "type": "module",
   "main": "dist/index.js",

package/skills/EXPORT.json

@@ -0,0 +1,14 @@
+{
+  "generator": "battlegrid-app/server/scripts/export-mcp-skills.mjs",
+  "contractVersion": "50.0.0",
+  "files": {
+    "battlegrid-agent-management/SKILL.md": "b6ea75b3d838c1dbaaf3984d7e99a11c81686de2c1a1910c35699ee7e70dafa5",
+    "battlegrid-arena-play/SKILL.md": "03fa153bf82be18bf5ed01e3ba12e2cd9f99a81b08d903a77b52169e7519a182",
+    "battlegrid-market-analysis/SKILL.md": "22fde9c4eac0261c89a8056ab8b20b66fcbe1fd58447fa0ac84fd410b4d134d7",
+    "battlegrid-radar-deployment/SKILL.md": "d2a012b154e1e529db19529bd7c3d75d069f4e410d5804add51165f0f0902b2e",
+    "battlegrid-strategy-authoring/SKILL.md": "93680b329c158b353fdc7e1ec9058dfd8ab69904cd7f1ae14cf411870c695bf1",
+    "battlegrid-strategy-doctor/SKILL.md": "9ab3f79128ec81d3e90167c3f1ea4bd6f6b570290e5ebe2bf855195263c58239",
+    "battlegrid-strategy-examples/SKILL.md": "3e418df3590054b6da75435de79770ebdbdb7b88564534d9050ef209e0476a08",
+    "battlegrid-trade-analysis/SKILL.md": "32573a67e55d735e6ee4e36b3b48c815694102704bc453c4d1c13db39551b3da"
+  }
+}

package/skills/battlegrid-agent-management/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: battlegrid-agent-management
+description: Commission and govern the player's intelligence agents — interview and create one against a committed strategy and an approved model, change its configuration and risk limits, rebind it to another strategy, halt and resume it, archive and reactivate it, and act on its live positions (close, or move a stop outside the platform ratchet). Activate whenever the player wants a new agent, wants to change, pause, restart, retire or revive an existing one, asks what an agent is allowed to risk, or wants to intervene in a position an agent has open.
+---
+
+# Agent Management
+
+You are commissioning and governing **soldiers**. Commander does not trade — the agent does,
+under server policy, with the player's real capital. Everything here either creates that
+authority, changes it, or takes it away.
+
+## The four failures this flow exists to prevent
+
+Each one has a trigger cue. When you see the cue, you are in that failure's territory — go to the
+step named beside it before doing anything else.
+
+1. **Commissioning without a strategy.** *Cue: "make me an agent", "spin up a bot", any create
+   ask.* An agent's whole trading behaviour is materialized from a committed strategy, and
+   `strategyId` is required. You never invent one, never reach for "the default", and never
+   describe an agent you have not bound. → step 2.
+2. **Acting without blast radius.** *Cue: halt, archive, rebind, update, close, override — any
+   verb that changes what the agent may do.* Every one of these has a reach the player cannot see
+   from the verb: open positions that keep running, deployments that stop firing, materialized
+   configuration that is replaced. State the reach from the reads BEFORE the confirm form. → step 3.
+3. **Mis-lever'd halt recovery.** *Cue: "why is it stopped", "start it again", any halted agent.*
+   There are three halt reasons and they do not share a lever. Offering a drawdown baseline reset
+   to a daily-loss halt is offering something that cannot work. → step 4.
+4. **Driving strategy writes from this arc.** *Cue: the answer to an agent problem turns out to be
+   "change the strategy".* You can SEE strategies here because you must name what you bind. That is
+   not permission to author them. → the cross-skill rule below.
+
+## Cross-skill rule: strategy changes are not yours
+
+`list_strategies` and `get_strategy` are yours — the binding lookup is part of commissioning.
+`compile_strategy_plan`, `apply_strategy_plan`, `fork_strategy`, `archive_strategy`,
+`restore_strategy` and `update_strategy_signal_rule` are **not**, even though activating this
+skill makes them visible in the conversation.
+
+When the work is a strategy change, activate `strategy-authoring` and let its arc run — its
+evidence, spec-lock, compile-review and confirm rules bind from that point. Do not drive a
+strategy write from this arc's own steps. (Visibility is not authority: those tools keep their own
+server gates — plan token, schema confirm, ownership — and this rule is about which arc's
+discipline governs the change, not about what the server would accept.)
+
+## Sequence
+
+### 1. Discover before you propose
+
+- `list_intelligence_agents` — the roster, and what slots are already spent.
+- `list_approved_models` — the models that may be **selected right now**. This serves only
+  currently-available models; a model you remember from another agent may be deprecated, which
+  keeps serving agents already bound to it while refusing a new selection. Never name a model
+  from memory. **Send the row's `modelId`** — the `provider/name` string, e.g. `z-ai/glm-5.3` —
+  never its `id`. The `id` UUID identifies the catalogue row; `create_intelligence_agent` and
+  `update_intelligence_agent` key on `modelId` and accept nothing else.
+- `list_strategies` — the binding candidates.
+
+Read each thing once. A roster or agent you already fetched in this conversation is still in front
+of you; re-fetching costs the player the same payload twice and it rides every later step.
+
+### 2. Commission: interview, restate, confirm, create
+
+**No strategy, no agent.** If the player has no committed strategy they could bind, say so and
+offer the `strategy-authoring` arc first. Do not fabricate a binding, do not pick one on their
+behalf from a name you have not read, and do not create an agent "to fill in later".
+
+One interview with the player covering: **mandate** (what is this agent for), **risk posture**,
+**model**, **strategy**. Put the one-line reason for each option beside it — the model's own
+scores and the strategy's own description, as the tools returned them.
+
+When the picks come back, restate in one line: *"Commissioning: <name>, bound to <strategy>, on
+<model>, <risk posture>."* Then one confirmation naming **the strategy, the model, and the
+budget posture** — the capital ceiling and stops the trading configuration will carry, or that it
+will take platform defaults.
+
+Call `create_intelligence_agent` with an **`idempotencyKey`** derived from this conversation and
+this confirm turn. A create spends an agent slot against the player's rank quota; a retry after a
+dropped response would spend a second one. With the key, an ambiguous retry replays the original
+result instead.
+
+### 3. Lifecycle verbs: read first, state the radius, then confirm
+
+Every one of update, rebind, halt, resume, activate and archive runs this shape. The reads
+(`get_agent_budget`, `get_agent_fund_allocation`, `get_agent_open_positions`,
+`get_agent_automation_status`, `get_agent_performance`, `get_agent_journal`) need no confirm and
+cost nothing but a call — do them first, always.
+
+State the blast radius **from server fields, as numbers**, before the confirm form:
+
+- **Halt** — the open-position count (they keep running; halting opens no exit) and the deployment
+  coverage that stops producing entries.
+- **Archive** — the same, plus that the agent stops entering games and signal evaluations, and
+  that `activate_intelligence_agent` reverses it.
+- **Rebind** — that the target strategy's context modules, signal rules, prose and timeframe
+  **replace** the ones materialized on the agent (this is not a merge), naming both strategies.
+  Agent-owned settings are untouched.
+- **Update** — the concrete diff: each field, from what, to what.
+
+Then one confirmation. Act only on an explicit pick. Free text while a confirmation is open is
+not consent — answer what they said and re-present the same confirmation.
+
+**`expectedRevision` comes from the latest read.** A CONFLICT means the stored agent moved since
+you read it: re-read, re-state the radius against the NEW state, and re-confirm. Never retry with a
+bumped number — that is voting on a state you have not seen.
+
+**A refused archive names its own blockers.** The refusal carries typed `archiveBlockers[]` —
+DEPLOYED / OPEN_TRADES / ACTIVE_SESSION, each with a count. Report each blocker and its count as
+the reason, and name what would clear it (un-deploy via the radar/deployment tools, close or let
+the positions resolve, wait for the session to settle). Never paraphrase the refusal into "it
+didn't work", and never retry it unchanged.
+
+### 4. Halt recovery: branch on the served halt reason
+
+`get_agent_budget` serves `haltReason`. There are exactly three, and the lever differs:
+
+- **MANUAL** — the player halted it. `resume_intelligence_agent` lifts it unconditionally.
+- **DRAWDOWN_BREACH** — cumulative realized loss reached the drawdown stop. Two levers: raise
+  `maxCumulativeDrawdownUsd` through the update verb, **or** `reset_agent_drawdown_baseline`,
+  which acknowledges the loss and re-arms the stop from today (it erases no history and journals
+  the acknowledgement). Then resume.
+- **DAILY_LOSS** — realized loss for the day reached the daily limit. Two levers: raise
+  `maxDailyLossUsd` through the update verb, **or** wait for the UTC-day rollover, which clears it
+  automatically. **The baseline reset cannot clear a daily-loss halt — never offer it here.**
+
+**A resume attempted while the breach still holds is refused by the server**, with the current
+figure against the limit. Surface those served figures and the applicable lever from the list
+above. Do not retry the resume, and do not reach for the reset to "get past" a refusal that names
+a different stop.
+
+### 5. Risk limits are a whole object
+
+`update_intelligence_agent`'s `tradingConfig` is a **complete** configuration: what you send
+replaces what is stored, and every field in that schema is required when the object is present.
+
+So: **read the current configuration, write the complete object with your change applied**, and
+name **every changed value** in the confirm — from what, to what. Never assemble a partial config
+and never echo a read config back unchanged: the read shape is wider than the write shape
+(`strategyTimeframe` and `regimeTimeframe` are strategy-derived and rejected as unknown keys).
+
+### 6. Live positions: present the served state, name the bypass
+
+- `get_agent_open_positions` / `list_user_active_positions` / `get_position_audit_history` first —
+  the `decisionId` these two tools need is discoverable only through those reads.
+- **`close_agent_position`** is irreversible: it submits a reduce-only market order and realizes
+  the P&L. It carries a schema-level `confirm: true`, so present the position, its unrealized
+  P&L and its protections, and confirm before calling. An exchange rejection comes back as a typed
+  trading error — report it; a success means the close order was *accepted*.
+- **`override_agent_protection`** moves the effective stop. Its confirm must say, in words, that
+  the change **moves the stop outside the platform's protective ratchet** — that is exactly what
+  the tool is for — and name the direction: whether the new level sits further from or closer to
+  price than the one the platform is holding. Present the current protection first, then the
+  requested level, then that sentence. Its `result` is discriminated by `kind`: only `committed`
+  advanced anything; every other branch names why the amendment did not apply — read it, do not
+  assume the write landed.
+
+These tools carry no consent gate on either door: they are ownership-gated and behave identically
+in chat and through an external MCP client. Your confirm is interaction, never authorization —
+never describe it as a permission check, and never add one of your own.
+
+## When a write's outcome is unknown
+
+An interrupted or timed-out write may have landed. **Read current state first** — the agent
+(`get_intelligence_agent`), the budget, the positions — and report the committed outcome. If it
+committed, that is a success, not a failure to retry. Never re-issue a state-changing call over an
+unverified outcome, and never re-create over an unread roster.
+
+## Reporting discipline
+
+- Report numbers exactly as the tools return them. Never recompute, re-derive, or round.
+- Reads are free of confirms; every write has one, and the radius is stated before the form.
+- A tool that fails is reported as failed, with what could not be checked. Never convert a failed
+  read into "no issue".
+- Be concise. Every write on this surface points real capital somewhere, or takes it away.

package/skills/battlegrid-arena-play/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: battlegrid-arena-play
+description: Enter the player into Market Grid sessions — find an open session, read its coin pool and live market context, compose a grid with real per-coin reasoning or have one of their agents generate it, submit it against the session's entry fee, then read the results and the reasoning journal after settlement. Activate whenever the player wants to play, enter, join or submit to a session, wants their agent to enter one, asks what is open to play, or asks how a session they entered turned out.
+---
+
+# Arena Play
+
+A submission is a **wager**. On a paid session the entry fee moves as part of the submit call, and
+the grid you submit is the one that gets scored. There is no draft state and no undo.
+
+## The three failures this flow exists to prevent
+
+1. **A blind submission.** *Cue: "just enter me", "pick something", any ask that skips reading.*
+   A grid composed without the session's own market context is a guess the player pays for. →
+   steps 2–3.
+2. **A stale or superseded agent grid submitted.** *Cue: the agent generated a grid and then
+   anything happened — a regeneration, a long pause, a change of mind.* The submit consumes
+   whatever generation is cached, not the one the player looked at. → step 4.
+3. **Restating a limit number.** *Cue: the urge to say "you have N entries left today" or "your cap
+   is $X".* Daily wager caps are platform config with per-user overrides, and the pipeline is the
+   only authority on them. → the negatives below.
+
+## Sequence
+
+### 1. Account state first
+
+`get_account_state`. It carries the balance, the rank, and **`mcpWagerEnabled`** — a served
+projection of the player's Server-Signed Wagers signer consent.
+
+- **False** ⇒ say so up front, name the enablement path (Profile → Wallet tab → enable Agent
+  Wagers), and continue **read-only**: sessions, market context, results and journals are all still
+  useful. Do not pretend a submit will work.
+- **True** ⇒ proceed. It is a routing signal for what you tell them, never an authorization: the
+  wager pipeline re-checks consent at the fee itself, and its refusal is the authority in either
+  direction.
+
+### 2. Workflow A reads, in order
+
+1. `list_market_grid_sessions` with status `PENDING` — the sessions still enterable. **The
+   `sessionId` you use comes from here; never fabricate one.**
+2. `get_market_grid_session` — the coin pool (note each coin's `id`), the entry fee, the pool and
+   the lock time.
+3. `get_market_context` for that session — the indicators, rankings and trends the picks will
+   actually be reasoned from.
+4. `check_market_grid_submission` — **before composing anything.** If a submission already exists,
+   report it (with its id and time) and offer `update_market_grid` where the session still permits
+   it. Never compose a duplicate.
+
+### 3. Compose — the reasoning is yours to get right
+
+A direct submission carries `grid`, `reasoning`, `confidenceScore`, `modelName` and
+`pickReasoning`, and all of them are required.
+
+- **Exactly one cell is captain** (2× multiplier).
+- **`pickReasoning` carries one entry per grid cell — every cell, no coin twice.** Compose it
+  correctly because it is yours to compose, not because something downstream will catch it: the
+  boundary refuses an incomplete payload before the fee moves, and leaning on that check means
+  submitting payloads you have not read.
+- Each entry's reasoning cites **the market context you read in this conversation**, for that
+  coin. Boilerplate reasoning attached to a real wager is worse than none — it looks like
+  evidence.
+- `confidenceScore` is your honest read, and you state it to the player on the confirm form.
+
+**The agent path instead:** `generate_agent_grid` has one of the player's agents produce the grid.
+It spends a **billed LLM inference against the player's intelligence credits** — say that before
+you call it. Each call replaces any previous pick for this (session, agent) pair, and the pending
+generation lives about ten minutes.
+
+Present the generation as a card: the agent, its confidence against the threshold
+(`confidenceThreshold: null` means no deployment declares a bar here, so the grid is **ungated** —
+say that rather than inventing a bar), whether it meets the threshold, and the per-coin picks.
+
+### 4. Confirm, then submit promptly
+
+One confirmation naming **the session, its entry fee, and the confidence** — then submit on an
+explicit pick.
+
+- Direct → `submit_market_grid`.
+- Agent → `submit_agent_grid`, which consumes the cached generation for that (session, agent).
+
+**A regeneration voids any prior confirm.** The submit takes no generation token — it reads
+whatever is currently cached — so a grid regenerated after the player confirmed would be submitted
+under a confirmation given for different picks. Re-present the confirm for the new generation,
+every time, and submit promptly after the confirmed one.
+
+**If the submit is refused for a missing pending generation**, the ten-minute window lapsed. The
+recovery is `generate_agent_grid` again and a fresh confirm. **Never** convert the stale picks into
+a hand-composed `submit_market_grid` under the player's own name — that submits an agent's
+reasoning as the player's, and the attribution is part of what was scored.
+
+### 5. After settlement
+
+- `get_market_grid_results` — available only once the session is SETTLED. Before that it returns a
+  typed CONFLICT naming the current status: **report it and stop**. Do not poll it in a loop; the
+  op budget is finite and a settling session is not a failure.
+- `get_mcp_reasoning_journal` on request — the reasoning, confidence and picks as recorded at
+  submit. Compare the outcome against what was actually reasoned, and say where the reasoning was
+  wrong.
+
+## Refusals, and what each one means
+
+Each is typed and distinguishable. Read the code, do not paraphrase:
+
+- **No wallet consent** — the shared wager pipeline's own refusal, carrying its enablement copy.
+  Surface that path verbatim. This is the same refusal an external MCP client gets; there is no
+  chat-side difference and no chat-side override.
+- **A daily cap** — a typed rate-limit refusal. Say the cap is spent and that it resets on the UTC
+  day. Distinguishable from the run's op budget and from consent — do not merge them into "you
+  can't play right now".
+- **Funds, session state, an already-submitted grid** — ordinary typed refusals. Report what the
+  server said.
+
+## Negatives
+
+- **Never restate a limit number** — not the daily count, not the volume cap. The pipeline holds
+  the real value including per-user overrides, and a number repeated from anywhere else will
+  eventually be wrong on a surface where being wrong costs money.
+- **Never use `random_submit_market_grid`.** It shuffles the pool and wagers on the result with no
+  reasoning at all. It exists for other clients; it is not something to offer a player who asked
+  you to think.
+- **Your confirmation with the player is interaction, never authorization.** Do not describe it as
+  a permission check, do not add a wager gate of your own, and do not treat free text typed while a
+  confirmation is open as consent.
+- **Never re-submit over an unknown outcome.** An interrupted submit may have committed the fee.
+  Run `check_market_grid_submission` first and report what actually exists.
+
+## Reporting discipline
+
+- Report fees, pools, scores and payouts exactly as served. Never recompute a payout or a rank.
+- Name the session and the fee every time money is about to move.
+- A tool that fails is reported as failed. Never fill a gap with a plausible value on a surface
+  that is about to charge someone.

package/skills/battlegrid-market-analysis/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: battlegrid-market-analysis
+description: Read the current crypto market for the player — regime, funding and open interest, leaders and laggards, and a deep-dive on any coin they name — and close with the levels worth watching. Activate whenever the player asks what the market is doing, whether to be long or short, which coins are moving, or for a read on a specific coin.
+---
+
+# Market Analysis
+
+You are answering "what is the market doing, and what should I watch?" with measurements, not
+opinions.
+
+## The one rule: measure before you opine
+
+Do not form a view and then fetch data that agrees with it. Fetch first, state what the numbers
+say, and let the view follow. Every claim in your answer must trace to a tool result in this
+conversation. If you did not measure it, you do not assert it.
+
+## Sequence
+
+Run these in order. Skip a step only when the player's question makes it irrelevant, and say so.
+
+1. **Regime.** `get_regime_snapshot` for the current read. `get_regime_history` when the player
+   asks how we got here, or when the snapshot alone would hide a fresh flip — a regime that
+   turned in the last few periods is a different fact from one that has held for weeks.
+2. **Market context.** `get_market_context` — this carries the breadth, funding and open-interest
+   picture. Funding and OI are the two figures most often skipped and most often decisive: crowded
+   positioning is the difference between "trend" and "trend about to be squeezed". Report both.
+3. **Leaders and laggards.** `get_top_ranked_coins`. Name the actual coins at both ends, not just
+   "strength in majors". A laggard list is as informative as a leader list and is usually omitted.
+3b. **Many coins on the same indicators — one call, not one per coin.** When the answer needs the
+   indicator modules ACROSS a set of coins (comparing RSI, funding or volatility over the leaders,
+   over a category, over the session pool), use `preview_strategy_report`: one table per module with
+   coins as rows, the schema preamble emitted once instead of per coin, and a server-reported token
+   budget. Ask `list_strategy_categories` for the section catalogue and pass the sections you want as
+   `{ "kind": "platform", "sectionKey": "includeRsi" }` — no authoring vocabulary is needed. Use
+   `{ "mode": "ranked", "limit": N }` as the coin selection when you have no explicit list.
+   Looping a per-coin tool over N coins costs several times this and returns the same values.
+4. **Coin deep-dive**, when the player named a coin or when one dominates the read: the SAME
+   `preview_strategy_report` call as step 3, with `{ "kind": "tickers", "tickers": ["SOL"] }` as the
+   coin selection and the funding / open-interest / positioning sections chosen — one coin is a
+   one-row report, not a different tool. Then `get_coin_candles` for the price action. For momentum
+   across timeframes, add the Relative Strength section — it carries the PPO trajectory and its
+   zero-crossing — or author `PPO` columns at the intervals you want pinned; that is the same read
+   at the precision the catalog declares, in the call you are already making. Use
+   `get_coin_performance_history` when the question is about how it has behaved, not where it is.
+4b. **How much of the FIELD is moving, not just this coin.** Add the Market Breadth module
+   (`{ "kind": "platform", "sectionKey": "includeMarketBreadth" }`) for the two-axis read: how much
+   of the tracked universe closed up, and how much of it carries positive momentum. It reports per
+   category as well as whole-universe, so a crypto call is not swayed by an equities selloff. Those
+   are report-level scalars — one table for the whole answer, not a per-coin download.
+5. **Close with what to watch.** Every answer ends with levels or conditions — the price that
+   invalidates the read, the level that confirms it, the event that would change it. An analysis
+   with no "what to watch" close is unfinished.
+
+## When the evidence contradicts the player
+
+If the player states a direction ("I'm long SOL, confirm it's going up") and what you fetched
+points the other way, do **not** proceed on their premise, and do **not** silently substitute your
+own. Present the contradicting evidence plainly, then put the direction back to them — offer the
+options their own data supports. They may know something you cannot measure; the
+point is that they decide with the contradiction in front of them, not behind it.
+
+## Reporting discipline
+
+- Report numbers exactly as the tools return them. Never recompute, re-derive, or round.
+- Separate what you measured from what you infer. "Funding is +0.03% and OI rose 12%" is a
+  measurement; "positioning is crowded long" is the inference from it — say both, in that order.
+- A tool that fails or returns nothing is reported as such. "I could not read the regime" is a
+  useful answer; inventing one is not.
+- Be concise. The player is reading this beside their positions.
+
+## Not available — say so rather than approximating
+
+- **Smart-money / whale concentration.** No tool exposes holder concentration or large-wallet
+  flow. If the player asks, say it is not something you can measure here.
+- **Cross-asset macro** (equities, DXY, rates, gold). Out of reach — this surface is
+  crypto-native only. Do not substitute BTC as a macro proxy and present it as one.