trackops 2.0.4 → 2.0.5

package/templates/skills/changelog-updater/SKILL.md

@@ -1,69 +1,69 @@
----
-name: "changelog-updater"
-description: "Herramienta automatizada para actualizar el archivo CHANGELOG.md basándose en el último commit realizado. Usa esta skill inmediatamente después de confirmar un commit para mantener el historial de cambios al día. Se activa con 'actualizar changelog', 'registrar cambio', 'update changelog', o automáticamente tras un commit exitoso cuando el router lo indique."
-metadata:
-  version: "1.0"
-  type: "project"
-  triggers:
-    - "actualizar changelog"
-    - "registrar cambio"
-    - "update changelog"
-    - "post-commit"
----
-
-# Actualizador de Changelog
-
-Esta skill mantiene actualizado el archivo `CHANGELOG.md` del proyecto de forma automática, leyendo la información directamente desde el historial de git.
-
-## Cuándo Usar
-
-Usa esta skill **inmediatamente después de realizar un commit** exitoso. El router debería activarla automáticamente tras detectar un commit, pero también puede invocarse manualmente.
-
-## Qué Hace
-
-1. Obtiene el último commit del repositorio via `git log`.
-2. Analiza el mensaje buscando el patrón de **Conventional Commits** (con soporte para emojis al inicio).
-3. Formatea una nueva entrada para `CHANGELOG.md` incluyendo:
-   - Emoji correspondiente al tipo de cambio.
-   - Ámbito (scope) si existe.
-   - Descripción del cambio.
-   - Hash corto del commit (7 caracteres).
-4. Inserta la entrada en la sección correspondiente a la fecha actual (`YYYY-MM-DD`).
-5. Si no existe `CHANGELOG.md`, lo crea con la estructura base.
-
-## Mapeo de Emojis
-
-El script reconoce estos tipos de commit y asigna sus emojis:
-
-| Tipo | Emoji | Descripción |
-| :--- | :---: | :--- |
-| `feat` | ✨ | Nueva característica |
-| `fix` | 🐛 | Corrección de errores |
-| `docs` | 📚 | Documentación |
-| `style` | 💄 | Estilos y formato |
-| `refactor` | ♻️ | Refactorización de código |
-| `perf` | ⚡ | Mejoras de rendimiento |
-| `test` | ✅ | Tests |
-| `build` | 📦 | Build y dependencias |
-| `ci` | 👷 | Integración continua |
-| `chore` | 🔧 | Tareas de mantenimiento |
-| `revert` | ⏪ | Reversión de cambios |
-
-Commits que no sigan el formato Conventional Commits se registran como "Misc".
-
-## Flujo de Trabajo Recomendado
-
-1. Realiza tus cambios en el código.
-2. Haz el commit siguiendo las convenciones (usa la skill `commiter`).
-3. Actualiza el changelog manualmente o via script si está configurado.
-
-## Requisitos
-
-- Repositorio git inicializado con al menos un commit.
-- El script se ejecuta desde la raíz del proyecto.
-
-## Manejo de Errores
-
-- Si no hay commits en el repo, el script muestra un mensaje informativo y no modifica nada.
-- Si `git` no está disponible, el script reporta el error y termina.
-- Si el `CHANGELOG.md` tiene una estructura inesperada, añade la entrada al final como fallback.
+---
+name: "changelog-updater"
+description: "Herramienta automatizada para actualizar el archivo CHANGELOG.md basándose en el último commit realizado. Usa esta skill inmediatamente después de confirmar un commit para mantener el historial de cambios al día. Se activa con 'actualizar changelog', 'registrar cambio', 'update changelog', o automáticamente tras un commit exitoso cuando el router lo indique."
+metadata:
+  version: "1.0"
+  type: "project"
+  triggers:
+    - "actualizar changelog"
+    - "registrar cambio"
+    - "update changelog"
+    - "post-commit"
+---
+
+# Actualizador de Changelog
+
+Esta skill mantiene actualizado el archivo `CHANGELOG.md` del proyecto de forma automática, leyendo la información directamente desde el historial de git.
+
+## Cuándo Usar
+
+Usa esta skill **inmediatamente después de realizar un commit** exitoso. El router debería activarla automáticamente tras detectar un commit, pero también puede invocarse manualmente.
+
+## Qué Hace
+
+1. Obtiene el último commit del repositorio via `git log`.
+2. Analiza el mensaje buscando el patrón de **Conventional Commits** (con soporte para emojis al inicio).
+3. Formatea una nueva entrada para `CHANGELOG.md` incluyendo:
+   - Emoji correspondiente al tipo de cambio.
+   - Ámbito (scope) si existe.
+   - Descripción del cambio.
+   - Hash corto del commit (7 caracteres).
+4. Inserta la entrada en la sección correspondiente a la fecha actual (`YYYY-MM-DD`).
+5. Si no existe `CHANGELOG.md`, lo crea con la estructura base.
+
+## Mapeo de Emojis
+
+El script reconoce estos tipos de commit y asigna sus emojis:
+
+| Tipo | Emoji | Descripción |
+| :--- | :---: | :--- |
+| `feat` | ✨ | Nueva característica |
+| `fix` | 🐛 | Corrección de errores |
+| `docs` | 📚 | Documentación |
+| `style` | 💄 | Estilos y formato |
+| `refactor` | ♻️ | Refactorización de código |
+| `perf` | ⚡ | Mejoras de rendimiento |
+| `test` | ✅ | Tests |
+| `build` | 📦 | Build y dependencias |
+| `ci` | 👷 | Integración continua |
+| `chore` | 🔧 | Tareas de mantenimiento |
+| `revert` | ⏪ | Reversión de cambios |
+
+Commits que no sigan el formato Conventional Commits se registran como "Misc".
+
+## Flujo de Trabajo Recomendado
+
+1. Realiza tus cambios en el código.
+2. Haz el commit siguiendo las convenciones (usa la skill `commiter`).
+3. Actualiza el changelog manualmente o via script si está configurado.
+
+## Requisitos
+
+- Repositorio git inicializado con al menos un commit.
+- El script se ejecuta desde la raíz del proyecto.
+
+## Manejo de Errores
+
+- Si no hay commits en el repo, el script muestra un mensaje informativo y no modifica nada.
+- Si `git` no está disponible, el script reporta el error y termina.
+- Si el `CHANGELOG.md` tiene una estructura inesperada, añade la entrada al final como fallback.

package/templates/skills/commiter/SKILL.md

@@ -1,99 +1,99 @@
----
-name: "commiter"
-description: "Guía para generar mensajes de commit en español siguiendo Conventional Commits estrictos con Emojis. Usa esta skill siempre que el usuario pida hacer un commit, generar un mensaje de commit, commitear cambios, o cuando se complete un cambio de código y sea momento de registrarlo en git. También se activa con 'commit', 'commitear', 'guardar cambios', 'registrar cambios' o cualquier intención de crear un punto en el historial de git."
-metadata:
-  version: "1.0"
-  type: "project"
-  triggers:
-    - "commit"
-    - "commitear"
-    - "guardar cambios"
-    - "registrar cambios"
-    - "hacer commit"
-    - "git commit"
----
-
-# Generador de Commits
-
-Cuando se te pida realizar un commit o generar un mensaje de commit, DEBES seguir estrictamente este formato.
-
-## Estándar: Conventional Commits con Emojis
-
-Utilizamos **Conventional Commits** enriquecidos con **Gitmoji** como base. Todo el contenido debe estar en **ESPAÑOL**.
-
-## Formato
-
-```text
-<emoji> <tipo>(<alcance>): <descripción corta>
-
-<cuerpo detallado y extenso>
-
-<footer>
-```
-
-## Reglas Obligatorias
-
-1. **Emoji**: El mensaje DEBE comenzar con el emoji correspondiente al tipo de cambio.
-2. **Idioma**: Todo el contenido del commit (descripción y cuerpo) debe estar en **ESPAÑOL**.
-3. **Límite del Título**: La primera línea (asunto) **NO debe exceder los 50 caracteres** (sin contar el emoji). Sé conciso.
-4. **Descripción Extensa**: El cuerpo del mensaje es **OBLIGATORIO**. Debes explicar detalladamente:
-   - **Qué** se ha cambiado.
-   - **Por qué** se ha hecho el cambio.
-   - Detalles técnicos relevantes de la implementación.
-5. **Tiempos Verbales**: Usa el modo imperativo en el asunto (ej: "agrega", "corrige", "cambia"), no en pasado.
-
-## Tipos Permitidos y Emojis
-
-| Emoji | Tipo | Descripción |
-| :---: | :--- | :--- |
-| ✨ | `feat` | Nueva característica (correlaciona con MINOR en SemVer). |
-| 🐛 | `fix` | Corrección de un bug (correlaciona con PATCH en SemVer). |
-| 📚 | `docs` | Cambios en la documentación. |
-| 💄 | `style` | Cambios que no afectan el significado del código (espacios, formato, etc). |
-| ♻️ | `refactor` | Cambio de código que no corrige bugs ni añade funcionalidades. |
-| ⚡ | `perf` | Cambio de código que mejora el rendimiento. |
-| ✅ | `test` | Añadir tests faltantes o corregir existentes. |
-| 📦 | `build` | Cambios que afectan el sistema de construcción o dependencias externas. |
-| 👷 | `ci` | Cambios en archivos de configuración y scripts de CI. |
-| 🔧 | `chore` | Otros cambios que no modifican src o test files (ej. config de herramientas). |
-| ⏪ | `revert` | Reversión de un commit anterior. |
-
-## Procedimiento
-
-Cuando el usuario pida hacer commit:
-
-1. **Analiza los cambios**: Revisa qué archivos se modificaron y qué tipo de cambio representan.
-2. **Selecciona el tipo**: Elige el tipo de commit más apropiado de la tabla.
-3. **Define el alcance**: Identifica el módulo o componente afectado (opcional pero recomendado).
-4. **Redacta el asunto**: Máximo 50 caracteres, imperativo, en español.
-5. **Redacta el cuerpo**: Explica qué, por qué y detalles técnicos. Es obligatorio.
-6. **Ejecuta el commit**: Usa `git commit -m` con el formato completo.
-
-## Ejemplo Correcto
-
-```text
-✨ feat(auth): integra login social con Google
-
-Se ha implementado la autenticación mediante OAuth2 con Google para facilitar
-el acceso a nuevos usuarios.
-
-Cambios principales:
-- Agrega configuración de estrategia de Passport.js para Google.
-- Crea nuevas rutas de callback en el controlador de autenticación.
-- Actualiza el modelo de Usuario para almacenar el providerId.
-- Ajusta la interfaz de login para incluir el botón de "Entrar con Google".
-
-Motivación:
-Reducir la fricción en el registro de usuarios y aumentar la conversión.
-```
-
-## Errores Comunes a Evitar
-
-- `fix: error login` → Falta emoji, título vago, sin cuerpo.
-- `🐛 Fix: arregla login` → Tipo en mayúscula, lo correcto es minúscula `fix`.
-- `✨ feat(user): Update user logic` → En inglés, debe ser en español.
-- Título que excede 50 caracteres → Acorta y mueve el detalle al cuerpo.
-
-## Integración con el Workflow
-
-Después de ejecutar un commit exitoso, el router debe activar la skill `changelog-updater` para registrar el cambio automáticamente en `CHANGELOG.md`.
+---
+name: "commiter"
+description: "Guía para generar mensajes de commit en español siguiendo Conventional Commits estrictos con Emojis. Usa esta skill siempre que el usuario pida hacer un commit, generar un mensaje de commit, commitear cambios, o cuando se complete un cambio de código y sea momento de registrarlo en git. También se activa con 'commit', 'commitear', 'guardar cambios', 'registrar cambios' o cualquier intención de crear un punto en el historial de git."
+metadata:
+  version: "1.0"
+  type: "project"
+  triggers:
+    - "commit"
+    - "commitear"
+    - "guardar cambios"
+    - "registrar cambios"
+    - "hacer commit"
+    - "git commit"
+---
+
+# Generador de Commits
+
+Cuando se te pida realizar un commit o generar un mensaje de commit, DEBES seguir estrictamente este formato.
+
+## Estándar: Conventional Commits con Emojis
+
+Utilizamos **Conventional Commits** enriquecidos con **Gitmoji** como base. Todo el contenido debe estar en **ESPAÑOL**.
+
+## Formato
+
+```text
+<emoji> <tipo>(<alcance>): <descripción corta>
+
+<cuerpo detallado y extenso>
+
+<footer>
+```
+
+## Reglas Obligatorias
+
+1. **Emoji**: El mensaje DEBE comenzar con el emoji correspondiente al tipo de cambio.
+2. **Idioma**: Todo el contenido del commit (descripción y cuerpo) debe estar en **ESPAÑOL**.
+3. **Límite del Título**: La primera línea (asunto) **NO debe exceder los 50 caracteres** (sin contar el emoji). Sé conciso.
+4. **Descripción Extensa**: El cuerpo del mensaje es **OBLIGATORIO**. Debes explicar detalladamente:
+   - **Qué** se ha cambiado.
+   - **Por qué** se ha hecho el cambio.
+   - Detalles técnicos relevantes de la implementación.
+5. **Tiempos Verbales**: Usa el modo imperativo en el asunto (ej: "agrega", "corrige", "cambia"), no en pasado.
+
+## Tipos Permitidos y Emojis
+
+| Emoji | Tipo | Descripción |
+| :---: | :--- | :--- |
+| ✨ | `feat` | Nueva característica (correlaciona con MINOR en SemVer). |
+| 🐛 | `fix` | Corrección de un bug (correlaciona con PATCH en SemVer). |
+| 📚 | `docs` | Cambios en la documentación. |
+| 💄 | `style` | Cambios que no afectan el significado del código (espacios, formato, etc). |
+| ♻️ | `refactor` | Cambio de código que no corrige bugs ni añade funcionalidades. |
+| ⚡ | `perf` | Cambio de código que mejora el rendimiento. |
+| ✅ | `test` | Añadir tests faltantes o corregir existentes. |
+| 📦 | `build` | Cambios que afectan el sistema de construcción o dependencias externas. |
+| 👷 | `ci` | Cambios en archivos de configuración y scripts de CI. |
+| 🔧 | `chore` | Otros cambios que no modifican src o test files (ej. config de herramientas). |
+| ⏪ | `revert` | Reversión de un commit anterior. |
+
+## Procedimiento
+
+Cuando el usuario pida hacer commit:
+
+1. **Analiza los cambios**: Revisa qué archivos se modificaron y qué tipo de cambio representan.
+2. **Selecciona el tipo**: Elige el tipo de commit más apropiado de la tabla.
+3. **Define el alcance**: Identifica el módulo o componente afectado (opcional pero recomendado).
+4. **Redacta el asunto**: Máximo 50 caracteres, imperativo, en español.
+5. **Redacta el cuerpo**: Explica qué, por qué y detalles técnicos. Es obligatorio.
+6. **Ejecuta el commit**: Usa `git commit -m` con el formato completo.
+
+## Ejemplo Correcto
+
+```text
+✨ feat(auth): integra login social con Google
+
+Se ha implementado la autenticación mediante OAuth2 con Google para facilitar
+el acceso a nuevos usuarios.
+
+Cambios principales:
+- Agrega configuración de estrategia de Passport.js para Google.
+- Crea nuevas rutas de callback en el controlador de autenticación.
+- Actualiza el modelo de Usuario para almacenar el providerId.
+- Ajusta la interfaz de login para incluir el botón de "Entrar con Google".
+
+Motivación:
+Reducir la fricción en el registro de usuarios y aumentar la conversión.
+```
+
+## Errores Comunes a Evitar
+
+- `fix: error login` → Falta emoji, título vago, sin cuerpo.
+- `🐛 Fix: arregla login` → Tipo en mayúscula, lo correcto es minúscula `fix`.
+- `✨ feat(user): Update user logic` → En inglés, debe ser en español.
+- Título que excede 50 caracteres → Acorta y mueve el detalle al cuerpo.
+
+## Integración con el Workflow
+
+Después de ejecutar un commit exitoso, el router debe activar la skill `changelog-updater` para registrar el cambio automáticamente en `CHANGELOG.md`.

package/templates/skills/opera-contract-auditor/SKILL.md

@@ -1,38 +1,38 @@
----
-name: "opera-contract-auditor"
-description: "Skill para auditar el contrato operativo de OPERA, detectar huecos, contradicciones y pseudoprecision antes de seguir ejecutando."
-metadata:
-  version: "1.0"
-  type: "project"
----
-
-# OPERA Contract Auditor
-
-Usa esta skill cuando exista `ops/contract/operating-contract.json` o cuando OPERA haya dejado `ops/bootstrap/quality-report.json`.
-
-## Objetivo
-
-Validar si el contrato operativo ya es suficientemente coherente para pasar de discovery a ejecucion.
-
-## Debes revisar
-
-- `ops/contract/operating-contract.json`
-- `ops/bootstrap/quality-report.json`
-- `ops/bootstrap/open-questions.md`
-- `ops/genesis.md`
-
-## Checklist minimo
-
-- el problema y el usuario objetivo estan definidos
-- el resultado singular deseado es verificable
-- la fuente de verdad esta clara
-- input y output schema no se contradicen
-- no hay reglas de comportamiento ambiguas
-- las integraciones externas son coherentes con el contrato
-- las preguntas abiertas siguen abiertas de forma explicita o estan resueltas
-
-## Salida esperada
-
-- identificar contradicciones o lagunas concretas
-- proponer solo las correcciones necesarias
-- no inventar decisiones de negocio no confirmadas
+---
+name: "opera-contract-auditor"
+description: "Skill para auditar el contrato operativo de OPERA, detectar huecos, contradicciones y pseudoprecision antes de seguir ejecutando."
+metadata:
+  version: "1.0"
+  type: "project"
+---
+
+# OPERA Contract Auditor
+
+Usa esta skill cuando exista `ops/contract/operating-contract.json` o cuando OPERA haya dejado `ops/bootstrap/quality-report.json`.
+
+## Objetivo
+
+Validar si el contrato operativo ya es suficientemente coherente para pasar de discovery a ejecucion.
+
+## Debes revisar
+
+- `ops/contract/operating-contract.json`
+- `ops/bootstrap/quality-report.json`
+- `ops/bootstrap/open-questions.md`
+- `ops/genesis.md`
+
+## Checklist minimo
+
+- el problema y el usuario objetivo estan definidos
+- el resultado singular deseado es verificable
+- la fuente de verdad esta clara
+- input y output schema no se contradicen
+- no hay reglas de comportamiento ambiguas
+- las integraciones externas son coherentes con el contrato
+- las preguntas abiertas siguen abiertas de forma explicita o estan resueltas
+
+## Salida esperada
+
+- identificar contradicciones o lagunas concretas
+- proponer solo las correcciones necesarias
+- no inventar decisiones de negocio no confirmadas

package/templates/skills/opera-contract-auditor/locales/en/SKILL.md

@@ -1,38 +1,38 @@
----
-name: "opera-contract-auditor"
-description: "Skill for auditing the OPERA operating contract, spotting gaps, contradictions, and false precision before execution continues."
-metadata:
-  version: "1.0"
-  type: "project"
----
-
-# OPERA Contract Auditor
-
-Use this skill when `ops/contract/operating-contract.json` already exists or when OPERA has produced `ops/bootstrap/quality-report.json`.
-
-## Goal
-
-Validate whether the operating contract is coherent enough to move from discovery into execution.
-
-## Review these files
-
-- `ops/contract/operating-contract.json`
-- `ops/bootstrap/quality-report.json`
-- `ops/bootstrap/open-questions.md`
-- `ops/genesis.md`
-
-## Minimum checklist
-
-- the problem and target user are defined
-- the singular desired outcome is verifiable
-- the source of truth is clear
-- input and output schema do not contradict each other
-- behavior rules are not ambiguous
-- external integrations match the contract
-- open questions are either explicitly open or clearly resolved
-
-## Expected output
-
-- identify concrete contradictions or gaps
-- propose only the corrections that are actually needed
-- do not invent unconfirmed business decisions
+---
+name: "opera-contract-auditor"
+description: "Skill for auditing the OPERA operating contract, spotting gaps, contradictions, and false precision before execution continues."
+metadata:
+  version: "1.0"
+  type: "project"
+---
+
+# OPERA Contract Auditor
+
+Use this skill when `ops/contract/operating-contract.json` already exists or when OPERA has produced `ops/bootstrap/quality-report.json`.
+
+## Goal
+
+Validate whether the operating contract is coherent enough to move from discovery into execution.
+
+## Review these files
+
+- `ops/contract/operating-contract.json`
+- `ops/bootstrap/quality-report.json`
+- `ops/bootstrap/open-questions.md`
+- `ops/genesis.md`
+
+## Minimum checklist
+
+- the problem and target user are defined
+- the singular desired outcome is verifiable
+- the source of truth is clear
+- input and output schema do not contradict each other
+- behavior rules are not ambiguous
+- external integrations match the contract
+- open questions are either explicitly open or clearly resolved
+
+## Expected output
+
+- identify concrete contradictions or gaps
+- propose only the corrections that are actually needed
+- do not invent unconfirmed business decisions

package/templates/skills/opera-policy-guard/SKILL.md

@@ -1,26 +1,26 @@
----
-name: "opera-policy-guard"
-description: "Skill para interpretar la politica ejecutable de OPERA y decidir que acciones requieren aprobacion explicita."
-metadata:
-  version: "1.0"
-  type: "project"
----
-
-# OPERA Policy Guard
-
-Usa esta skill cuando vayas a ejecutar acciones con riesgo operativo, efectos externos o cambios destructivos.
-
-## Fuente principal
-
-- `ops/policy/autonomy.json`
-
-## Debes responder
-
-- si la accion es verde, amarilla o roja
-- si requiere aprobacion explicita
-- que efecto externo produce
-- que alternativa segura existe si no hay permiso
-
-## Regla
-
-Si la politica deja dudas, no asumas permiso. Marca la accion como bloqueada hasta aclararlo.
+---
+name: "opera-policy-guard"
+description: "Skill para interpretar la politica ejecutable de OPERA y decidir que acciones requieren aprobacion explicita."
+metadata:
+  version: "1.0"
+  type: "project"
+---
+
+# OPERA Policy Guard
+
+Usa esta skill cuando vayas a ejecutar acciones con riesgo operativo, efectos externos o cambios destructivos.
+
+## Fuente principal
+
+- `ops/policy/autonomy.json`
+
+## Debes responder
+
+- si la accion es verde, amarilla o roja
+- si requiere aprobacion explicita
+- que efecto externo produce
+- que alternativa segura existe si no hay permiso
+
+## Regla
+
+Si la politica deja dudas, no asumas permiso. Marca la accion como bloqueada hasta aclararlo.

package/templates/skills/opera-policy-guard/locales/en/SKILL.md

@@ -1,26 +1,26 @@
----
-name: "opera-policy-guard"
-description: "Skill for interpreting the OPERA executable policy and deciding which actions require explicit approval."
-metadata:
-  version: "1.0"
-  type: "project"
----
-
-# OPERA Policy Guard
-
-Use this skill before actions with operational risk, external side effects, or destructive changes.
-
-## Primary source
-
-- `ops/policy/autonomy.json`
-
-## You must answer
-
-- whether the action is green, yellow, or red
-- whether it requires explicit approval
-- what external side effect it causes
-- what safe alternative exists if approval is missing
-
-## Rule
-
-If the policy is ambiguous, do not assume permission. Mark the action as blocked until it is clarified.
+---
+name: "opera-policy-guard"
+description: "Skill for interpreting the OPERA executable policy and deciding which actions require explicit approval."
+metadata:
+  version: "1.0"
+  type: "project"
+---
+
+# OPERA Policy Guard
+
+Use this skill before actions with operational risk, external side effects, or destructive changes.
+
+## Primary source
+
+- `ops/policy/autonomy.json`
+
+## You must answer
+
+- whether the action is green, yellow, or red
+- whether it requires explicit approval
+- what external side effect it causes
+- what safe alternative exists if approval is missing
+
+## Rule
+
+If the policy is ambiguous, do not assume permission. Mark the action as blocked until it is clarified.