/glossary
Crear y mantener un glosario de términos del proyecto para evitar ambigüedades. Activar ante: glosario, definir terminos, vocabulario del proyecto, que significa
$ npx -y skills add 686f6c61/alfred-dev --skill glossary --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/glossary
Context preview
The summary Claude sees to decide when to auto-load this skill.
Crear y mantener un glosario de términos del proyecto para evitar ambigüedades. Activar ante: glosario, definir terminos, vocabulario del proyecto, que significa
SKILL.md
glossary.SKILL.mdname: glossary
description: "Crear y mantener un glosario de términos del proyecto para evitar ambigüedades. Activar ante: glosario, definir terminos, vocabulario del proyecto, que significa"
Corpus lingüístico / Glosario del proyecto
Resumen
Este skill crea y mantiene un glosario de términos del proyecto: un documento de referencia donde cada concepto tiene una definición única, consensuada y sin ambigüedades. El objetivo es que todo el equipo hable el mismo idioma: cuando alguien dice "usuario", todos entienden lo mismo.
Las malas interpretaciones entre miembros del equipo son una de las fuentes más frecuentes de bugs y retrabajos. Un glosario bien mantenido previene estos problemas de raíz.
Proceso
Paso 1: identificar términos clave
- Revisar el código fuente: nombres de entidades, modelos, servicios, tipos.
- Revisar la documentación existente: README, PRDs, historias de usuario.
- Identificar términos que se usan de forma inconsistente o ambigua.
- Preguntar al usuario si hay términos que generen confusión en el equipo.
Paso 2: crear el fichero de glosario
Crear `docs/glossary.md` con la siguiente estructura:
# Glosario del proyecto
| Término | Definición | Contexto | No confundir con |
|---------|-----------|----------|------------------|
| Usuario | Persona registrada con cuenta activa | Backend, API | Visitante (no registrado) |
| Sesión | Período de actividad autenticada | Auth | Conexión (socket) |
Cada entrada incluye:
- **Término**: la palabra o expresión exacta.
- **Definición**: qué significa en el contexto de este proyecto. Una frase, precisa.
- **Contexto**: dónde se usa (módulo, capa, dominio).
- **No confundir con**: términos similares que significan otra cosa.
Paso 3: vincular con el código
- Verificar que los nombres en el código (variables, clases, funciones) son coherentes con el glosario.
- Si hay inconsistencias, proponer renombramientos o documentar la discrepancia.
Paso 4: mantener actualizado
- Cada vez que se introduce un concepto nuevo en el proyecto, añadirlo al glosario.
- Si un término cambia de significado, actualizar la definición y notificar al equipo.
Qué NO hacer
- No incluir términos genéricos de programación (API, endpoint, función). Solo términos específicos del dominio del proyecto.
- No escribir definiciones largas. Una frase por término, dos como máximo.
- No crear el glosario y olvidarlo. Un glosario desactualizado es peor que no tener ninguno.
Read more
name: glossary description: "Crear y mantener un glosario de términos del proyecto para evitar ambigüedades. Activar ante: glosario, definir terminos, vocabulario del proyecto, que significa"
Corpus lingüístico / Glosario del proyecto
Resumen
Este skill crea y mantiene un glosario de términos del proyecto: un documento de referencia donde cada concepto tiene una definición única, consensuada y sin ambigüedades. El objetivo es que todo el equipo hable el mismo idioma: cuando alguien dice "usuario", todos entienden lo mismo.
Las malas interpretaciones entre miembros del equipo son una de las fuentes más frecuentes de bugs y retrabajos. Un glosario bien mantenido previene estos problemas de raíz.
Proceso
Paso 1: identificar términos clave
- Revisar el código fuente: nombres de entidades, modelos, servicios, tipos.
- Revisar la documentación existente: README, PRDs, historias de usuario.
- Identificar términos que se usan de forma inconsistente o ambigua.
- Preguntar al usuario si hay términos que generen confusión en el equipo.
Paso 2: crear el fichero de glosario
Crear `docs/glossary.md` con la siguiente estructura:
# Glosario del proyecto | Término | Definición | Contexto | No confundir con | |---------|-----------|----------|------------------| | Usuario | Persona registrada con cuenta activa | Backend, API | Visitante (no registrado) | | Sesión | Período de actividad autenticada | Auth | Conexión (socket) |
Cada entrada incluye:
- **Término**: la palabra o expresión exacta.
- **Definición**: qué significa en el contexto de este proyecto. Una frase, precisa.
- **Contexto**: dónde se usa (módulo, capa, dominio).
- **No confundir con**: términos similares que significan otra cosa.
Paso 3: vincular con el código
- Verificar que los nombres en el código (variables, clases, funciones) son coherentes con el glosario.
- Si hay inconsistencias, proponer renombramientos o documentar la discrepancia.
Paso 4: mantener actualizado
- Cada vez que se introduce un concepto nuevo en el proyecto, añadirlo al glosario.
- Si un término cambia de significado, actualizar la definición y notificar al equipo.
Qué NO hacer
- No incluir términos genéricos de programación (API, endpoint, función). Solo términos específicos del dominio del proyecto.
- No escribir definiciones largas. Una frase por término, dos como máximo.
- No crear el glosario y olvidarlo. Un glosario desactualizado es peor que no tener ninguno.
Plugin de Claude Code: 18 agentes especializados, 60 skills, 25 comandos, 13 hooks, memoria persistente, Memory UI local, quality gates, evidence guard, continuidad operativa y modo autopilot.
Repo: 686f6c61/alfred-dev
Other skills on alfred-dev.
- /alfred
Alias global /alfred para abrir el asistente contextual de Alfred Dev sin escribir el namespace completo. Activar solo cuando el usuario invoque explicitamente /alfred.
Open skill - /choose-stack
Usar para evaluar y elegir tecnologías con matriz de decisión ponderada. Activar cuando el usuario quiera elegir tecnología, comparar frameworks, decidir entre alternativas técnicas, construir una matriz de decisión, evaluar stack, seleccionar base de datos, elegir lenguaje o
Open skill - /design-system
Usar para diseñar la arquitectura de un sistema con diagramas y contratos. Activar cuando el usuario quiera diseñar arquitectura, definir componentes del sistema, crear un diagrama de flujo, establecer contratos entre módulos, planificar la estructura del proyecto o decidir cómo
Open skill - /evaluate-dependencies
Usar para evaluar si una dependencia merece la pena antes de añadirla. Activar cuando el usuario quiera añadir una librería, saber si merece la pena esta dependencia, evaluar un paquete antes de instalarlo, hacer npm install o pip install de algo nuevo, buscar alternativas a una
Open skill - /write-adr
Usar para documentar decisiones arquitectónicas como ADR. Activar cuando el usuario quiera documentar por qué se tomó una decisión, registrar alternativas descartadas, crear un ADR, un decision record, dejar constancia de una elección técnica o justificar una decisión de diseño
Open skill - /code-review
Usar para revisar código con foco en calidad, legibilidad y errores lógicos. También: revisar código, buscar errores, calidad del código, revisión de PR, pull request review.
Open skill

