Lo que trae el paquete
Las 11 skills
El paquete trae once skills. Una skill es un procedimiento en un formato que el agente carga solo cuando la tarea coincide con su descripción: el formato SKILL.md del estándar Agent Skills, con name y description en el frontmatter. init las instala en .agents/skills/; esta página dice qué hace cada una.
Hay dos tipos. Cinco son protocolos: los cuatro de la Parte III del manual en formato ejecutable, más protocolo-arranque, que corre antes que todos. Seis son de oficio: nacieron resolviendo problemas concretos en proyectos reales y resultaron transferibles.
Resumen
Sección titulada «Resumen»| Skill | Tipo | Se activa | Por defecto | Perfiles que la instalan | Pide interfaz |
|---|---|---|---|---|---|
protocolo-arranque |
Protocolo | Al principio: hay una idea o un requerimiento y todavía no hay PRD ni arquitectura | No | Todos, con entrevista | No |
protocolo-features |
Protocolo | Comando, módulo o feature nuevo, antes de escribir código | Sí | Todos | No |
protocolo-cambios |
Protocolo | Algo que ya funciona tiene que cambiar, incluidos los documentos de gobierno | Sí | Todos | No |
protocolo-cierre |
Protocolo | Al cerrar cualquier tramo con commits | Sí | Todos | No |
protocolo-ux |
Protocolo | Al diseñar un feature con interfaz, antes de codear | No | saas, landing, movil |
Sí |
test-fix |
Oficio | Después de implementar, o cuando la suite falla | Sí | Todos | No |
version-bump |
Oficio | Después de protocolo-cierre, para decidir el número de versión |
Sí | Todos | No |
information-architecture |
Oficio | Al crear, mover o renombrar un módulo, ruta o ítem de navegación | No | saas, movil |
Sí |
ux-writer |
Oficio | Al escribir cualquier texto visible | No | saas, landing, movil |
Sí |
ux-audit |
Oficio | Antes de mergear frontend | No | saas, landing, movil |
Sí |
i18n |
Oficio | Al agregar textos, plantillas o catálogos | No | Ninguno: sólo con --skills |
No |
Por defecto es lo que instala init sin entrevista y sin --skills: las cinco que no piden interfaz. Perfiles es lo que instala con entrevista, según la respuesta a «¿Qué clase de producto es?». Con --skills todas entran las once, y con --skills y una lista, exactamente ésas. El detalle está en Qué skills instala.
La columna «Se activa» es la misma que init escribe en el bloque de AGENTS.md. Las descripciones de cada sección son el description literal del SKILL.md, que es lo que el agente lee para decidir si la carga.
Protocolos
Sección titulada «Protocolos»protocolo-arranque
Sección titulada «protocolo-arranque»Protocolo de arranque de un proyecto: del requerimiento en bruto a los artefactos que el desarrollo necesita. Descubrimiento con benchmark de mercado y cuestionamiento exhaustivo hasta cerrar todo vacío, decisión de stack con su fila de ADR, y generación de PRD, arquitectura, specs y guía de diseño a partir de los templates del paquete, en el repo y no en un adjunto. Activar cuando el proyecto todavía no está definido: hay una idea, un requerimiento o notas de reunión, y no hay PRD ni arquitectura escritos. Para implementar un feature de un proyecto ya definido, usar protocolo-features.
Qué escribe, en este orden y cada documento desde su template: la fila de la decisión de stack en docs/ADR.md; docs/PRD.md; docs/ARQUITECTURA.md; docs/GUIA_DISENO.md y docs/COMPONENTES.md si el producto tiene interfaz; una spec por módulo en docs/specs/, o una sola del sitio en una landing; docs/TECH_NOTES.md. Al final completa AI-FIRST.md y AGENTS.md, este último fuera de las marcas de init. No instala dependencias ni corre generadores.
Lee primero AI-FIRST.md: el perfil decide qué artefactos escribe. Es la única que corre una sola vez por proyecto. Trae references/artefactos-por-perfil.md.
Se explica en La cadena de artefactos y se usa en Arrancar un producto desde cero. SKILL.md
protocolo-features
Sección titulada «protocolo-features»Protocolo de desarrollo de features nuevos: pre-implementación en 7 pasos (spec → inventario de reuso → diseño → UX → dependencias → contexto → secuencia), secuencia estricta de implementación por capas, validación incremental y checklists post-implementación. Comprueba Zonas Prohibidas antes de escribir código y manda al ADR las decisiones difíciles de revertir. Activar ANTES de implementar cualquier feature nuevo, página, módulo o endpoint. Para modificar algo que ya existe, usar protocolo-cambios.
Qué escribe: el código del feature, en la secuencia de capas del proyecto, y una fila en docs/ADR.md si el feature tomó una decisión difícil de revertir. Da por hecha la spec que deja protocolo-arranque. La entrevista de init le escribe la secuencia, los comandos de verificación y si hay agentes en paralelo.
Se explica en Protocolo de desarrollo de features y se usa en Desarrollar una feature. SKILL.md
protocolo-cambios
Sección titulada «protocolo-cambios»Protocolo para modificar features ya implementados: clasificación del cambio (corrección / ajuste / requerimiento / prioridad), flujo corto (1-2 archivos) vs. flujo completo (3+ archivos o cambio de schema), documento CHG-XXX obligatorio antes de tocar código, análisis de impacto, implementación por pasos en sesión limpia y cierre en el CHANGE_LOG. Distingue el cambio, que se archiva, de la decisión arquitectónica, que va al ADR y sobrevive. Activar cuando algo que YA funciona necesita cambiar.
Qué escribe: el documento del cambio en docs/changes/pending/, antes de tocar código, a partir del molde que trae en references/documento-de-cambio.md; ese documento es el que lee la verificación de alcance excedido. Al cerrar, su resumen en docs/changes/CHANGE_LOG.md, y el archivo de pending/ se elimina. Si el cambio es además una decisión arquitectónica, una fila en docs/ADR.md.
Se explica en Protocolo de gestión de cambios y se usa en Cambiar algo que ya funciona. SKILL.md
protocolo-cierre
Sección titulada «protocolo-cierre»Ejecuta la Fase A del protocolo de cierre de sesión: actualiza el SESSION_LOG, actualiza los docs afectados y enruta los aprendizajes al destino correcto según el árbol de decisión del AGENTS.md, incluida la fila del ADR cuando la sesión tomó una decisión arquitectónica. Activar al terminar cualquier sesión de implementación, antes de hacer commit. Las Fases B (verificar) y C (commit) las hace el humano.
Qué escribe: la entrada de la sesión en docs/SESSION_LOG.md, los documentos que la sesión dejó desactualizados, y cada aprendizaje en su destino: una fila en docs/ADR.md si se decidió algo, una cicatriz en docs/TECH_NOTES.md, un cambio cerrado en docs/changes/CHANGE_LOG.md. No hace el commit: verificar y firmar es del humano.
Se explica en Protocolo de cierre de sesión y se usa en Cerrar la sesión. SKILL.md
protocolo-ux
Sección titulada «protocolo-ux»Reglas de comportamiento e interacción: cuándo modal vs. página nueva, confirmaciones destructivas, navegación por capas (Browse → Create/Edit → Detail), patrones de tabla, formularios, toasts y los 4 estados obligatorios. Activar al DISEÑAR cómo debe comportarse un feature con interfaz — antes de escribir código. Define el QUÉ (comportamiento), no el CÓMO (implementación en el stack).
Qué escribe: nada propio. Es una skill de criterio: decide cómo se comporta la interfaz antes de que exista, y la implementación la hace protocolo-features. Con entrevista, init le escribe dónde están la guía de diseño y el inventario de componentes, o que todavía no existen.
Se explica en Protocolo UX. SKILL.md
Skills de oficio
Sección titulada «Skills de oficio»test-fix
Sección titulada «test-fix»Corre los tests del alcance que la sesión tocó —unitarios e integración siempre; de extremo a extremo (E2E) sólo bajo decisión explícita—, clasifica cada falla en mecánica (se corrige sin preguntar) o de negocio (se pregunta), aplica la corrección mínima, con un tope de dos rondas, y corre la suite completa una sola vez al final. Activar después de implementar un feature o un cambio, cuando la suite falla y hay que diagnosticar, o como verificación antes del cierre de sesión.
Qué escribe: la corrección mínima de cada falla mecánica, en el código o en la prueba. Una falla de negocio no la corrige: la reporta con la decisión que tiene que tomar el humano. Si tras dos rondas quedan fallas, para y reporta. La entrevista de init le escribe los comandos de la suite, de tipos y de lint.
Se presenta en Skills, hooks y gestión de contexto. SKILL.md
version-bump
Sección titulada «version-bump»Analiza los commits desde el último tag de versión, clasifica el cambio según SemVer (MAJOR/MINOR/PATCH), recomienda el bump apropiado y lo aplica actualizando los manifiestos del proyecto. Pide confirmación explícita antes de aplicar y NUNCA crea el tag — eso lo hace el humano. Activar al final de una sesión de implementación, después de protocolo-cierre.
Qué escribe: el número de versión en todos los manifiestos del proyecto, después de tu confirmación, y la fecha de la entrada del CHANGELOG en el mismo commit, si el proyecto lleva uno. Nunca el tag. La entrevista de init le escribe cuál es el manifiesto.
Se presenta en Skills, hooks y gestión de contexto. SKILL.md
information-architecture
Sección titulada «information-architecture»Arquitectura de información del producto: qué es una cosa, cómo se llama en cada capa y dónde vive. Reglas de naming (un concepto, un lema), navegación principal vs. configuración, agrupación, modelo de contenido (qué muestra una lista, cuándo un detalle lleva pestañas), relaciones entre módulos y cuándo un cambio de estructura es cambio formal. Activar al diseñar la ESTRUCTURA y el ETIQUETADO de un feature —crear un módulo o ruta, mover algo, renombrar, definir pestañas o columnas, agregar un ítem a la navegación— ANTES de protocolo-ux (comportamiento) y de tu ux-patterns (implementación).
Qué escribe: nada propio. Decide la estructura sobre la que protocolo-ux define el comportamiento. Un cambio de estructura en algo que ya está en producción lo manda a protocolo-cambios, y a docs/ADR.md si la razón se va a preguntar en seis meses.
Se menciona en Protocolo UX. SKILL.md
ux-writer
Sección titulada «ux-writer»Contenido, tono y voz del producto: glosario canónico de términos, registros por audiencia, reglas mecánicas de microcopy (botones, títulos, estados vacíos, errores, toasts, confirmaciones) y la regla de temperatura. Activar al escribir o editar CUALQUIER string visible — claves de i18n, plantillas de email y notificación, mensajes de error — y al auditar copy existente.
Qué escribe: los textos visibles, según sus reglas. Trae cinco referencias —glosario, voz, superficies, inglés y deuda conocida— que se adaptan al producto: el glosario de otro proyecto no es el tuyo.
Se presenta en Skills, hooks y gestión de contexto. SKILL.md
ux-audit
Sección titulada «ux-audit»Auditoría UX/UI en cuatro capas: análisis estático automatizable (tokens, iconos, i18n, tipografía), validación de patrones de interacción por lectura de código, análisis visual con navegador headless + axe, y juicio subjetivo delegado. Produce un reporte con severidades. Activar antes de mergear un PR de frontend, como gate previo a un release, o ante un reporte de inconsistencia visual.
Qué escribe: un reporte de auditoría con los hallazgos por severidad y una acción concreta por hallazgo. No corrige. Trae dos scripts para la primera capa, en checks/: el análisis estático y la fidelidad de los skeletons.
Se presenta en Skills, hooks y gestión de contexto. SKILL.md
Las tres capas de internacionalización: strings de interfaz en el frontend, plantillas bilingües de email y notificación en el backend, y campos de etiqueta por idioma en la base de datos para datos dinámicos (roles, estados, catálogos). Activar al agregar cualquier string visible, plantilla de comunicación, campo de catálogo, o al formatear fechas, números y monedas.
Qué escribe: los textos y etiquetas en todos los idiomas a la vez: ningún string nuevo se entrega en uno solo. Trae tres referencias, una por capa. Es la única que ningún perfil instala y para la que la entrevista no escribe adaptación.
Se menciona en GUIA_DISEÑO.md — Documentación evolutiva. SKILL.md
Cómo se relacionan
Sección titulada «Cómo se relacionan»protocolo-arranque ──> information-architecture ──> protocolo-ux ──> ux-audit │ ▲ └──────────> protocolo-features ──┬──────────┘ ├──> ux-writer ────> i18n └──> test-fix protocolo-cambios ───┘ protocolo-cierre ────────> version-bumpLas flechas indican «invoca» o «asume cargada», no un orden de instalación obligatorio: cada skill funciona por separado.
Si tu proyecto ya tiene una skill con el mismo nombre que una del paquete, init salta la del paquete entera. Qué hacer entonces está en Adoptar en un proyecto existente.