CommunityProgramación y desarrollogithub.com

aabrur/trading-agent-mpu-gandring

Úsese antes de enviar cualquier orden, en CEX (Bybit V5) o DEX (Hyperliquid). Entrevista al propietario para obtener límites por escrito, dimensiona cada ticket a partir de una cuenta en vivo y devuelve PASS o FAIL. Nunca envía órdenes.

¿Qué es trading-agent-mpu-gandring?

Este agente actúa como una puerta de enlace de gestión de riesgos que debe utilizarse antes de que cualquier orden sea enviada, tanto en exchanges centralizados como Bybit V5 como en descentralizados como Hyperliquid. Su función principal es realizar una entrevista al propietario para establecer límites de riesgo por escrito (pérdida máxima por ticket, apalancamiento máximo, mercados permitidos, etc.) y luego, para cada ticket, leer datos en vivo de la cuenta (saldo, posiciones, órdenes abiertas), calcular el tamaño adecuado de la operación usando una fórmula que incorpora comisiones y deslizamiento, y devolver PASS si el ticket cumple todos los límites o FAIL en caso contrario. Es crucial porque nunca envía, modifica ni cancela órdenes, delegando esa responsabilidad a un módulo de ejecución separado, y porque aplica reglas estrictas como no usar datos antiguos, verificar que el stop esté en la dirección correcta y respetar topes de riesgo global. Funciona en modo entrevista para recopilar límites, luego en modo de verificación por ticket, y está diseñado para ser usado en conjunto con un agente de ejecución que solo actúa tras recibir un PASS.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/aabrur/trading-agent-mpu-gandring/tree/HEAD/skills/risk-gate

Installed? Explore more Programación y desarrollo skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Puerta de riesgo

Dimensiona riesgos y los veta. El riesgo nunca envía, modifica ni cancela una orden. Solo el asiento de ejecución envía, una vez, después de un PASS.

1. Entrevista de configuración (haga una pregunta a la vez)

No firme ningún ticket hasta que todas las respuestas estén escritas en risk-limits.md en la carpeta de trabajo.

  1. Lugar: ¿CEX (perpetuos USDT lineales de Bybit) o DEX (perpetuos de Hyperliquid)? ¿Testnet primero o mainnet?
  2. Acceso de lectura: ¿qué cuenta puedo leer saldos, posiciones y órdenes abiertas? Solo necesito alcance de lectura. La clave que puede comerciar pertenece al asiento de ejecución y se lee desde una variable de entorno, nunca se pega en el chat ni se envía a un repositorio.
  3. Pérdida máxima por ticket, como un porcentaje del capital si se activa el stop. Valor predeterminado sugerido 1%. Todo lo que supere el 5% recibe una advertencia simple y una confirmación por escrito.
  4. Riesgo total máximo abierto en todas las posiciones. Valor predeterminado sugerido 3%.
  5. Posiciones máximas. Valor predeterminado sugerido 2.
  6. Apalancamiento máximo. Valor predeterminado sugerido 3x.
  7. Mercados permitidos (símbolos exactos, por ejemplo, ETHUSDT, SOLUSDT en Bybit o ETH, SOL en Hyperliquid).
  8. Límite de pérdida diaria como un porcentaje del capital al inicio del día. Valor predeterminado sugerido 5%. Cuando se alcanza, el trading automático se pausa hasta que el propietario lo reinicie por escrito.
  9. Deslizamiento máximo al enviar. Valor predeterminado sugerido 10 bps.

El modo de aprobación (aprobar cada ticket o autoenviar cada PASS) se pregunta una vez en order-execution, no aquí. El modo automático necesita que el límite de pérdida diaria del paso 8 esté escrito primero.

Escriba las respuestas, la fecha y el lugar en risk-limits.md. Los límites escritos más nuevos reemplazan a los anteriores; nunca los mezcle.

2. Cada ticket

Un ticket debe nombrar: mercado, lado, tipo de entrada y precio, precio de stop, tamaño o presupuesto de riesgo, y el lado de la estrategia del que proviene con su hora de cierre de la vela.

Lea en vivo, justo antes de dimensionar:

  • Cuenta: capital, margen disponible, posiciones abiertas, órdenes abiertas.
    • Bybit: GET /v5/account/wallet-balance, GET /v5/position/list?category=linear, GET /v5/order/realtime?category=linear.
    • Hyperliquid: POST /info con clearinghouseState y openOrders para la dirección de la cuenta.
  • Instrumento: cantidad mínima, paso de cantidad, tamaño de tick, nocional mínimo, apalancamiento máximo.
    • Bybit: GET /v5/market/instruments-info?category=linear&symbol=....
    • Hyperliquid: POST /info con meta (szDecimals, maxLeverage).
  • Libro: mejor oferta y demanda. Rechace si tiene más de 60 segundos.

Dimensionamiento:

pérdida_estresada = qty * |entrada - stop| + qty * entrada * comisión_taker * 2 + qty * entrada * deslizamiento
qty = redondear_al_paso(máx_pérdida_usd / pérdida_estresada_por_unidad)

Use la comisión taker real del lugar (Bybit lineal predeterminado 0.00055; Hyperliquid según su nivel de comisión).

FALLA si alguna de estas es verdadera:

  • Sin stop, o stop en el lado incorrecto de la entrada.
  • Mercado no en la lista permitida.
  • qty después del redondeo está por debajo del mínimo del exchange, o el nocional mínimo no se puede alcanzar sin romper el límite de pérdida. No redondear hacia arriba para ajustar.
  • El margen con el apalancamiento elegido excede el margen disponible.
  • Apalancamiento por encima del límite, las posiciones excederían el límite, o el riesgo total abierto excedería el límite.
  • El límite de pérdida diaria ya se ha alcanzado.
  • El lado de la estrategia está cancelado (precio más allá de su invalidación) en el libro en vivo.
  • La lectura de la cuenta o del libro falló o está desactualizada. Nunca se usan números antiguos.

PASS escribe un archivo risk/<hora UTC>-<símbolo>-<lado>-pass.md con: entradas, lecturas en vivo con horas UTC, qty, stop, apalancamiento, pérdida estresada en USD y como % del capital, y el id del ticket. FALLA escribe lo mismo con el motivo.

3. Reglas que nunca cambian

  • Nunca enviar una orden. Nunca mover fondos. Nunca pedir o imprimir una clave privada.
  • Sin promesas de ganancias. El PnL no realizado no es ganancia. Un depósito no es ganancia.
  • El acuerdo entre bots no es evidencia. El efectivo inactivo no es una razón para operar.
  • Si se desconoce el resultado de un envío, no se reenvía nada hasta que se lea el registro del exchange.
  • Los secretos solo viven en variables de entorno o en el almacén de secretos de la plataforma, nunca en el repositorio.

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

Skills relacionados