Como venimos escuchando en los últimos años, la IA ha llegado para quedarse. Y lo cierto es que cada día está más presente en nuestro trabajo como desarrolladores, integrándose de forma natural en nuestro flujo de desarrollo.
En este post veremos, paso a paso, cómo sacar el máximo partido al plugin de GitHub Copilot en Android Studio, centrándonos en sus opciones de personalización.
Puedes encontrar la documentación oficial de GitHub Copilot en este enlace. Es un buen punto de partida, pero probablemente te hayas encontrado con comportamientos poco claros o documentados.
En este artículo veremos esos puntos con ejemplos reales y conclusiones prácticas basadas en el uso diario.
Antes de empezar
Para poder beneficiarnos de todo lo que veremos en este artículo, es necesario contar con una licencia de GitHub Copilot (Copilot Pro o superior para cuentas personales, o cualquiera de las licencias para empresa).
También es importante tener instalado y actualizado a la última versión el plugin de GitHub Copilot en tu IDE de JetBrains (Android Studio, IntelliJ IDEA, etc.)
Este artículo se basa en la versión 1.5.62 del plugin de GitHub Copilot, por lo que algunas opciones pueden variar con el tiempo.
Empezamos
Antes de entrar en detalle en cada una de las opciones de personalización de GitHub Copilot, vamos a poner en contexto cómo se configuran dentro de Android Studio.
Para ello, abrimos los ajustes del IDE y nos dirigimos a:
Tools > GitHub Copilot > Customizations
En esta sección encontramos todas las opciones relacionadas con la personalización del plugin de GitHub Copilot en los IDEs de JetBrains, que son las que analizaremos a lo largo de este artículo.
Como se puede observar en la captura, Copilot ofrece distintas secciones de personalización. Antes de analizar cada una de ellas, es importante entender un concepto que se repite en casi todas: Workspace y Global.
Workspace vs Global
Estas dos opciones definen el alcance de las personalizaciones que configuremos.
Workspace
La opción Workspace aplica las personalizaciones únicamente al proyecto actual. Al seleccionarla, Android Studio crea un fichero dentro del propio proyecto bajo la carpeta .github/.
Este fichero puede versionarse y subirse al repositorio, lo que permite que todo el equipo se beneficie de las mismas personalizaciones de Copilot.
Este enfoque es ideal para definir reglas y convenciones propias del proyecto, por ejemplo:
- Evita la complejidad innecesaria (KISS) y la duplicación (DRY).
- Garantizar el cumplimiento legal y evita problemas de licencias.
Global
La opción Global, por el contrario, crea un fichero de configuración local en nuestro ordenador, que se aplica a todos los proyectos que tengamos en ese entorno.
Estas personalizaciones no se comparten con el repositorio y solo afectan a nuestra experiencia personal con el plugin.
Es la opción adecuada para preferencias individuales como, por ejemplo:
- Responde siempre en alemán.
- Prefiero respuestas concisas y bien estructuradas.
- Al explicar conceptos técnicos, incluye un ejemplo visual.
¿Cuál elegir?
Utiliza Workspace cuando las personalizaciones formen parte del proyecto y puedan compartirse con el resto del equipo.
Utiliza Global cuando se trate de preferencias personales que quieras reutilizar en distintos proyectos sin afectar a otros desarrolladores.
Con esta diferencia clara, ya podemos entrar en detalle en cada una de las opciones de personalización de GitHub Copilot.
A partir de este punto, los ejemplos del artículo estarán definidos a nivel de Workspace, al ser el caso más habitual en proyectos de equipo. No obstante, todas las configuraciones pueden aplicarse también a nivel Global según tus necesidades.
Ten en cuenta que ambos niveles pueden coexistir. En ese caso, evita definir instrucciones contradictorias, ya que pueden provocar comportamientos inesperados o que Copilot ignore alguna de ellas.
Copilot Instructions
Esta es una de las personalizaciones más básicas y relevantes que podemos definir en nuestros proyectos.
El fichero de Copilot Instructions permite establecer instrucciones generales que GitHub Copilot tendrá en cuenta al generar código dentro del proyecto. Estas instrucciones actúan como reglas globales y pueden definirse tanto a nivel de Workspace como de Global.
Aunque la estructura del fichero no influye directamente en el comportamiento de Copilot, sí es recomendable organizar las instrucciones en bloques temáticos para mejorar su legibilidad y mantenimiento.
A continuación, se muestra un ejemplo de instrucciones definidas a nivel de proyecto:
## Contexto del repositorio
Este repositorio contiene una aplicación Android modular, escrita en Kotlin.
### Directrices generales
– Seguir una arquitectura limpia: separar las capas de Presentación, Dominio y Datos.
– Todo el código nuevo debe escribirse en Kotlin. Migrar el código Java a Kotlin siempre que sea posible.
### Directrices de casos de uso
– Toda la lógica de negocio debe estar en clases de tipo UseCase o BL.
– Los UseCases solo deben acceder a repositorios de su propio módulo.
### Directrices de testing unitario
– Las clases de test deben usar el sufijo Test siguiendo el patrón [NombreDeClase]Test.
– Usar Mockito para simular dependencias mediante la función mock<>() en lugar de la anotación @Mock.
Instruction files
Esta personalización permite definir instrucciones asociadas a ficheros o contextos específicos, en lugar de aplicar reglas generales a todo el proyecto.
Podemos crear tantos Instruction files como necesitemos. La única regla es que el nombre del fichero siga el patrón:
[nombre].instructions.md
La recomendación general es separar las instrucciones en distintos ficheros según su propósito, por ejemplo: revisión de código, validaciones de API pública, convenciones de testing, etc. Esto facilita el mantenimiento y evita mezclar reglas no relacionadas.
Estructura del fichero y frontmatter
Los instruction files utilizan un frontmatter en la parte superior del fichero. Esta sección permite definir metadatos que controlan cuándo y cómo se aplican las instrucciones.
A continuación, se muestra un ejemplo práctico, extraído de un caso real utilizado en Mística, el Design System público de Telefónica, donde es especialmente importante detectar breaking changes para no afectar a los consumidores de la librería:
—
applyTo: «library/**/*» excludeAgent: «coding-agent»
—
Por favor, realiza tu revisión habitual de Pull Request.
- Además, comprueba posibles breaking changes únicamente dentro del módulo «library», prestando especial atención a:
- Eliminación o cambio de nombre de clases, interfaces, enums, métodos, propiedades o constantes públicas.
- Eliminación o modificación de valores de enums.
- Cambios en las firmas de métodos (parámetros, tipos, nullabilidad, valores por defecto, tipos de retorno).
- Cambios de visibilidad que reduzcan la accesibilidad (por ejemplo: public → internal/private/protected).
Cuando se detecte un posible breaking change únicamente en el módulo de la librería:
- Crea un comentario separado explicando por qué puede romper a los consumidores existentes.
- Recuerda al autor que aplique la etiqueta «Breaking change» al PR.
Configuración del frontmatter
Actualmente, los instruction files admiten únicamente dos propiedades en el frontmatter.
applyTo
Define los ficheros o rutas que activan estas instrucciones.
Este campo es obligatorio: si no se especifica, las instrucciones serán ignoradas.
Se pueden indicar múltiples rutas utilizando patrones separados por comas.
excludeAgent
Es opcional y permite excluir agentes concretos de GitHub Copilot. Se pueden excluir los siguientes agentes:
- coding-agent: responsable de la generación de código.
- code-review: responsable de la revisión de código y generación de comentarios.
Un detalle clave sobre applyTo
Aquí hay un comportamiento importante que no queda claro en la documentación oficial.
Aunque pueda parecer que applyTo limita las instrucciones únicamente a los ficheros indicados, en la práctica actúa como un disparador. Cuando se modifica alguno de los ficheros definidos en applyTo, las instrucciones de ese fichero se activan y se suman al resto de instrucciones activas, tanto generales como de otros Instruction files.
Es decir, las instrucciones no se aplican únicamente a esos ficheros, sino que pasan a formar parte del conjunto de reglas activas durante esa operación.
Por este motivo, en el ejemplo anterior es imprescindible indicar explícitamente que los comentarios sobre breaking changes deben limitarse a la API pública. De lo contrario, Copilot podría aplicar esas comprobaciones a cualquier fichero revisado, aunque no pertenezca al applyTo.
Git Commit Instructions
Esta personalización permite definir cómo GitHub Copilot genera los mensajes de commit.
A continuación, se muestra un ejemplo de un fichero de Git Commit Instructions donde se indica a Copilot que tenga en cuenta el nombre de la rama a la hora de generar el mensaje:
Estás generando un mensaje de commit para el proyecto actual.
Reglas:
- Usa el nombre de la rama actual como contexto para extraer un ticket o identificador cuando esté disponible.
- Comienza el mensaje de commit con el identificador extraído. Si no se encuentra ninguno, utiliza un marcador genérico.
- Utiliza un verbo corto y orientado a la acción (por ejemplo: Add, Update, Remove).
- Escribe una descripción concisa y de alto nivel del cambio.
- No incluyas detalles de implementación.
- No menciones ficheros, clases o métodos concretos.
- Céntrate en la intención del cambio.
Ejemplos:
- PROJ-1234 Update error handling behavior
- PROJ-567 Add support for dark mode
- PROJ-XXX Remove deprecated feature
Uso en Android Studio
Una vez definidas las instrucciones, el mensaje de commit se genera desde la ventana de commits de Android Studio, accesible desde:
Git > Commit…
En esta ventana aparece el icono de GitHub Copilot. Al pasar el ratón por encima se muestra la opción “Generate Commit Message”. Al pulsarla, Copilot genera m mm-jj-h-i – mmnbvz< xbc nb,.x automáticamente un mensaje de commit teniendo en cuenta las instrucciones configuradas y los cambios actuales.
Comportamiento a tener en cuenta
Hay un detalle importante sobre cómo Copilot genera el mensaje:
- Si hay ficheros marcados para el commit, el mensaje se generará solo a partir de esos cambios.
- Si no hay ningún fichero marcado, el mensaje se basará en todos los ficherosmodificados que aparecen en la ventana de commit.
Este comportamiento es relevante cuando trabajamos con cambios grandes o commits parciales, ya que influye directamente en el contenido del mensaje generado.
Prompt Files
Esta opción permite definir prompts personalizados que podemos reutilizar directamente en el chat integrado de GitHub Copilot mediante la barra de comandos /.
El propio plugin de GitHub Copilot para Android Studio ya incluye varios prompts predefinidos. Basta con escribir / en el chat para que aparezca la lista de comandos disponibles.
Prompts personalizados
Cuando creamos nuevos prompt files, estos se integran automáticamente en esta lista junto a los prompts que incluye el plugin por defecto.
En el siguiente ejemplo se define un prompt personalizado para generar previews de Composables, pensado para automatizar una tarea recurrente durante el desarrollo:
—
description: Genera @Preview de Compose con estados de ejemplo y casos límite
—
# Generado de Previews para Compose
Eres un ingeniero Android senior (Jetpack Compose).
Dado el código Compose seleccionado:
- Crea una o más funciones @Preview.
- Proporciona estados o datos de ejemplo realistas.
- Incluye al menos una preview de caso límite (vacío / cargando / error).
- Limita cada preview a un propósito concreto y evita añadir más de lo necesario
Resultado:
- Solo código Kotlin.
- Utiliza valores de ejemplo estables (nada aleatorio).
Una vez definido y guardado el fichero, el prompt aparece disponible en el chat de GitHub Copilot al escribir /, junto al resto de comandos integrados.
Un detalle importante sobre las descripciones
En los IDEs de JetBrains, los prompt files permiten definir una descripción en el frontmatter que se muestra directamente en el diálogo de comandos al escribir /. Este comportamiento no está documentado oficialmente para Android Studio, pero funciona de forma consistente en la práctica.
Es importante destacar que, aunque en otros entornos como Visual Studio Code la documentación oficial describe más opciones de configuración en el frontmatter de los prompts, en Android Studio esas opciones no tienen efecto. Actualmente, la única configuración soportada y funcional es la descripción.
Uso combinado con contexto
Estos prompts se pueden ejecutar teniendo en cuenta ficheros de contexto, por ejemplo, archivos que contengan composables. Al ejecutar el comando en modo agente, Copilot genera automáticamente las previews siguiendo las instrucciones definidas en el prompt.
Lo interesante de este enfoque es que permite automatizar tareas recurrentes con muy poco esfuerzo: una vez definido el prompt y el contexto adecuado, apenas es necesario escribir nada para obtener el resultado deseado.
Chat Agents
Los Chat Agents permiten definir modos de chat personalizados para GitHub Copilot, ajustando de forma persistente cómo debe comportarse el chat según el tipo de tarea que estemos realizando.
A diferencia de otras personalizaciones, un Chat Agent no define una acción concreta, sino un rol y un criterio de respuesta que se mantiene activo durante toda la conversación.
A continuación, se muestra un ejemplo de un Chat Agent enfocado a accesibilidad, pensado para revisar código e interfaces desde una perspectiva de accesilbidad.:
—
description: «Experto de accesibilidad»
tools: [«semantic_search», «read_file»]
—
Actúa como un experto en accesibilidad para aplicaciones Android.
Céntrate en las directrices WCAG y en las buenas prácticas de accesibilidad en Android.
Revisa los componentes de la interfaz en aspectos como contraste, áreas táctiles, semántica y compatibilidad con lectores de pantalla.
Proporciona recomendaciones claras y accionables, y destaca posibles problemas de accesibilidad.
Estructura del Chat Agent
Antes de ver cómo se utiliza este agente dentro del plugin, vamos a analizar la estructura de un Chat Agent y las opciones que nos ofrece.
Frontmatter
En la parte superior se define el frontmatter, donde se configuran los metadatos del agente:
- description: Texto descriptivo que identifica el agente en la interfaz del chat.
- tools: Lista de herramientas que el agente puede utilizar durante la conversación.
En Android Studio, justo encima de este campo aparece el enlace “Configure Tools…”, que abre el diálogo del IDE para gestionar las herramientas disponibles.
Desde ahí podemos:
- Seleccionar las herramientas integradas que incluye el plugin.
- Añadir herramientas adicionales definidas mediante MCP, según la configuración del entorno.
El uso y disponibilidad de estas herramientas depende del soporte del propio IDE y del contexto en el que se ejecute Copilot.
Definición del comportamiento
Debajo del frontmatter se define el comportamiento del agente.
Aquí se describe:
- El rol que debe adoptar Copilot.
- El enfoque de las respuestas.
- Las áreas en las que debe centrarse.
- Cualquier restricción o criterio específico.
Este bloque actúa como una instrucción persistente mientras usamos nuestro Chat Agent.
Uso en el plugin
Una vez definido el Chat Agent, este aparece disponible en el chat de GitHub Copilot y puede seleccionarse como modo de conversación.
A partir de ese momento, todas las interacciones del chat seguirán el comportamiento definido por el agente hasta que se cambie o se desactive.
Chat Agents vs Prompts
Una de las confusiones más habituales al trabajar con GitHub Copilot es pensar que los Chat Agents y los prompt files sirven para lo mismo. Aunque se parecen, su propósito es distinto.
- Usa un prompt cuando quieras ejecutar una tarea concreta.
- Usa un Chat Agent cuando quieras cambiar el rol o el comportamiento del chat durante una conversación.
Para cerrar
Si has llegado hasta aquí, ¡enhorabuena! Ya tienes una visión bastante completa de cómo se pueden personalizar las distintas piezas de GitHub Copilot en Android Studio y, sobre todo, de cuándo tiene sentido usar cada una.
A partir de ahora, el siguiente paso es tuyo: probar, ajustar y decidir qué configuraciones encajan mejor en tu flujo de trabajo o en el de tu equipo. No se trata de usarlo todo, sino de quedarte con aquello que realmente te ayude a trabajar mejor. Muchas gracias por leer y happy coding!
