SkipDocumentación Skipdocs
Prompts

Plan de integración

Plan de proyecto listo para presentar — hitos, owners, riesgos, Gantt.

Da los datos de tu equipo, stack y deadline. El agente arma un plan en Markdown que un(a) director(a) o COO puede leer sin contexto técnico — hitos numerados, owners, duración por fase, Gantt en ASCII, y los riesgos que importan.

Completa tu contexto

Copia el prompt compuesto

Completa los campos obligatorios para activar la copia: Productos Skip, Equipo disponible (roles, nombres), Resumen del stack, Deadline.

# Resumen de integración Skip

Skip es una plataforma chilena de salud con dos productos que los partners integran:

## Spot
Onboarding de pacientes y automatización de boletas médicas. Tres formas de integración:
- Widget: el backend mintea un token de un solo uso (POST /api/spot/widget), se embebe un iframe en el sitio del partner, el paciente llena un formulario, el partner escucha eventos postMessage.
- POS: flujo de mostrador. El personal hace lookup por RUT, crea usuario. Sin iframe.
- Boletas: el backend empuja boletas a /api/spot/gastos (archivo) o /api/spot/gastos-url (URL). La IA extrae los datos, el reembolso ISAPRE se presenta automático.

Auth: public_key (browser-safe, query param). Algunos endpoints admin usan un header secret_key aparte.

## AAPD / CNPL
"Atiéndete Ahora y Paga Después". 30% pagado al momento con tarjeta, 70% financiado por Ventipay (proveedor de préstamo, totalmente gestionado por Skip), reembolso ISAPRE presentado automático. Skip cobra el 70% restante cuando la ISAPRE paga — o antes si hay 3 días de acceso ISAPRE bloqueado, o al día 45 sin aprobación.

Endpoints (gokeipay-api en https://pay.getskip.ai):
- POST /orders (auth: client_secret) — crea la orden, devuelve hash
- POST /orders/{hash}/validate_customer_identity (auth: client_id) — el widget llama esto
- POST /orders/{hash}/add_payment_method (auth: client_id) — el widget llama esto
- POST /orders/{hash}/payment (auth: client_id) — el widget llama esto
- PUT /orders/{hash}/refund (auth: client_secret) — reembolso total o parcial

Credenciales de auth:
- public_key: browser-safe, para Spot.
- client_id: browser-safe, para operaciones de paciente AAPD.
- client_secret: solo backend, para creación de órdenes/reembolsos AAPD.
- webhook_secret: solo backend, para verificar firmas HMAC-SHA256 de webhooks.

## Webhooks (AAPD)
SkipPay envía webhooks firmados a una URL hosteada por el partner.
- Firma: X-Gokeipay-Signature: sha256={hex}, HMAC-SHA256 sobre el body JSON crudo usando webhook_secret.
- Retries: 6 intentos con backoff exponencial (1m, 5m, 15m, 30m, 60m). Timeout: 10s por intento.
- Eventos que reciben los partners: order.paid, order.partially_paid, order.refunded, order.failed, order.cancelled.
- Siempre incluye event_id para idempotencia.

## Ambientes
- Producción: backend.getskip.ai (Spot), pay.getskip.ai (AAPD), spot.getskip.ai (host del widget).
- Staging: mismos hosts con prefijo staging., ej. staging.backend.getskip.ai. Credenciales de prueba son pk_test_*, ci_test_*, st_test_*.
- Presentación ISAPRE en staging está mockeada (no se presentan reembolsos reales).
- Ventipay en staging es sandbox (no se mueve plata real).

## Fases típicas de integración
1. Emisión de cuenta y credenciales (equipo Skip).
2. Creación server-side de órdenes (solo AAPD): POST /orders.
3. Minteo server-side de widget tokens: POST /api/spot/widget.
4. Embed del iframe + manejo de eventos postMessage en frontend.
5. Receptor de webhooks: endpoint HTTPS + verificación HMAC + procesamiento idempotente.
6. Test end-to-end en staging con pacientes de prueba.
7. Rollout a producción.

Skip se encarga de: presentación de reembolsos ISAPRE, retries de pago, notificaciones WhatsApp/email al paciente, payouts a sub-centros (para meta-prestadores). Los partners no implementan nada de esto.

## Conceptos
- Provider: la ficha del partner en la base de datos de Skip.
- Beneficiary: la ficha del paciente. Identificada por RUT.
- ISAPRE: aseguradora privada chilena de salud. Las credenciales del paciente se guardan en Skip; Skip presenta los reembolsos en su nombre.
- RUT: ID nacional chileno. Formato XXXXXXXX-Y donde Y es un dígito verificador (0-9 o K). Skip normaliza (saca los puntos).
- order_token: igual al campo hash que devuelve POST /orders. Pásalo al widget para activar el flujo AAPD.
- widget_token: UUID que identifica un TempWidgetToken. TTL de 1 hora, o 30 días para long-term tokens.
- meta-prestador: partner que opera con muchas sub-clínicas detrás de una sola integración. Onboardea sub-clínicas vía POST /api/spot/sacmed/centers, después pasa provider_rut en POST /orders.

## Qué los partners NO construyen
- Integración con la ISAPRE (Skip se encarga).
- Underwriting de crédito/préstamo (Ventipay se encarga).
- Despacho de notificaciones al paciente (Skip se encarga).
- Liquidación / payouts (Skip se encarga).
- Almacenamiento de tarjetas / scope PCI (Ventipay se encarga).


# Contexto del proyecto
- Productos: 
- Equipo: 
- Stack: 
- Deadline: 
- Constraints: ninguno declarado

# Tu tarea
Produce un plan de proyecto en Markdown para la integración Skip que un stakeholder no técnico (director(a) de clínica, COO) pueda leer. Estructura:

## Objetivo
Una sola frase.

## Hitos
Numerados, cada uno con:
- Entregable (qué va a existir cuando esté listo).
- Owner (persona nombrada).
- Duración estimada en calendario.
- Criterios de aceptación.

## Línea de tiempo
Gantt en ASCII desde hoy hasta el deadline.

## Riesgos
Top 5 riesgos con mitigación.

## Dependencias del lado Skip
Qué debe entregar el equipo Skip y cuándo.

Escribe para lectura no técnica. Sin jerga sin explicación.

Cómo debería verse la respuesta

Ver ejemplo de salida

Objetivo

Integrar el producto AAPD de Skip para que los pacientes que reservan en nuestra clínica puedan pagar 30% al momento y 70% vía reembolso del seguro — para el 2026-08-01.

Hitos

1. Cuenta + emisión de credenciales — Equipo Skip

  • Entregable: credenciales de producción y staging entregadas vía 1Password.
  • Owner: Equipo Skip (Diego coordina).
  • Duración: 2 días.
  • Aceptación: las credenciales cargan, /api/profile devuelve scopes válidos.

2. Integración backend — Carlos

...

Riesgos

  1. Idempotencia de webhooks — mitigación: implementar tabla de dedup indexada por event_id.
  2. WebView en app móvil — mitigación: diferida a v1.1. ...