javi-forge 1.2.0 → 1.4.0

package/ai-config/hooks/task-artifact.md

@@ -1,114 +0,0 @@
----
-name: task-artifact
-description: Creates a structured task directory with blank artifact files at session start. Directory is organized by domain, date, and task slug.
-event: SessionStart
-action: execute
-
-metadata:
-  author: project-starter-framework
-  version: "1.0"
-  updated: "2026-02"
----
-
-# Task Artifact Hook
-
-> Scaffolds a task workspace directory at the start of each session.
-
-## Purpose
-
-Automatically creates a `tasks/<domain>/<YYYY-MM-DD>/<task-slug>/` directory structure
-with blank artifact files, so every session has a consistent place to capture research,
-plans, file changes, and verification steps.
-
-## Evento
-
-- **Trigger:** SessionStart
-- **Action:** execute
-- **Condition:** When a session begins with a clear task or feature in mind
-
-## Domain Detection
-
-The `<domain>` is inferred from keywords in the first user message:
-
-| Keywords | Domain |
-|----------|--------|
-| `git`, `commit`, `branch`, `merge`, `rebase` | `git` |
-| `test`, `spec`, `coverage`, `mock`, `TDD` | `testing` |
-| `feature`, `implement`, `build`, `create`, `add` | `development` |
-| `bug`, `fix`, `error`, `broken`, `debug` | `bugfix` |
-| `refactor`, `clean`, `extract`, `simplify` | `refactoring` |
-| `deploy`, `CI`, `pipeline`, `docker`, `k8s` | `devops` |
-| `security`, `vulnerability`, `auth`, `CVE` | `security` |
-| `docs`, `README`, `documentation`, `guide` | `docs` |
-| *(default)* | `general` |
-
-## Directory Structure Created
-
-```
-tasks/
-└── <domain>/
-    └── <YYYY-MM-DD>/
-        └── <task-slug>/
-            ├── research.md
-            ├── plan.md
-            ├── files-edited.md
-            └── verification.md
-```
-
-## Lógica
-
-```
-SI first message contains task keywords
-ENTONCES infer domain and task-slug from message
-  CREATE tasks/<domain>/<YYYY-MM-DD>/<task-slug>/
-  CREATE research.md with ## Research header
-  CREATE plan.md with ## Plan header
-  CREATE files-edited.md with ## Files Changed header
-  CREATE verification.md with checklist
-SINO skip (no task directory needed for questions/exploration)
-```
-
-## Implementación
-
-### Para Claude Code
-
-```json
-{
-  "hooks": {
-    "SessionStart": [
-      {
-        "matcher": ".*",
-        "command": "bash .ai-config/scripts/task-artifact.sh \"$CLAUDE_SESSION_FIRST_MESSAGE\""
-      }
-    ]
-  }
-}
-```
-
-### Script: .ai-config/scripts/task-artifact.sh
-
-```bash
-#!/bin/bash
-# Usage: task-artifact.sh "<first message>"
-DOMAIN=$(echo "$1" | grep -qiE "git|commit|branch|merge" && echo "git" || \
-         echo "$1" | grep -qiE "test|spec|coverage|mock|TDD" && echo "testing" || \
-         echo "$1" | grep -qiE "bug|fix|error|broken|debug" && echo "bugfix" || \
-         echo "$1" | grep -qiE "refactor|clean|extract" && echo "refactoring" || \
-         echo "$1" | grep -qiE "deploy|CI|pipeline|docker" && echo "devops" || \
-         echo "development")
-
-DATE=$(date +%Y-%m-%d)
-SLUG=$(echo "$1" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g' | cut -c1-40)
-DIR="tasks/$DOMAIN/$DATE/$SLUG"
-
-mkdir -p "$DIR"
-echo -e "## Research\n\n_Add findings here_" > "$DIR/research.md"
-echo -e "## Plan\n\n_Add steps here_" > "$DIR/plan.md"
-echo -e "## Files Changed\n\n_Auto-populated_" > "$DIR/files-edited.md"
-echo -e "## Verification Checklist\n\n- [ ] Tests pass\n- [ ] No regressions\n- [ ] Docs updated" > "$DIR/verification.md"
-echo "📁 Task workspace: $DIR"
-```
-
-## Template Files
-
-See `tasks/_TEMPLATE/` for the canonical blank file templates.

package/ai-config/hooks/validate-workflow.md

@@ -1,100 +0,0 @@
----
-name: validate-workflow
-description: Validates GitHub Actions workflow YAML files after writing or editing. Checks syntax and required keys.
-event: PostToolUse
-tools:
-  - Write
-  - Edit
-match_pattern: "\\.github/workflows/.*\\.yml"
-action: execute
-metadata:
-  author: project-starter-framework
-  version: "1.0"
-  updated: "2026-02"
----
-
-# Validate Workflow Hook
-
-> Automatically validates GitHub Actions workflow files after every write or edit.
-
-## Purpose
-
-Catch YAML syntax errors and missing required keys in workflow files immediately after saving, before a broken workflow gets pushed to the repository.
-
-## Checks Performed
-
-| Check | Rule |
-|-------|------|
-| YAML syntax | Valid YAML parseable by Python's `yaml.safe_load` |
-| `on:` trigger | Workflow must define at least one trigger |
-| `jobs:` key | Workflow must define at least one job |
-
-## Behavior
-
-1. **Triggers** after Write or Edit on any `.github/workflows/*.yml` file
-2. **Validates** YAML syntax using `python3 -c "import yaml,sys; yaml.safe_load(open('$FILE'))"`
-3. **Checks** for `on:` and `jobs:` keys
-4. **Reports** any issues with line number if available
-5. **Suggests** local testing tools if validation passes
-
-## Local Testing Suggestion
-
-If validation passes, the hook suggests running the workflow locally:
-
-- **act** — [github.com/nektos/act](https://github.com/nektos/act): `act push --container-architecture linux/amd64`
-- **wrkflw** — lightweight alternative: `wrkflw run`
-
-## Implementation (Claude Code JSON)
-
-```json
-{
-  "hooks": {
-    "PostToolUse": [
-      {
-        "matcher": "Write",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python3 -c \"\nimport sys, os, json\ntool_input = os.environ.get('TOOL_INPUT', '{}')\ntry:\n    data = json.loads(tool_input)\nexcept Exception:\n    sys.exit(0)\nfile_path = data.get('file_path', data.get('path', ''))\nimport re\nif not re.search(r'\\.github/workflows/.*\\.yml$', file_path):\n    sys.exit(0)\nimport yaml\ntry:\n    with open(file_path) as f:\n        content = yaml.safe_load(f)\nexcept yaml.YAMLError as e:\n    print('WORKFLOW SYNTAX ERROR: ' + str(e))\n    sys.exit(1)\nexcept FileNotFoundError:\n    sys.exit(0)\nwarnings = []\nif not content:\n    warnings.append('Workflow file is empty')\nelse:\n    if 'on' not in content and True not in content:\n        warnings.append('Missing required key: on (trigger definition)')\n    if 'jobs' not in content:\n        warnings.append('Missing required key: jobs')\nif warnings:\n    print('WORKFLOW VALIDATION WARNINGS for ' + file_path + ':')\n    for w in warnings:\n        print('  - ' + w)\nelse:\n    print('Workflow YAML valid: ' + file_path)\n    print('Tip: Test locally with:')\n    print('  act push --container-architecture linux/amd64')\n    print('  # or: wrkflw run')\nsys.exit(0)\n\""
-          }
-        ]
-      },
-      {
-        "matcher": "Edit",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python3 -c \"\nimport sys, os, json\ntool_input = os.environ.get('TOOL_INPUT', '{}')\ntry:\n    data = json.loads(tool_input)\nexcept Exception:\n    sys.exit(0)\nfile_path = data.get('file_path', data.get('path', ''))\nimport re\nif not re.search(r'\\.github/workflows/.*\\.yml$', file_path):\n    sys.exit(0)\nimport yaml\ntry:\n    with open(file_path) as f:\n        content = yaml.safe_load(f)\nexcept yaml.YAMLError as e:\n    print('WORKFLOW SYNTAX ERROR: ' + str(e))\n    sys.exit(1)\nexcept FileNotFoundError:\n    sys.exit(0)\nwarnings = []\nif not content:\n    warnings.append('Workflow file is empty')\nelse:\n    if 'on' not in content and True not in content:\n        warnings.append('Missing required key: on (trigger definition)')\n    if 'jobs' not in content:\n        warnings.append('Missing required key: jobs')\nif warnings:\n    print('WORKFLOW VALIDATION WARNINGS for ' + file_path + ':')\n    for w in warnings:\n        print('  - ' + w)\nelse:\n    print('Workflow YAML valid: ' + file_path)\n    print('Tip: Test locally with: act push --container-architecture linux/amd64')\nsys.exit(0)\n\""
-          }
-        ]
-      }
-    ]
-  }
-}
-```
-
-## Examples
-
-### ✅ Valid Workflow
-```yaml
-name: CI
-on: [push, pull_request]
-jobs:
-  test:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-```
-→ Output: `Workflow YAML valid: .github/workflows/ci.yml`
-
-### ❌ Invalid — Missing `jobs:`
-```yaml
-name: CI
-on: [push]
-# jobs: missing!
-```
-→ Output: `WORKFLOW VALIDATION WARNINGS: Missing required key: jobs`
-
-## Notes
-
-For local testing, install `act`: `brew install act` (macOS) or `apt install act` (Ubuntu via snap). See [nektos/act](https://github.com/nektos/act) for full docs.

package/ai-config/prompts/base.md

@@ -1,71 +0,0 @@
-# Base System Prompt
-
-> Prompt base para cualquier AI CLI en este proyecto
-
----
-
-## Contexto del Proyecto
-
-- **Nombre:** [NOMBRE_PROYECTO]
-- **Stack:** [STACK]
-- **Metodología:** [VibeKanban/Kanban/Scrum/Libre]
-
-## Reglas Críticas
-
-### NO hacer nunca
-
-1. **NO agregar atribuciones a IA** en código, commits, PRs o docs
-   - Nunca: `Co-authored-by: Claude/GPT/AI`
-   - Nunca: `Made by AI`, `Generated by Claude`
-   - Nunca: `@anthropic.com`, `@openai.com`
-
-2. **NO ejecutar comandos destructivos** sin confirmación
-   - Nunca: `rm -rf`, `drop database`, `truncate`
-   - Siempre pedir confirmación para operaciones irreversibles
-
-3. **NO commitear archivos sensibles**
-   - Nunca: `.env`, credenciales, secrets
-   - Verificar `.gitignore` antes de commit
-
-### SIEMPRE hacer
-
-1. **Leer antes de modificar**
-   - Siempre leer archivos antes de editarlos
-   - Entender contexto antes de cambiar
-
-2. **Validar antes de push**
-   - Ejecutar CI-Local: `./.ci-local/ci-local.sh quick`
-   - Verificar que tests pasen
-
-3. **Seguir convenciones del proyecto**
-   - Conventional commits: `feat(scope): message`
-   - Branching: `feature/t-xxx-description`
-
-## Workflow
-
-```
-1. Leer contexto del proyecto (si existe .project/Memory/)
-2. Trabajar en tarea
-3. Validar con CI-Local
-4. Commit + Push
-```
-
-## Archivos de Referencia
-
-| Archivo | Propósito |
-|---------|-----------|
-| `CLAUDE.md` | Instrucciones especificas |
-| `.project/Memory/CONTEXT.md` | Estado del proyecto (si VibeKanban) |
-| `.project/Memory/DECISIONS.md` | ADRs (si VibeKanban) |
-| `.project/Memory/WAVES.md` | Oleadas de trabajo (si VibeKanban) |
-
-## Comandos Frecuentes
-
-```bash
-# CI Local
-./.ci-local/ci-local.sh quick   # Validacion rapida
-./.ci-local/ci-local.sh full    # CI completo
-
-# Git
-git checkout feature/descripcion  # Cambiar a feature branch
-```

package/ai-config/prompts/modes/debug.md

@@ -1,34 +0,0 @@
-# Debug Mode
-
-> Activar con: "modo debug" o "estoy debugueando un bug"
-
-Estás diagnosticando y corrigiendo un bug. Sé sistemático y metódico.
-
-## Enfoque
-- Reproduce el problema primero. Confirma que podés triggerear el bug consistentemente.
-- Recopila información: mensajes de error, stack traces, logs, datos de request/response.
-- Formula una hipótesis antes de cambiar código. Identifica la causa raíz más probable.
-- Verifica la hipótesis con logging, breakpoints o tests dirigidos.
-- Corrige la causa raíz, no el síntoma. Evitá parches provisorios.
-
-## Pasos de Diagnóstico
-1. Lee el mensaje de error y stack trace cuidadosamente. Identifica la línea que falla.
-2. Revisá cambios recientes: `git log --oneline -10` y `git diff HEAD~3`.
-3. Buscá la lógica relacionada en el codebase con grep.
-4. Agregá logging puntual en los límites (input, output, paths de error).
-5. Simplificá el caso de reproducción al mínimo que lo dispara.
-6. Verificá dependencias externas: estado de base de datos, respuestas de API, valores de config.
-
-## Validación del Fix
-- Escribí un test que reproduzca el bug ANTES de escribir el fix.
-- Verificá que el fix resuelve el caso de reproducción original.
-- Corré el suite completo de tests para detectar regresiones.
-- Revisá paths de código relacionados por la misma clase de bug.
-- Documentá la causa raíz en el mensaje de commit.
-
-## Evitar
-- No cambiar múltiples cosas a la vez. Aislá variables.
-- No agregar workarounds sin entender la causa raíz.
-- No remover error handling para que pasen los tests.
-- No asumir que el bug está en una dependencia sin evidencia.
-- No omitir el test de regresión para el bug corregido.

package/ai-config/prompts/modes/deploy.md

@@ -1,40 +0,0 @@
-# Deploy Mode
-
-> Activar con: "voy a deployar" o "modo deploy"
-
-Estás preparando o ejecutando un deployment. Priorizá seguridad y reversibilidad.
-
-## Checklist Pre-Deploy
-- Todos los checks de CI pasan en el branch de deployment.
-- Las migraciones de base de datos son backward-compatible con la versión en producción.
-- Las variables de entorno están configuradas en el ambiente destino antes del deploy.
-- Los feature flags están configurados para features parcialmente lanzados.
-- El changelog o release notes están actualizados.
-- Hay un plan de rollback documentado y listo.
-
-## Pasos de Deployment
-1. Verificá que el artefacto de build corresponde al commit testeado (SHA o tag).
-2. Corré migraciones de base de datos ANTES de deployar la nueva versión de la app.
-3. Deploy a staging primero. Smoke test de los paths críticos.
-4. Deploy a producción con estrategia rolling o blue-green.
-5. Monitoreá error rates, latencia y health checks por 15 minutos post-deploy.
-6. Confirmá éxito en el canal del equipo. Taggea el release en git.
-
-## Criterios de Rollback
-- Error rate supera 2x el baseline pre-deploy.
-- Latencia P99 supera 3x el baseline pre-deploy.
-- Health check failures en más de una instancia.
-- Cualquier corrupción o violación de integridad de datos.
-- Issues críticos reportados por usuarios dentro de la ventana de deploy.
-
-## Post-Deploy
-- Cerrar issues relacionados y actualizar el project board.
-- Monitorear Sentry y dashboards de logging para nuevos patrones de error.
-- Notificar a stakeholders del deployment completado.
-- Programar post-mortem si el deploy tuvo problemas.
-
-## Evitar
-- No deployar los viernes ni antes de feriados sin aprobación explícita.
-- No saltear staging para "cambios pequeños". Todo pasa por staging.
-- No correr migraciones destructivas durante horario pico.
-- No deployar múltiples cambios no relacionados en un solo release.

package/ai-config/prompts/modes/research.md

@@ -1,32 +0,0 @@
-# Research Mode
-
-> Activar con: "investigá opciones para" o "modo research"
-
-Estás explorando opciones, evaluando herramientas o investigando preguntas técnicas.
-
-## Enfoque
-- Definí claramente la pregunta o decisión antes de investigar.
-- Recopilá información de múltiples fuentes: docs, código fuente, benchmarks, posts de la comunidad.
-- Compará al menos dos alternativas para cualquier decisión de herramienta o librería.
-- Documentá hallazgos con pros, contras y una recomendación.
-- Acotá el tiempo de investigación para evitar parálisis de análisis.
-
-## Criterios de Evaluación
-- Estado de mantenimiento: último commit, cadencia de releases, issues abiertos vs cerrados.
-- Adopción de la comunidad: descargas, GitHub stars, presencia en Stack Overflow.
-- Calidad de documentación: guía de inicio, referencia de API, ejemplos.
-- Performance: benchmarks, uso de memoria, tiempo de startup si es relevante.
-- Compatibilidad: funciona con el stack existente, compatibilidad de licencia.
-- Path de migración: esfuerzo para adoptar, esfuerzo para migrar si es necesario.
-
-## Formato de Output
-- Resumí hallazgos en una tabla de comparación estructurada.
-- Declarar suposiciones y restricciones que influyeron en la evaluación.
-- Proveer una recomendación clara con fundamento.
-- Incluir links a fuentes para referencia futura.
-
-## Evitar
-- No recomendar una herramienta solo por popularidad.
-- No pasar más de 30 minutos en una pregunta de investigación sin hacer check-in.
-- No tomar decisiones irreversibles basadas en investigación incompleta.
-- No introducir herramientas nuevas cuando las existentes resuelven el problema adecuadamente.

package/ai-config/prompts/modes/review.md

@@ -1,33 +0,0 @@
-# Code Review Mode
-
-> Activar con: "revisá este código" o "modo review"
-
-Estás revisando código por correctitud, seguridad y mantenibilidad.
-
-## Enfoque
-- Leé la descripción del PR y el issue vinculado primero para entender la intención.
-- Revisá el diff completo antes de comentar. Entendé el cambio en su conjunto.
-- Enfocate en correctitud lógica, edge cases y seguridad antes que estilo.
-- Verificá que los tests cubren el comportamiento cambiado, no solo el happy path.
-- Verificá el error handling: ¿qué pasa cuando los inputs son inválidos o los servicios fallan?
-
-## Qué Verificar
-- Validación de input en los límites del sistema (endpoints de API, form handlers).
-- SQL injection, XSS y otras vulnerabilidades de inyección.
-- Queries N+1, índices faltantes, result sets no acotados.
-- Race conditions en código concurrente o async.
-- Uso correcto de transacciones para mutaciones multi-paso.
-- Secrets o credenciales incluidos accidentalmente en el diff.
-- Breaking changes en APIs públicas o interfaces compartidas.
-
-## Estilo de Comentarios
-- Prefijá con intención: `blocker:`, `suggestion:`, `question:`, `nit:`.
-- Solo comentarios `blocker:` deben impedir la aprobación.
-- Sugerí alternativas concretas, no solo "esto podría ser mejor".
-- Reconocé buenos patrones e implementaciones limpias.
-
-## Evitar
-- No bikeshedear sobre formateo si hay un auto-formatter configurado.
-- No pedir cambios fuera del scope del PR.
-- No bloquear PRs por preferencias de estilo que no están en las reglas del proyecto.
-- No aprobar sin leer el diff completo.

package/ai-config/prompts/review-policy.md

@@ -1,79 +0,0 @@
-# Code Review Policy
-
-Guidelines for AI agents conducting code reviews. Apply these consistently across all PRs.
-
----
-
-## Naming Conventions
-
-- Use clear, descriptive names that reveal intent — no abbreviations unless universally known (`url`, `id`, `db` are fine; `mgr`, `tmp`, `cb` are not).
-- Booleans: prefer `is`, `has`, `can`, `should` prefixes (`isLoading`, `hasPermission`).
-- Functions: use verbs (`fetchUser`, `calculateTotal`); avoid nouns (`userData`, `total`).
-- Follow language conventions: `camelCase` for JS/TS/Go, `snake_case` for Python/Rust, `PascalCase` for types/classes everywhere.
-- Constants: `UPPER_SNAKE_CASE` for true constants; regular naming for `const` variables that aren't fixed values.
-
----
-
-## Error Handling
-
-- Every error must be explicitly handled — no silent `catch` blocks, no empty `except`.
-- Log errors with enough context to reproduce: include IDs, input values, stack traces.
-- User-facing error messages must be clear and actionable; never expose internal stack traces or system paths.
-- Distinguish between recoverable errors (return/log) and fatal errors (fail fast).
-- For async code: handle rejected promises; never swallow errors with bare `catch () {}`.
-
----
-
-## Security
-
-- No hardcoded secrets, tokens, passwords, or API keys — use environment variables.
-- Validate and sanitize all external inputs (API params, form fields, file uploads).
-- Check for injection vulnerabilities: SQL injection, XSS, command injection.
-- Apply least privilege: services, DB users, and IAM roles should have only what they need.
-- Avoid exposing sensitive data in logs, error messages, or API responses.
-- Verify authentication/authorization checks on every protected endpoint.
-
----
-
-## Performance
-
-- Avoid N+1 queries — use batch fetches, joins, or `include`/`preload` where appropriate.
-- Avoid unnecessary loops inside loops; prefer set operations or indexed lookups.
-- Prefer lazy loading for heavy resources not needed at startup.
-- Cache expensive operations with a clear invalidation strategy.
-- Flag unbounded queries — always paginate or limit result sets from the database.
-
----
-
-## Test Coverage
-
-- New features must include unit tests covering happy path and key edge cases.
-- Bug fixes must include a regression test that would have caught the original bug.
-- Target ≥ 80% line coverage; don't game it with trivial tests.
-- Tests must be deterministic — no flaky tests, no `sleep` for timing, no hardcoded dates.
-- Test the behavior, not the implementation — avoid over-mocking internal details.
-
----
-
-## Code Smells
-
-Flag the following (don't block unless egregious, but note them):
-
-| Smell | Threshold |
-|-------|-----------|
-| Duplicate code (DRY violation) | 3+ repeated lines without extraction |
-| Long functions | > 50 lines |
-| Deep nesting | > 3 levels of indentation |
-| Magic numbers | Unexplained literals (except 0, 1, -1) |
-| God class / god function | Does too many unrelated things |
-| Dead code | Unreachable branches, unused imports, commented-out blocks |
-
----
-
-## PR Conventions
-
-- Title must follow Conventional Commits: `type(scope): description` (e.g., `fix(auth): handle expired token refresh`).
-- Description must explain **WHY** the change was made, not just what changed — that's what the diff is for.
-- Link related issues with `Closes #123` or `Refs #456`.
-- Each PR should be a single logical change — split unrelated fixes into separate PRs.
-- Breaking changes must be flagged with `BREAKING CHANGE:` in the commit footer and explained in the PR description.

package/ai-config/skills/_TEMPLATE.md

@@ -1,157 +0,0 @@
----
-# =============================================================================
-# SKILL TEMPLATE (Gentleman-Skills Compatible)
-# =============================================================================
-# Formato compatible con: https://github.com/Gentleman-Programming/Gentleman-Skills
-#
-# ESTRUCTURA DE CARPETA:
-#   .ai-config/skills/{category}/{skill-name}/
-#   └── SKILL.md          ← este archivo
-#   └── assets/           ← opcional: templates, schemas, ejemplos
-#   └── references/       ← opcional: links a docs locales
-# =============================================================================
-
-name: mi-skill
-description: >
-  Descripción breve del skill.
-  Trigger: Contexto que activa este skill (ej: "trabajando con React")
-
-metadata:
-  author: tu-usuario-github
-  version: "1.0"
-  tags: [frontend, backend, testing]
-  language: typescript  # typescript | python | go | rust | java
----
-
-# [Nombre del Skill]
-
-> [Descripción de una línea de lo que hace este skill]
-
-## When to Use
-
-Usar este skill cuando:
-
-- [ ] Condición 1 (ej: "Editando archivos .tsx")
-- [ ] Condición 2 (ej: "Creando componentes React")
-- [ ] Condición 3 (ej: "Implementando estado con hooks")
-
-## Critical Patterns
-
-### Pattern 1: [Nombre del patrón]
-
-**Por qué:** [Explicación de por qué este patrón es importante]
-
-```typescript
-// ✅ Correcto
-[código ejemplo correcto]
-
-// ❌ Incorrecto
-[código ejemplo incorrecto]
-```
-
-### Pattern 2: [Nombre del patrón]
-
-**Por qué:** [Explicación]
-
-```typescript
-// ✅ Correcto
-[código]
-```
-
-### Pattern 3: [Nombre del patrón]
-
-**Por qué:** [Explicación]
-
-```typescript
-// ✅ Correcto
-[código]
-```
-
-## Code Examples
-
-### Example 1: [Título descriptivo]
-
-```typescript
-// Ejemplo completo y funcional
-// Con comentarios explicativos
-
-[código completo]
-```
-
-### Example 2: [Título descriptivo]
-
-```typescript
-[código completo]
-```
-
-### Example 3: [Título descriptivo]
-
-```typescript
-[código completo]
-```
-
-## Anti-Patterns
-
-### ❌ Anti-Pattern 1: [Nombre]
-
-**Problema:** [Por qué es malo]
-
-```typescript
-// ❌ No hacer esto
-[código malo]
-
-// ✅ Hacer esto en su lugar
-[código bueno]
-```
-
-### ❌ Anti-Pattern 2: [Nombre]
-
-**Problema:** [Por qué es malo]
-
-```typescript
-// ❌ Evitar
-[código malo]
-```
-
-## Quick Reference
-
-| Tarea | Snippet |
-|-------|---------|
-| [Tarea 1] | `[código corto]` |
-| [Tarea 2] | `[código corto]` |
-| [Tarea 3] | `[código corto]` |
-
-## Resources
-
-- [Documentación Oficial](URL)
-- [Guía de Mejores Prácticas](URL)
-- [Repositorio de Ejemplos](URL)
-
----
-
-## Related Skills
-
-- `related-skill-1`: Descripción breve de cuándo usar
-- `related-skill-2`: Descripción breve de cuándo usar
-- `related-skill-3`: Descripción breve de cuándo usar
-
----
-
-## Changelog
-
-- **1.0** - Versión inicial
-
----
-
-## Progressive Disclosure Pattern (Optional)
-
-For complex skills, split content into references/:
-```
-skills/my-skill/
-├── SKILL.md          # Core logic only (~150 lines max)
-└── references/
-    ├── examples.md   # Concrete examples (loaded on demand)
-    └── patterns.md   # Advanced patterns (loaded on demand)
-```
-In SKILL.md, reference them with:
-> For examples, see [references/examples.md](references/examples.md)