Corrige el 500 de POST /orders cuando items está vacío.
Revisa src/orders.ts y tests/orders.test.ts.
Devuelve 400 sin cambiar el contrato de los casos válidos.
Añade un test de regresión y ejecuta esa suite.

Mantén la API pública actual. Limita el refactor al parser
y conserva los mensajes de error existentes.
Comprueba la compatibilidad con los fixtures de v1.

# Convenciones
- Usa TypeScript estricto.
- Para cambios de lógica, ejecuta npm test.
- No edites archivos generados en src/generated/.
- Consulta docs/api.md cuando cambies endpoints.

# Billing
- Mantén las operaciones de cobro idempotentes.
- Usa importes en céntimos enteros.
- Prueba reintentos y eventos duplicados.
- Conserva compatibilidad con los webhooks publicados.

---
name: revisar-sql
description: Revisa migraciones SQL para detectar bloqueos y pérdida de datos.
---
1. Lee la migración y el esquema afectado.
2. Detecta locks, backfills y cambios incompatibles.
3. Propón validación y estrategia de recuperación.
4. Informa hallazgos; no ejecutes la migración.

# Uso: $revisar-sql revisa migrations/042.sql

---
name: preparar-release
description: Prepara notas de versión a partir de un rango de commits.
---
1. Solicita el rango si falta.
2. Agrupa cambios en funcionalidades, fixes y rupturas.
3. Guarda RELEASE_NOTES.md y señala pasos manuales.

# Uso: $preparar-release desde v1.4.0 hasta HEAD

Busca dónde se valida el token y sus tests.
Lee solo esos archivos y el contrato de autenticación.
Explica el flujo citando rutas y líneas antes de cambiarlo.

Busca en la documentación interna el contrato de facturación v2.
Devuelve la fuente y versión de cada regla utilizada.
Compara esos requisitos con services/billing/.
Si no encuentras evidencia, señala la laguna.

# Migrar caché
Objetivo: conservar contrato y reducir lecturas a BD.
- [ ] Medir comportamiento actual.
- [ ] Añadir adaptador detrás de flag.
- [ ] Probar fallos y expiración.
Aceptación: misma respuesta en los fixtures de contrato.
Decisiones: registrar cambios de enfoque y su motivo.

Lee docs/plans/cache.md y comprueba el estado real del repo.
Continúa por el primer hito pendiente.
Actualiza progreso, decisiones y resultados de pruebas.
No marques como hecho lo que no has verificado.

[features]
memories = true

# En una sesión interactiva:
# /memories

Documenta en docs/decisions/007-cache.md por qué usamos Redis.
Incluye límites y fecha de la decisión.
Enlaza ese documento desde AGENTS.md para cambios de caché.

[mcp_servers.openai_docs]
url = "https://developers.openai.com/mcp"

# Después, en Codex:
# Consulta la documentación oficial de Responses con openai_docs.

codex mcp add tickets -- node /ruta/absoluta/tickets-mcp.mjs
codex mcp list

# Prompt: consulta ENG-42 y contrasta su aceptación con el diff.

Con GitHub, lee la PR 123 de mi-org/mi-repo.
Resume cambios de contrato y riesgos con referencias al diff.
Deja los hallazgos en este chat.

Consulta el issue ENG-42 en Linear.
Propón tareas de implementación y pruebas de aceptación.
Señala dependencias y guarda el plan en docs/plans/ENG-42.md.

{
  "hooks": {
    "SessionStart": [{
      "matcher": "startup|resume",
      "hooks": [{"type": "command", "command": "git status --short"}]
    }]
  }
}

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{
        "type": "command",
        "command": "npm test",
        "timeout": 120
      }]
    }]
  }
}

Usa dos subagentes en paralelo: uno analiza autenticación
y otro cobertura de tests. Que no editen archivos.
Cada uno debe devolver rutas, hallazgos y evidencia.
Integra los resultados en un único plan.

Delega a un subagente la documentación de docs/api.md
y a otro los tests de tests/parser.test.ts.
Tú implementa src/parser.ts. Fija primero el contrato común.
Integra y ejecuta la suite al terminar.

git worktree add ../mi-proyecto-cache -b experimento/cache

# Abre esa carpeta como proyecto en Codex.
# Prompt: implementa una caché detrás de un feature flag.

Realiza esta tarea en un worktree: actualiza las dependencias
compatibles y ejecuta las pruebas.
Prepara un diff con las versiones y los fallos encontrados.
Conserva mi trabajo del checkout actual.

sandbox_mode = "workspace-write"
approval_policy = "on-request"

prefix_rule(
    pattern = ["git", "push"],
    decision = "prompt",
    match = ["git push origin feature/parser"],
)

/review

# Elige cambios sin commit o comparación con la rama base.
# Prioriza regresiones, pérdida de datos y casos límite.
# Para cada hallazgo: archivo, entrada que falla y prueba.

Evalúa revisar-sql en 8 migraciones y 4 tareas ajenas a SQL.
Mide: activación correcta, riesgos detectados y falsos positivos.
Guarda casos, resultados y coste observado en evals/results.md.
Compara con el mismo conjunto antes de cambiar la skill.

Compara dos configuraciones disponibles en 10 tareas:
5 cambios sencillos y 5 bugs complejos.
Registra aceptación, duración y consumo.
Usa la configuración más económica que cumpla tu umbral.

Prepara un dataset revisado de tickets y etiquetas.
Separa entrenamiento y evaluación sin duplicados.
Compara un prompt base con un modelo ajustado compatible.
Mide macro-F1 y coste; no incluyas secretos en el dataset.

Analiza los módulos de src/. Genera docs/architecture.md
con responsabilidades, dependencias y un diagrama Mermaid.
Cita rutas reales y marca las inferencias.

Con metrics.csv, crea outputs/metrics.html autocontenido.
Incluye tabla filtrable, unidades y origen de los datos.
Comprueba que totales y filas coinciden con el CSV.
Abre una vista previa si el entorno lo permite.

En esta captura el menú tapa el formulario a 390 px.
Localiza la regla CSS responsable y corrígela.
Verifica a 390 y 1280 px, con teclado y zoom al 200 %.

Abre la vista previa local. Busca "hooks", abre la ficha
y comprueba el enlace directo y el botón de copiar.
Repite en viewport móvil. Informa fallos observados.

Cada lunes a las 09:00, Europe/Madrid, revisa dependencias
de este proyecto en un worktree.
Informa actualizaciones relevantes y pruebas necesarias.
Notifica solo si hay cambios accionables.

Comprueba cada hora el estado del pipeline de la rama main.
Consulta el CI conectado. Avisa si pasa de correcto a fallido
o vuelve a estar correcto. Incluye ejecución y causa probable.

codex exec --sandbox read-only "Resume los últimos 10 commits para una release" -o release-notes.md

{
  "type": "object",
  "properties": {"summary": {"type": "string"}},
  "required": ["summary"],
  "additionalProperties": false
}

# Guarda el JSON anterior en schema.json. Después ejecuta:
codex exec "Resume este repositorio" --output-schema schema.json -o report.json