Gemini Extensions & MCP — crear flujos personalizados

Referencias oficiales: Resumen de Extensions · Extension reference · Skills · Tools

Ruta de aprendizaje

1. Primeros pasos con Gemini CLI — instalación, autenticación y memoria
2. La ventaja de 1M tokens — trabajar con codebases completos — análisis de repos sin derroche
3. Gemini Extensions & MCP — crear flujos personalizados — empaquetar comandos, MCP y skills ← Estás aquí
4. Trusted Folders, Sandboxing y Restore — confianza, aislamiento y rollback
5. Headless Automation con Gemini CLI — scripts, CI y salida estructurada
6. Sub-agentes y Orquestación de Skills — delegación y flujos especialistas
7. Gemini Loop Seguro del Primer Día
8. Playbook Gemini para Entregas de Escala Semanal
9. Controles de Cambios de Alto Riesgo en Gemini
10. Manual Operativo de Gemini — Ritmo Escalable de Entrega por CLI
11. Gemini Playbook de Recuperación de Incidentes
12. Gemini Bucle de Hardening Post-Incidente
13. Gemini Simulacros de Resiliencia Caótica
14. Gemini Métricas de Resiliencia y SLO

Documentación oficial usada en este artículo

• Qué puede incluir una extension — Resumen de Extensions
• Manifest, commands, policies y settings sensibles — Extension reference
• Cómo se descubren y activan las skills — Skills

Extensions no significa "plugin pequeño"

Mucha gente oye “extension” y piensa en un complemento que solo agrega un comando. En Gemini CLI es bastante más amplio.

Según la documentación oficial, una extension puede empaquetar varias superficies de trabajo a la vez:

• prompts y commands reutilizables
• configuración de servidores MCP
• hooks y policies
• sub-agents
• agent skills
• settings propios de la extension

Por eso la idea correcta no es “añadir una función”, sino empaquetar una forma de operar. Una buena extension distribuye un flujo completo: cómo leer el repo, a qué sistemas externos conectarse y bajo qué guardrails trabajar.

Antes de crear una extension, elige la superficie mínima

No todo problema necesita packaging completo.

Necesidad	Mejor superficie	Motivo
Reglas estables del repo	GEMINI.md	Simplicidad y persistencia
Acceso a sistemas externos	MCP	Ideal para docs, bases de datos, tickets
Un procedimiento experto	Skill	Cambia el comportamiento sin empaquetar todo
Distribuir comandos, MCP y skills al equipo	Extension	Mejor para compartir una caja de herramientas

La secuencia sana suele ser:

1. fijar reglas en GEMINI.md
2. validar el flujo manualmente
3. convertir lo repetido en skill
4. empaquetarlo como extension cuando ya merece distribución

Una extension buena suele ser pequeña y explícita

Las mejores extensiones no intentan hacer de todo. Suelen tener cuatro piezas bien elegidas:

1. Uno o pocos commands para tareas frecuentes.
2. Uno o dos MCP con valor real.
3. Una skill enfocada para un tipo de trabajo concreto.
4. Policies o guardrails para evitar que el poder crezca sin control.

La reference oficial importa justamente por eso: ahí es donde aparecen detalles como exclusión de tools, settings sensibles, policies y nombres personalizados de archivos de contexto. Es la diferencia entre una demo vistosa y una pieza operable por un equipo.

Para muchos equipos, skill es la mejor puerta de entrada

El primer gran salto de productividad suele venir de una skill, no de una extension completa.

¿Por qué?

• tiene un alcance más fácil de auditar
• fija procedimiento, no solo texto bonito
• se reutiliza sin reexplicar todo
• obliga a definir qué significa “terminado”

Ejemplos útiles:

• locale-review para revisar paridad entre idiomas
• docs-qa para validar frontmatter y enlaces
• release-note-drafter para resumir cambios
• una variante interna de security-review

Cuando esa skill ya está probada, ahí sí tiene sentido envolverla dentro de una extension junto a commands y MCP.

La extension debe respetar el mismo modelo de confianza del repo

Las extensiones no viven fuera del sistema de trust y safety de Gemini CLI. Por eso conviene diseñarlas como si otra persona del equipo fuera a inspeccionarlas en frío.

Buenas prácticas:

• exponer comandos riesgosos de forma explícita
• priorizar helpers read-only primero
• tratar secrets y variables de entorno como configuración sensible
• documentar cómo cambia el workflow del repo
• evitar sorpresas tipo auto-approval silencioso

Una buena extension deja claro: qué añade, qué herramientas toca y qué riesgos introduce.

Patrón sano de adopción

1. Probar el flujo a mano

Primero, prompts y GEMINI.md. Nada de empaquetar antes de tiempo.

2. Subirlo a skill

Con skill-creator o con un SKILL.md escrito a mano, fija pasos, restricciones y criterios de revisión.

3. Añadir MCP solo cuando copiar y pegar ya molesta

Si el agente necesita siempre Jira, CMS o documentación interna, deja de pegar contexto y dale una conexión estructurada.

4. Empaquetar como extension cuando haya valor claro

En ese momento la extension ya tiene propósito: distribución, consistencia y onboarding.

Qué empaquetaría para AI Native Notes

Si este repo sigue creciendo, una buena extension de Gemini probablemente incluiría:

• un command para revisar paridad de slugs entre ko, en y es
• una skill de auditoría de contenido para frontmatter, enlaces y copy
• un MCP para inventario editorial o CMS en el futuro
• una policy estrecha para bloquear automatizaciones peligrosas de contenido

La idea es simple: empaquetar operaciones editoriales ya existentes, no inventar complejidad nueva.

Checklist antes de compartir una extension

• ¿El flujo ya es útil incluso sin extension?
• ¿Otra persona podría auditarla rápido?
• ¿Los tools riesgosos son opt-in?
• ¿El equipo entiende qué MCP y settings entran con la instalación?
• ¿De verdad no basta con GEMINI.md o una skill aislada?

Si las cuatro primeras respuestas son sí y la última es no, probablemente ya merece convertirse en extension.

Siguientes lecturas recomendadas

• Modelo seguro de operación: Trusted Folders, Sandboxing y Restore
• Delegación y especialistas: Sub-agentes y Orquestación de Skills
• Comparación de contexto externo: MCP Power Tools