exis_ray 0.5.10 → 0.5.11

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 3ad15b3b5656e54690df31596233aabafaf70a5061b9086d6a601a60370fca16
-  data.tar.gz: 6d2d87410cb374c1f8c9ddee2b6caf730f959a6c87bc63004ef43e52a290d8c1
+  metadata.gz: 38ac0186226043d69ad60406f9aa32045a8d1192e223322735c76773a1fd41dd
+  data.tar.gz: 5a37831fc8b34237723ca0ab929c79d469fe316241d97b859272f25b8349e6b6
 SHA512:
-  metadata.gz: dd4d89629f65123d600cddf5dbca462b2bfcf50f9c4be9a40a87f9f4fc57949ff2ab5e6c5c65a0095040a99b63bca225a08c9a8d223b90231735049f6bb8f71a
-  data.tar.gz: 173790ac008fe33aa7b2aca4823dbe7bb94a5428e9628181bcde0325ed3260cc95f75a706751ee56829cca5778d211a386ae1654c83d0af737f401f3ed537501
+  metadata.gz: a7f0c1f2e1629f593fd3af2608678568fae5890cd2eb6ed19450364e2a353725dd730baa4cc665498695d0062147728b68d45f3f0485acce93a2e370a956442d
+  data.tar.gz: 84dc5252d489b2e28f5b9909d3928b49b8dfdc176019f4e2dcb066a7e25c1da460752625aca61b2be5c404c2eb7187da813de3fc34f02ba447a8e29902800129

data/.agents/skills/agent-review/SKILL.md

@@ -0,0 +1,213 @@
+---
+name: agent-review
+description: Review de código entre agentes AI via ClickUp. Úsala SIEMPRE que el usuario mencione "review", "crear review", "review para gemini/opencode/claude", "que revise gemini/opencode/claude", "tengo reviews pendientes", o quiera que otro agente revise el trabajo realizado. Crea tickets con checklist de revisores, permite agregar revisores, y guía el proceso de review. Requiere MCP de ClickUp.
+---
+
+# Agent Review
+
+Skill para crear y gestionar reviews de código entre agentes AI. Un agente trabaja, crea un ticket de review en ClickUp, y otros agentes lo revisan y dan feedback — todo trazable.
+
+## Configuración
+
+### MCP de ClickUp
+Requiere el MCP de ClickUp. Verificá que esté en `mcps:` del `skills.yml`:
+
+```yaml
+mcps:
+  - clickup
+```
+
+### Lista en ClickUp
+
+| Lista | ID | Uso |
+|---|---|---|
+| **Agent Reviews** | `901415149921` | Reviews de código entre agentes |
+
+## Flujos
+
+### 1. Crear review
+
+**Trigger:** El usuario dice "creá un review para Gemini" o "review para Gemini y OpenCode".
+
+#### Paso 1 — Recopilar contexto
+Analizá TODO el trabajo realizado en la sesión actual revisando estas 3 fuentes:
+1. **Commits sin pushear:** `git log @{u}..HEAD --oneline` (o desde el último tag si no hay upstream)
+2. **Cambios sin commitear:** `git diff` y `git diff --cached` (staged + unstaged)
+3. **Archivos nuevos:** `git status` para detectar archivos no trackeados
+
+Con base en ese análisis completo, armá el resumen para la descripción del ticket:
+- **Resumen de cambios:** qué se hizo y por qué
+- **Decisiones tomadas:** elecciones de diseño, trade-offs
+- **Cambios pendientes:** qué falta por hacer
+- **Dudas o riesgos:** puntos que merecen atención del revisor
+
+#### Paso 2 — Crear ticket
+Usá `clickup_create_task` en la lista Agent Reviews (`901415149921`):
+
+**Título:** `[proyecto] — descripción concreta de lo que se hizo`
+- Ejemplo: `[bug_bunny] Implementar reconexión con backoff exponencial`
+- Ejemplo: `[billing-api] Migrar endpoint de pagos a V2`
+- NO poner "review" en el título — ya se sabe por la lista.
+
+**Descripción:**
+
+El agente debe analizar los commits sin pushear, cambios sin commitear y archivos nuevos, **entender** qué se hizo, y **escribir** la descripción en sus propias palabras. No copiar output de git ni listar archivos mecánicamente. Referenciar archivos solo cuando aportan contexto puntual (ej: "Breaking change en `reconnect!` de `connection.rb:45`").
+
+```markdown
+**Proyecto:** [nombre]
+**Autor:** [Claude/Gemini/OpenCode]
+**Fecha:** [YYYY-MM-DD]
+**Revisores:** [lista de agentes que deben revisar]
+
+## Resumen
+[Qué se hizo y por qué — 2-3 líneas]
+
+## Qué se hizo
+[Descripción clara y detallada del trabajo realizado. Explicar la lógica,
+los componentes creados o modificados, y cómo encajan. Referenciar archivos
+solo cuando es relevante para entender un punto específico.]
+
+## Decisiones
+[Elecciones de diseño y justificación de cada una]
+
+## Pendiente
+[Qué falta por hacer o commitear, si corresponde]
+
+## Atención
+[Puntos que el revisor debería mirar con cuidado: breaking changes,
+riesgos, dependencias de test, etc.]
+
+## Checklist
+- [ ] [Agente revisor 1]
+- [ ] [Agente revisor 2]
+```
+
+#### Paso 3 — Agregar tags
+Con `clickup_add_tag_to_task`:
+- Tag del **proyecto** (ej: `bug_bunny`, `billing-api`)
+- Tag de cada **agente revisor** (ej: `gemini`, `opencode`). NO taguear al autor.
+
+#### Paso 4 — Confirmar
+Mostrá al usuario: "Review creado: [link]. Revisores: [lista]. Cuando levantes [agente], decile 'tengo reviews pendientes'."
+
+---
+
+### 2. Agregar revisor a review existente
+
+**Trigger:** El usuario dice "agregá a OpenCode al review".
+
+1. Buscar el ticket de review más reciente del proyecto actual en Agent Reviews (`901415149921`) por tag del proyecto.
+2. Agregar al revisor en el checklist (comentario con actualización).
+3. Agregar tag del nuevo agente.
+4. Confirmar: "OpenCode agregado como revisor a [link]."
+
+---
+
+### 3. Revisar
+
+**Trigger:** El usuario dice "tengo reviews pendientes" o "revisá los reviews".
+
+#### Paso 1 — Buscar reviews pendientes
+Buscar en Agent Reviews (`901415149921`) tickets abiertos donde este agente está como revisor sin marcar.
+
+#### Paso 2 — Leer el ticket
+Para cada review pendiente, mostrá un resumen al usuario:
+- Proyecto, agente autor, fecha
+- Resumen del trabajo
+- Puntos de atención
+
+#### Paso 3 — Revisar los cambios
+Analizá los cambios locales del proyecto:
+- Leer los archivos mencionados en el ticket
+- Verificar coherencia entre lo descrito y lo implementado
+- Evaluar decisiones de diseño
+- Identificar bugs potenciales, mejoras, o riesgos
+
+#### Paso 4 — Dar feedback
+Crear comentario en el ticket con `clickup_create_task_comment`:
+
+```
+## Review — [agente]
+**Desde:** [proyecto]
+**Agente:** [Claude/Gemini/OpenCode]
+**Fecha:** [YYYY-MM-DD]
+
+### Veredicto: [Aprobado / Aprobado con observaciones / Requiere cambios]
+
+### Observaciones
+[Feedback detallado punto por punto]
+
+### Sugerencias
+[Mejoras opcionales]
+
+### Issues encontrados
+[Bugs o problemas que necesitan atención]
+```
+
+#### Paso 5 — Marcar como revisado
+Actualizar el checklist marcando al agente como revisado. Si todos los revisores marcaron, informar al usuario que el review está completo.
+
+---
+
+### 4. Verificar y cerrar review (agente autor)
+
+**Trigger:** El usuario dice "revisá mi review", "cómo está mi review", "cerrá el review" al agente que creó el review original.
+
+#### Paso 1 — Buscar reviews creados por este agente
+Buscar en Agent Reviews (`901415149921`) tickets abiertos por tag del proyecto actual donde este agente es el autor.
+
+#### Paso 2 — Leer feedback de los revisores
+Leer los comentarios del ticket con `clickup_get_task_comments`. Para cada revisor:
+- ¿Comentó? ¿Marcó su check?
+- ¿Cuál fue su veredicto? (Aprobado / Aprobado con observaciones / Requiere cambios)
+- ¿Qué observaciones o issues encontró?
+
+#### Paso 3 — Mostrar resumen al usuario
+```
+Review: [título]
+Revisores:
+  ✅ [Agente A] — Aprobado con observaciones: [resumen]
+  ✅ [Agente B] — Aprobado: [resumen]
+  ⬜ [Agente C] — Pendiente
+
+Estado: Todos revisaron / Falta [agente]
+```
+
+#### Paso 4 — Cerrar si corresponde
+- Si **todos** revisaron y **ninguno** pidió "Requiere cambios": cerrar el ticket con `clickup_update_task` (status → **done**).
+- Si algún revisor pidió **"Requiere cambios"**: informar al usuario qué cambios piden y NO cerrar.
+- Si **faltan revisores**: informar quién falta y NO cerrar.
+
+---
+
+## Nota sobre agentes
+
+Esta skill funciona con **cualquier agente AI** que tenga acceso al MCP de ClickUp (Claude Code, Gemini CLI, OpenCode, o cualquier otro). Los nombres de agentes en los ejemplos son ilustrativos — el flujo es el mismo independientemente de qué agentes se usen como autor o revisores.
+
+---
+
+## Ejemplo de flujo completo
+
+```
+1. Usuario trabaja con Agente A en bug_bunny
+   → Agente A implementa reconexión con backoff exponencial
+
+2. Usuario: "creá un review para Agente B y Agente C"
+   → Agente A crea ticket en ClickUp con resumen, decisiones, checklist
+
+3. Usuario abre Agente B en el repo de bug_bunny
+   Usuario: "tengo reviews pendientes"
+   → Agente B busca en ClickUp, encuentra el ticket
+   → Agente B revisa los cambios, comenta feedback, marca su check
+
+4. Usuario abre Agente C en el repo
+   Usuario: "revisá los reviews"
+   → Agente C lee ticket + review de Agente B
+   → Agente C comenta feedback, marca su check
+
+5. Usuario vuelve a Agente A
+   Usuario: "revisá mi review"
+   → Agente A lee los comentarios de los revisores
+   → Agente A muestra resumen de veredictos
+   → Si todos aprobaron, cierra el ticket
+```

data/.agents/skills/ai-reports/SKILL.md

@@ -0,0 +1,211 @@
+---
+name: ai-reports
+description: Gestiona reportes generados por agentes AI en el espacio ai_knowledge de ClickUp. Úsala cuando detectes un bug en una dependencia, quieras sugerir una mejora, o necesites registrar un TODO. Requiere MCP de ClickUp.
+---
+
+# AI Reports
+
+Skill para reportar bugs, mejoras y TODOs desde cualquier proyecto del ecosistema al espacio `ai_knowledge` de ClickUp. Usá esta skill cuando un agente detecte un problema con una dependencia, identifique una oportunidad de mejora, o necesite registrar una tarea.
+
+## Configuración
+
+### MCP de ClickUp
+Esta skill requiere el MCP de ClickUp. Verificá que esté en `mcps:` del `skills.yml`:
+
+```yaml
+mcps:
+  - clickup
+```
+
+Si el MCP no está disponible, generá un archivo local como fallback (ver sección Fallback).
+
+### Espacio y Listas
+
+| Lista | ID | Uso |
+|---|---|---|
+| **Bug Reports** | `901415148810` | Bugs detectados en gemas o servicios del ecosistema. |
+| **Improvements** | `901415148812` | Sugerencias de mejora para skills, gemas o servicios. |
+
+## Alcance — Solo dependencias propias
+
+**Regla:** Solo reportar bugs e improvements para gemas, servicios y skills que están bajo nuestro control — es decir, declaradas en el `skills.yml` del proyecto actual (`gems:`, `services:` o `skills:`).
+
+Si el problema es en una dependencia externa (ej: `rails`, `redis`, `sidekiq`), **no crear reporte**. Informar al usuario que el problema está fuera de nuestro control y sugerirle que abra un issue en el repo del mantenedor.
+
+## Cuándo reportar
+
+### Bug Report
+Cuando el agente detecta un problema en una dependencia **propia** (declarada en `skills.yml`):
+- Un método no se comporta como dice la skill/documentación
+- Un error se repite en Sentry y el origen es una dependencia propia
+- Un test falla por un bug en una gema interna
+- Incompatibilidad entre versiones de dependencias propias
+
+### Improvement
+Cuando el agente identifica una oportunidad de mejora en algo **propio**:
+- Una skill podría cubrir un caso que no contempla
+- Un patrón de código se repite en varios servicios y podría extraerse
+- La documentación de una gema propia es insuficiente o incorrecta
+- Un flujo podría automatizarse
+
+
+## Flujo de reporte
+
+### Paso 1 — Preguntar destino
+Preguntá al usuario: "¿Querés reportarlo en ClickUp o generar un archivo local?"
+
+### Paso 2 — Clasificar
+Determiná el tipo de reporte:
+- **Bug** → lista Bug Reports (`901415148810`)
+- **Improvement** → lista Improvements (`901415148812`)
+
+### Paso 3 — Generar contenido
+
+#### Template de Bug Report
+```
+Título: [gema/servicio] — descripción breve del problema
+
+Descripción:
+## Contexto
+- **Reportado desde:** [nombre del proyecto actual]
+- **Versión del proyecto:** [versión actual]
+- **Versión de la dependencia:** [versión de la gema/servicio afectado]
+
+## Problema
+[Descripción clara del bug]
+
+## Reproducción
+[Pasos o código para reproducir]
+
+## Stacktrace
+[Si hay stacktrace relevante]
+
+## Impacto
+[Frecuencia, severidad, usuarios afectados]
+
+## Sugerencia
+[Si el agente tiene una hipótesis de la causa o solución]
+```
+
+#### Template de Improvement
+```
+Título: [gema/servicio/skill] — descripción breve de la mejora
+
+Descripción:
+## Contexto
+- **Detectado en:** [nombre del proyecto actual]
+
+## Situación actual
+[Qué pasa hoy]
+
+## Mejora propuesta
+[Qué debería pasar]
+
+## Beneficio
+[Por qué vale la pena]
+```
+
+### Paso 4 — Crear el reporte
+
+**Con MCP de ClickUp:**
+Usá `clickup_create_task` con:
+- `list_id` según el tipo de reporte
+- `name` del template
+- `description` del template
+- `priority` según severidad (bug crítico → urgent, mejora → normal)
+
+Después de crear el task, agregar **tags** con `clickup_add_tag_to_task`:
+- **Tipo:** `gem` o `service` (según la dependencia afectada)
+- **Nombre:** el nombre de la gema o servicio (ej: `bug_bunny`, `billing-api`)
+
+Esto permite filtrar en ClickUp:
+- Todos los bugs de gemas → tag `gem`
+- Bugs de una gema específica → tag `bug_bunny`
+- Todos los bugs de servicios → tag `service`
+- Bugs de un servicio específico → tag `billing-api`
+
+**Mostrar link del task creado al usuario.**
+
+### Paso 5 — Confirmar
+Mostrá un resumen: "Task creado en ClickUp: [link]. Lista: [nombre]. Tags: [tipo, nombre]. Prioridad: [prioridad]."
+
+---
+
+## Cerrar reportes resueltos
+
+Cuando el agente está en el repo de una gema o servicio y resuelve un bug que tiene un ticket en ClickUp:
+
+### Paso 1 — Buscar tickets abiertos
+Usá `clickup_search` o `clickup_filter_tasks` para buscar en Bug Reports (`901415148810`) por el tag de la gema/servicio actual.
+
+### Paso 2 — Identificar el ticket
+Si el fix matchea con un reporte abierto (por descripción, error, o referencia), mostrá el ticket al usuario y preguntá: "¿Este fix resuelve el ticket [título] ([link])?"
+
+### Paso 3 — Cerrar
+Con confirmación del usuario, usá `clickup_update_task` para:
+- Cambiar status a **done** o **closed**
+- Agregar un comentario con `clickup_create_task_comment`: "Resuelto en [proyecto] v[versión]. Commit: [hash]."
+
+---
+
+## Conversación entre agentes via comentarios
+
+Los tickets funcionan como hilo de comunicación asíncrona entre el servicio que reportó y la gema/servicio afectado.
+
+### Leer comentarios pendientes
+Cuando el agente entra a un repo, puede verificar si hay tickets con actividad nueva:
+
+1. Buscar tickets abiertos en Bug Reports (`901415148810`) e Improvements (`901415148812`) con el tag de la gema/servicio actual.
+2. Para cada ticket, leer comentarios con `clickup_get_task_comments`.
+3. Si hay comentarios nuevos (preguntas, pedidos de info), mostrá un resumen al usuario: "Hay [N] tickets con actividad nueva para [nombre]."
+
+### Responder a un comentario
+Cuando el agente tiene información que aportar a un ticket:
+
+1. Usá `clickup_create_task_comment` para agregar la respuesta.
+2. Identificá el contexto: desde qué proyecto se responde, qué se investigó, qué se encontró.
+
+Ejemplo de flujo:
+```
+1. billing-api reporta: "bug_bunny: reconexión falla después de timeout"
+2. bug_bunny lee, comenta: "¿Qué versión de RabbitMQ? ¿SSL habilitado?"
+3. billing-api lee, responde: "RabbitMQ 3.12, SSL on, timeout 30s"
+4. bug_bunny comenta: "Bug en connection.rb:45. Fix en v4.9.1"
+5. bug_bunny cierra el ticket
+```
+
+### Formato de comentarios
+```
+**Desde:** [nombre del proyecto] v[versión]
+**Agente:** [Claude/Gemini/OpenCode]
+
+[Contenido del comentario]
+```
+
+---
+
+## Fallback — Archivo local
+
+Si el MCP de ClickUp no está disponible, generá un archivo local:
+
+```
+.reports/
+  2026-04-04-bug-bug_bunny-reconnect.md
+  2026-04-04-improvement-sentry-skill-pagination.md
+  2026-04-04-todo-investigar-redis-timeout.md
+```
+
+Formato del nombre: `YYYY-MM-DD-[tipo]-[descripción-breve].md`
+
+El contenido usa los mismos templates. Estos archivos se pueden subir a ClickUp después manualmente o en el próximo sync.
+
+## Integración con otras skills
+
+Las siguientes skills pueden invocar `ai-reports` cuando detectan algo reportable:
+
+- **`quality-code`** — Si detecta un patrón problemático recurrente en una dependencia.
+- **`sentry`** — Si un error apunta a un bug en una gema interna.
+- **`skill-builder`** — Si al analizar el código encuentra antipatrones o documentación faltante en dependencias.
+- **`gem-release` / `service-release`** — Si durante el release se detectan issues que no bloquean pero deberían registrarse.
+
+En todos los casos, la skill pregunta al usuario antes de crear el reporte.

data/.agents/skills/documentation-writer/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: documentation-writer
+description: 'Diátaxis Documentation Expert. An expert technical writer specializing in creating high-quality software documentation, guided by the principles and structure of the Diátaxis technical documentation authoring framework.'
+---
+
+# Diátaxis Documentation Expert
+
+You are an expert technical writer specializing in creating high-quality software documentation.
+Your work is strictly guided by the principles and structure of the Diátaxis Framework (https://diataxis.fr/).
+
+## GUIDING PRINCIPLES
+
+1. **Clarity:** Write in simple, clear, and unambiguous language.
+2. **Accuracy:** Ensure all information, especially code snippets and technical details, is correct and up-to-date.
+3. **User-Centricity:** Always prioritize the user's goal. Every document must help a specific user achieve a specific task.
+4. **Consistency:** Maintain a consistent tone, terminology, and style across all documentation.
+
+## YOUR TASK: The Four Document Types
+
+You will create documentation across the four Diátaxis quadrants. You must understand the distinct purpose of each:
+
+- **Tutorials:** Learning-oriented, practical steps to guide a newcomer to a successful outcome. A lesson.
+- **How-to Guides:** Problem-oriented, steps to solve a specific problem. A recipe.
+- **Reference:** Information-oriented, technical descriptions of machinery. A dictionary.
+- **Explanation:** Understanding-oriented, clarifying a particular topic. A discussion.
+
+## WORKFLOW
+
+You will follow this process for every documentation request:
+
+1. **Acknowledge & Clarify:** Acknowledge my request and ask clarifying questions to fill any gaps in the information I provide. You MUST determine the following before proceeding:
+    - **Document Type:** (Tutorial, How-to, Reference, or Explanation)
+    - **Target Audience:** (e.g., novice developers, experienced sysadmins, non-technical users)
+    - **User's Goal:** What does the user want to achieve by reading this document?
+    - **Scope:** What specific topics should be included and, importantly, excluded?
+
+2. **Propose a Structure:** Based on the clarified information, propose a detailed outline (e.g., a table of contents with brief descriptions) for the document. Await my approval before writing the full content.
+
+3. **Generate Content:** Once I approve the outline, write the full documentation in well-formatted Markdown. Adhere to all guiding principles.
+
+## CONTEXTUAL AWARENESS
+
+- When I provide other markdown files, use them as context to understand the project's existing tone, style, and terminology.
+- DO NOT copy content from them unless I explicitly ask you to.
+- You may not consult external websites or other sources unless I provide a link and instruct you to do so.

data/.agents/skills/gem-release/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: gem-release
+description: Automatiza el proceso de liberación (release) de gemas Ruby siguiendo estándares de industria. Úsala cuando necesites subir una nueva versión a RubyGems. Ejecuta quality-code, propone versión, genera CHANGELOG, regenera la skill y publica. Soporta [patch|minor|major].
+---
+
+# Gem Release Expert
+
+Sos el responsable de garantizar que el proceso de publicación de una gema sea seguro, pase todos los controles de calidad y tenga documentación de clase mundial.
+
+## Parámetros de Uso
+- `/gem-release` — El agente analiza los cambios y propone el tipo de bump.
+- `/gem-release patch|minor|major` — Override manual del tipo de bump.
+
+## Flujo de Trabajo Obligatorio
+
+### Paso 1 — Quality Code
+Ejecutá `quality-code` para validar linting, tests, YARD incremental y skill.
+
+### Paso 2 — Propuesta de Versión
+No asumas rutas fijas. Investigá el entorno:
+- Detectá el nombre de la gema del `.gemspec`.
+- Localizá el archivo de versión (`lib/**/version.rb`).
+- Leé la versión actual.
+- **Análisis de cambios:** Revisá **todas** las fuentes de cambios:
+  1. Commits desde el último tag: `git log [último-tag]...HEAD`
+  2. Diff commiteado contra el tag: `git diff [último-tag]...HEAD`
+  3. Cambios sin commitear (staged + unstaged): `git status` y `git diff` / `git diff --cached`
+  
+  **Importante:** Los cambios sin commitear son parte del release.
+  
+  Clasificá todos los cambios en conjunto:
+  - **major** — Breaking changes: métodos/clases eliminados o renombrados, cambios en firmas de métodos públicos, cambios incompatibles en comportamiento.
+  - **minor** — Nuevas funcionalidades: métodos/clases nuevos, nuevas opciones de configuración, funcionalidad extendida sin romper compatibilidad.
+  - **patch** — Bugfixes, mejoras de performance, refactors internos sin cambios en la API pública.
+- **Propuesta:** Mostrá un resumen de los cambios, la clasificación y la versión propuesta (Actual → Nueva). Esperá confirmación.
+- Si el usuario pasó un override (`/gem-release major`), usá ese tipo directamente.
+
+### Paso 3 — Documentación y Skill
+1. **Skill Experta:** Ejecutá `skill-builder` en modo **completo** para regenerar `skill/SKILL.md` (y `references/`, `scripts/` si aplica) con la API actualizada de la nueva versión.
+2. **Gemspec — Empaquetado de la Skill:** Ejecutá `/skill-manager check` para validar que el gemspec esté en orden. Verificá que `skill/` esté incluido en `spec.files`.
+   - Si `spec.files` usa `git ls-files`, asegurate de que `skill/` esté commiteado.
+   - Si `spec.files` usa un glob explícito, asegurate de que incluya `skill/**/*`.
+   - Asegurá la presencia de `metadata["documentation_uri"]` apuntando a `skill/`.
+
+### Paso 4 — Aplicación del Release
+1. Actualizá el archivo `version.rb` con la Nueva Versión.
+2. **Generar entrada de CHANGELOG** (ver sección "Generación de CHANGELOG" abajo).
+3. **Persistencia Git:**
+   - `git add .`
+   - `git commit -m "release: v[NUEVA_VERSION]"`
+   - `git tag -a v[NUEVA_VERSION] -m "Version [NUEVA_VERSION]"`
+
+### Paso 5 — Push (Requiere confirmación)
+Mostrá un resumen del commit y el tag creados. Esperá confirmación explícita antes de pushear.
+- `git push origin main`
+- `git push origin v[NUEVA_VERSION]`
+
+**Nota:** No es necesario hacer `gem build` ni `gem push` manualmente. Un GitHub Action se encarga de buildear y publicar la gema en RubyGems cuando detecta el tag.
+
+---
+
+## Generación de CHANGELOG
+
+### Fuente de datos
+Leer todos los commits desde el último tag: `git log [último-tag]...HEAD --format="%H %s (%an)"`
+
+### Filtrado
+Ignorar commits que matcheen:
+- `release:` — commits de release anteriores
+- `Merge branch` / `Merge pull request` — merges automáticos
+- `chore:` — tareas de mantenimiento sin impacto funcional
+
+### Agrupación por tipo
+Clasificar cada commit por su prefijo conventional commit:
+
+```markdown
+## [X.X.X] — YYYY-MM-DD
+
+### Nuevas funcionalidades
+- Agregar endpoint de facturación (#123) — @dev1
+- Soportar filtro por fecha en listado — @dev2
+
+### Correcciones
+- Corregir cálculo de IVA en pagos parciales — @dev1
+- Resolver timeout en conexión a Redis — @dev3
+
+### Mejoras internas
+- Extraer servicio de notificaciones — @dev2
+- Optimizar queries de reportes — @dev1
+```
+
+**Mapeo de prefijos:**
+- `feat:` → **Nuevas funcionalidades**
+- `fix:` → **Correcciones**
+- `refactor:`, `perf:`, `style:` → **Mejoras internas**
+- `docs:` → **Documentación**
+- `test:` → **Tests**
+- Sin prefijo reconocido → **Otros cambios**
+
+### Formato
+- Cada entrada: descripción limpia (sin el prefijo), PR o issue si está en el mensaje, autor (`@nombre`).
+- Fecha en formato `YYYY-MM-DD`.
+- Si el `CHANGELOG.md` no existe, crearlo con header `# Changelog`.
+- La entrada nueva va al tope del archivo, debajo del header.
+
+### Atribución
+Extraer el autor de cada commit con `git log --format="%an"`. Esto permite saber qué dev contribuyó a cada cambio en el release.
+
+---
+
+## Reglas de Seguridad y Estilo
+- **Tag con `v`:** Los tags de gemas usan formato `vX.X.X`.
+- **Stop on Failure:** Si quality-code falla, detenete. No fuerces el release.
+- **Confirmation:** Siempre esperá confirmación antes de persistir cambios en Git y publicar.
+- **Sin Hardcoding:** No uses versiones de Ruby o rutas específicas. Confiá en el entorno configurado.
+- **CHANGELOG is Law:** Todo release debe tener su entrada en CHANGELOG.md.

data/.agents/skills/quality-code/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: quality-code
+description: Validación de calidad para proyectos Ruby (gemas y servicios). Ejecuta RuboCop, tests, YARD incremental y actualiza la skill del proyecto. Invocala manualmente en cualquier momento o dejá que `gem-release` y `service-release` la ejecuten como primer paso.
+---
+
+# Quality Code
+
+Barrera de calidad para proyectos Ruby. Valida que el código cumpla los estándares antes de mergear, hacer release o en cualquier momento que quieras verificar el estado de tu branch.
+
+## Detección de tipo de proyecto
+
+- **Gema**: existe `.gemspec` en la raíz.
+- **Servicio**: existe `config/application.rb`.
+
+## Flujo de Trabajo
+
+### Paso 1 — Linting
+- Ejecutá `bundle exec rubocop -a` (o `-A`) para corregir ofensas automáticas.
+- Si quedan ofensas que no se pueden auto-corregir, reportalas y detenete.
+
+### Paso 2 — Tests
+- Ejecutá `bundle exec rspec` (o el test runner detectado).
+- Si un test falla, el proceso se detiene inmediatamente.
+
+### Paso 3 — Base de Datos (solo servicios)
+- Verificá si hay migraciones en `db/migrate/`.
+- Asegurate de que `db/schema.rb` esté actualizado y consistente.
+
+### Paso 4 — Auditoría YARD Incremental (Boy Scout Rule)
+Solo documentá lo que cambió:
+- Analizá `git diff [PRIMARY_BRANCH]...HEAD` para detectar métodos públicos o protegidos nuevos o modificados.
+- **Importante:** También revisá cambios sin commitear (`git status`, `git diff`, `git diff --cached`).
+- Todo método afectado DEBE tener documentación YARD completa (`@param`, `@return`, `@yield` si aplica).
+- Si falta documentación en métodos tocados, generala basándote en la lógica del código.
+
+### Paso 5 — Sincronización de Skill
+- Ejecutá `skill-builder` en modo **incremental** para actualizar `skill/SKILL.md` (y `references/`, `scripts/` si aplica) con los cambios actuales.
+- Auditá si el `README.md` necesita actualizarse por los cambios.
+
+### Paso 6 — Reporte
+Mostrá un resumen de lo ejecutado:
+- RuboCop: OK / X ofensas corregidas
+- Tests: OK / X tests, X failures
+- YARD: OK / X métodos documentados
+- Skill: actualizada / sin cambios
+- README: actualizado / sin cambios
+
+## Reglas
+- **Stop on Failure:** Si los tests o el linting fallan, detenete. No continues con los pasos siguientes.
+- **Sin Hardcoding:** No uses versiones de Ruby o rutas específicas. Confiá en el entorno configurado.
+- **Explain the Why:** Si sugerís cambios en documentación, explicá cómo mejora la mantenibilidad.