con un clic
nautilus-competition-run
nautilus-competition-run contiene 7 skills recopiladas de cajias, con cobertura ocupacional por repositorio y páginas de detalle dentro del sitio.
Skills en este repositorio
Diagnose and fix failures in `paper.mode: live` runs against Binance Spot Testnet. Use when: (1) a live paper run aborts with `HttpClientBuildError("builder error")` from the Rust adapter; (2) a live paper run aborts with `MissingBinanceCredentialsError` from the fail-fast guard in `paper_phase._run_live`; (3) a live paper run reaches Binance and is rejected with `-2014` / `-2015` / `-1022`; (4) setting up a fresh Amazon Linux 2023 / RHEL / Fedora host for live paper for the first time; (5) the operator's shell exports a stale `SSL_CERT_FILE` (e.g., from isengard-cli) that points at a non-existent path; (6) a `compete status <run-dir>` post-mortem surfaces a live-paper failure root-cause bucket; (7) deciding which files in `nautilus-trading/` and the competition repo need to exist before running `compete run --paper-mode live`.
Operator runbook for the nautilus-competition CLI. Use when: (1) scaffolding a working directory via `compete init` (or laying it out manually); (2) running `compete run <working-dir>` with `--paper-duration-minutes`, `--rounds`, `--metrics-endpoint`, or `--run-id`; (3) reading the output tree under `<working-dir>/runs/<run_id>/` (eval/, paper/, leaderboard.md, final_leaderboard.md); (4) triaging a team that hit `max_train_iterations` and produced a `FAILED` marker / `FAILED.json`; (5) deciding between simulated and live paper modes; (6) running the hermetic demo at `examples/demo_competition/`.
Per-team authoring contract for nautilus-competition. A team is a MULTI-AGENT system (5-role baseline: researcher + hypothesis-generator + critic + risk-officer + memory-keeper, plus paradigm-specific specialists) that runs INSIDE `train(ctx)` to crystallize a strategy + `runtime_rules.json`. Use when: (1) creating or editing a team folder under `<working-dir>/teams/<team_name>/`; (2) designing the internal agent roster and orchestrating it in `train()`; (3) writing the researcher's `run_claude(...)` prompt or any paradigm-specific specialist stub; (4) writing or modifying a team's `entry.py` `def train(ctx) -> tuple[type[Strategy], StrategyConfig]`; (5) deciding how to use `ctx.prev_gain` for the anti-stuck paradigm-swap; (6) using `ctx.get_train_data` / `ctx.get_test_data` / `ctx.prev_round_leaderboard`; (7) designing the trade-time live Python critic that reads `runtime_rules.json` (no LLM at trade-time); (8) sizing the bar type vs `paper.duration_minutes` so indicators warm up; (9) respecting window disci
General-purpose NautilusTrader (nautilus_trader) usage guidance, OUTSIDE the nautilus-competition framework. Use when: (1) explaining NautilusTrader's event-driven architecture, MessageBus, or actor model for someone new to the library; (2) deciding between `BacktestEngine` / `BacktestNode` (historical replay) and `TradingNode` (live/testnet/paper over real venues) and describing the shared-Strategy-code principle; (3) writing a standalone `Strategy` subclass — lifecycle hooks (`on_start`, `on_bar`, `on_order_filled`), `order_factory` usage, indicator registration order; (4) picking `OmsType` (NETTING vs HEDGING) or `AccountType` (CASH vs MARGIN) for a non-competition backtest. Do NOT use this skill when (a) the question is specifically about the `nautilus-competition` repo (team contract, `compete` CLI, observability, leaderboard) — those have dedicated `nautilus-competition-*` skills; or (b) the user is hitting the logger-singleton panic or the catalog/instrument precision mismatch — those have dedicated `n
Live observability stack for nautilus-competition runs. Use when: (1) bringing up the docker-compose Prometheus + pushgateway + Grafana stack with `docker compose -f docker-compose.observability.yml up -d`; (2) wiring `compete run` to push metrics via `--metrics-endpoint` / `COMPETE_METRICS_ENDPOINT`; (3) the dashboard at http://localhost:3000/d/competition shows "No data"; (4) inspecting raw metric values via `curl http://localhost:9091/metrics`; (5) understanding the eight panels (Active Round, Eval gain_factor, Paper equity, Current price, Eval backtests, Latest metrics, Team failures, Avg eval duration); (6) wiping pushgateway state between runs.
Fix for "RuntimeError: invalid bar.volume.precision=N did not match instrument.size_precision=M" or similar bar/instrument precision-mismatch errors at BacktestEngine.run() time. Use when: (1) bars come from a ParquetDataCatalog and the instrument is loaded from somewhere else (TestInstrumentProvider, hand-built, hard-coded), (2) eval works but paper fails (or vice versa) on the same data, (3) you've seeded a catalog with one tool and are running the engine with an instrument from another. The fix is to load instruments FROM the catalog so their precisions match the bars stored alongside them.
Fix for nautilus_trader's global Rust logger panicking on second init within the same Python process. Use when: (1) you see "thread '<unnamed>' panicked at crates/common/src/ffi/logging.rs:146:14: Failed to initialize logging: attempted to set a logger after the logging system was already initialized", (2) a second `BacktestEngine` instantiation crashes mid-process even when the first one succeeded, (3) `Fatal Python error: Aborted` from a nautilus test after a prior test in the same pytest run already created an engine, (4) running `compete run` / any harness that creates multiple BacktestEngine instances per run aborts the second engine. Covers the bypass_logging fix, the pytest-process-isolation pattern, and why TradingNode → BacktestEngine sequences hit it too.