bug_bunny 4.7.0 → 4.8.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: b3b2260d4ec9ac9684adce0a4ea1c8ab7d86508a601eba51e630438ba5c36059
-  data.tar.gz: c8a41ed643ba5293babfe946476fce1c022137916dfe534224159574928e8b08
+  metadata.gz: 35c04cd113b0a3056cab1dcfda6d389fa996e13bb44992d4791bdef29b93fc7d
+  data.tar.gz: aa7d145fb3eb1d80f435c0541e1009df78a636019e6c6452be0e0a0515b1f1a8
 SHA512:
-  metadata.gz: 6e8ef4dc6d1e9fc6aa4ac067da0aa48ccf5a291c91cb2c8474ed5811e34a57cbbeb44b9b6a813de8d5158a3351a96c15513c1e0715adf5a47e12ef70681935d4
-  data.tar.gz: a036a4e0a8c8b8fc29286f5490be2c506561951167c765461ef668b79c77dfcf0bb8e7f2020df28847820875697008129f24e4a97f34079cb54d5202a6e36d65
+  metadata.gz: 9efee5f3deb6a52c76a361230032e040c964e22a1b52a2419873cb3d1c06159a1c52a042f424974a697a591342e8116aea1e39dd57e0bf71aa617ed5245e0860
+  data.tar.gz: 1f569f9e8b6fdfa2b48dd2270494a9a6b8f8aec2539ebadec5e20bc27f3ccd23407a340891b15c1567fe48ce593ee45a694b843987e5078852bb14d94ad37d70

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,114 @@
+---
+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 — Publicación (Requiere confirmación final)
+- Construí la gema: `gem build [nombre].gemspec`
+- Empujá a RubyGems: `gem push [nombre]-[NUEVA_VERSION].gem`
+- Eliminá el artefacto `.gem` local después de subirlo.
+
+---
+
+## 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.