Flujo de trabajo de IA confiable con GitHub Copilot: guía completa con ejemplos

¡Hola! Hoy comparto una guía rápida sobre cómo configurar un proyecto para trabajar con GitHub Copilot.

Flujo de trabajo de IA confiable con GitHub Copilot: guía completa con ejemplos

Esta guía muestra cómo crear flujos de trabajo de IA predecibles y reproducibles en su repositorio e IDE/CLI utilizando primitivas de agente e ingeniería de contexto. Aquí encontrará la estructura de archivos, plantillas listas para usar, reglas de seguridad y comandos.

⚠️ Nota: La funcionalidad de los archivos de instrucciones y el modo de agente en IDE/CLI puede cambiar; adapte esta guía a las versiones específicas de Copilot y VS Code que utilice.

1) Resumen: de qué consta el flujo de trabajo

El objetivo principal es dividir el trabajo del agente en pasos transparentes y hacerlo controlable. Para ello, existen las siguientes herramientas:

• Instrucciones personalizadas (.github/copilot-instructions.md) — reglas globales del proyecto (cómo compilar, cómo probar, estilo de código, políticas de PR).
• Instrucciones específicas de ruta (.github/instructions/*.instructions.md) — reglas para áreas específicas, aplicadas a través de applyTo (patrones glob).
• Modos de chat (.github/chatmodes/*.chatmode.md) — modos de chat especializados (por ejemplo, Plan/Frontend/DBA) con herramientas y modelo fijos.
• Archivos de instrucciones (.github/prompts/*.prompt.md) — escenarios/"programas" reutilizables para tareas típicas (revisión, refactorización, generación).
• Ayudantes de contexto (docs/*.spec.md, docs/*.context.md, docs/*.memory.md) — especificaciones, referencias y memoria del proyecto para un contexto preciso.
• Servidores MCP (.vscode/mcp.json o a través de la UI) — herramientas y recursos externos que el agente puede utilizar.

2) Estructura de archivos del proyecto

La siguiente estructura se corresponde con las herramientas descritas anteriormente y ayuda a construir un flujo de trabajo completo para los agentes.

1.github/
2  copilot-instructions.md
3  instructions/
4    backend.instructions.md
5    frontend.instructions.md
6    actions.instructions.md
7  prompts/
8    implement-from-spec.prompt.md
9    security-review.prompt.md
10    refactor-slice.prompt.md
11    test-gen.prompt.md
12  chatmodes/
13    plan.chatmode.md
14    frontend.chatmode.md
15.vscode/
16  mcp.json
17docs/
18  feature.spec.md
19  project.context.md
20  project.memory.md

3) Archivos y su propósito: explicación técnica

Ahora examinaremos cada herramienta por separado y su función. A continuación se explica cómo funciona todo internamente: qué son estos archivos, por qué existen, cómo afectan a la comprensión de la tarea por parte del agente y en qué orden se combinan / reemplazan. Los ejemplos de código a continuación corresponden a la especificación.

Orden de combinación de reglas y configuraciones: Frontmatter del prompt → Modo de chat → Instrucciones del repo/ruta → Valores predeterminados.

Y ahora, veamos cada herramienta por separado.

3.1. Reglas globales — .github/copilot-instructions.md

Qué es: Un archivo Markdown con reglas cortas y verificables: cómo compilar, cómo probar, estilo de código y políticas de PR.

Propósito: Que todas las respuestas se basen en un conjunto unificado de estándares (sin duplicación en cada prompt).

Cómo funciona: El archivo se convierte automáticamente en parte del contexto del sistema para todas las consultas dentro del repositorio. No tiene applyTo (sobre esto, más adelante), se aplica en todas partes.

Ejemplo mínimo:

1# Estándares de codificación del repositorio
2- Compilación: `npm ci && npm run build`
3- Pruebas: `npm run test` (cobertura ≥ 80%)
4- Lint/Verificación de tipos: `npm run lint && npm run typecheck`
5- Commits: Conventional Commits; mantenga los PR pequeños y enfocados
6- Documentación: actualice `CHANGELOG.md` en cada PR de lanzamiento

Consejos.

1. Mantenga los puntos cortos.
2. Evite frases generales.
3. Incluya solo lo que pueda afectar al resultado (compilación/pruebas/lint/tipos/política de PR).

3.2. Instrucciones para rutas específicas — .github/instructions/*.instructions.md

Qué es: Reglas modulares con applyTo en el frontmatter YAML — patrones glob de archivos para los que se aplican.

Propósito: Diferenciar estándares en diferentes áreas (frontend/backend/CI). Permite controlar el contexto según el tipo de tarea.

Cómo funciona: Al procesar una tarea, Copilot encuentra todos los *.instructions.md cuyo applyTo coincide con el contexto actual (archivos que está discutiendo/editando). Las reglas coincidentes se añaden a las globales.

Ejemplo:

1---
2applyTo: "apps/web/**/*.{ts,tsx},packages/ui/**/*.{ts,tsx}"
3---
4- React: componentes de función y hooks
5- Estado: Zustand; obtención de datos con TanStack Query
6- Estilo: Tailwind CSS; evite estilos en línea excepto en casos dinámicos
7- Pruebas: Vitest + Testing Library; evite snapshots inestables

Nota.

1. Evite duplicar reglas globales existentes.
2. Asegúrese de que el glob apunte realmente a las rutas deseadas.

3.3. Modos de chat — .github/chatmodes/*.chatmode.md

Qué es: Archivos de configuración que definen el modo de operación del agente para el diálogo: descripción corta, modelo (si es necesario) y lista de herramientas permitidas.

Propósito: Dividir las fases de trabajo (planificación/frontend/DBA/seguridad) y limitar las herramientas en cada etapa. Esto hace que los resultados sean más predecibles.

Estructura del archivo:

1---
2description: "Planificar - analizar código/especificaciones y proponer un plan; herramientas de solo lectura"
3model: GPT-4o
4tools:[ "search/codebase"]
5---
6En este modo:
7- Produzca un plan estructurado con riesgos e incógnitas
8- No edite archivos; genere una lista de tareas concisa en su lugar

Cómo funciona:

• El modo de chat se aplica al chat actual en el IDE.
• Si activa un archivo de prompt, su frontmatter tiene prioridad sobre el modo de chat (puede cambiar el modelo y limitar tools).
• La lista efectiva de herramientas permitidas es: herramientas del modo de chat, limitadas por las herramientas del prompt y los flags de CLI --allow/--deny.

Gestión y cambio:

• En el IDE (VS Code):

1. Abra el panel de Copilot Chat.
2. En la barra superior, seleccione el modo de chat deseado de la lista desplegable (la lista se construye a partir de .github/chatmodes/*.chatmode.md + modos integrados).
3. El modo se aplica solo a esta rama de diálogo. Para cambiar, seleccione otro o cree una nueva rama con el modo deseado.
4. Compruebe el modo activo en el encabezado/panel de conversación; en Referencias verá el archivo *.chatmode.md.

• En la CLI: (un poco de hackeo, es mejor a través de prompts)

  • Generalmente no hay un flag CLI especial para cambiar de modo; codifique las restricciones deseadas en el frontmatter del archivo de prompt y/o a través de los flags --allow-tool/--deny-tool.
  • Puede indicar en la primera línea: "Use el modo de chat i18n." — si la versión lo admite, el agente puede cambiar; si no, el frontmatter del prompt seguirá aplicando las restricciones de herramientas.

• Sin cambio de modo: ejecute el prompt con los tools: deseados en el frontmatter — esto limitará las herramientas independientemente del modo de chat.

Diagnóstico: si el agente utiliza herramientas "extras" o no ve las necesarias, compruebe: (1) qué modo de chat está seleccionado; (2) tools en el frontmatter del prompt; (3) flags de CLI --allow/--deny; (4) Referencias en la respuesta (archivos *.chatmode.md/*.prompt.md visibles).

3.4. Archivos de prompt — .github/prompts/*.prompt.md

Qué es: Archivos de escenario para tareas reutilizables. Constan de frontmatter YAML (configuración) y cuerpo (instrucciones/pasos/criterios de aceptación). Se invocan en el chat a través de /nombre o a través de la CLI.

Cuándo usar: Cuando se necesita un proceso predecible y automatizable: revisión de PR, generación de pruebas, implementación de una función según especificación, etc.

Estructura del frontmatter

• description — propósito corto del escenario.
• mode — ask (Preguntas y respuestas, sin edición de archivos) · edit (edición local de archivos abiertos) · agent (proceso de varios pasos con herramientas).
• model — perfil de modelo deseado.
• tools — lista de herramientas permitidas para el escenario (limita incluso lo que permite el modo de chat).

Algoritmo de ejecución (secuencia)

1. Dónde ejecutar:

• En el chat: introduzca /nombre-del-prompt y los argumentos en el campo de mensaje.
• En la CLI: invoque copilot y pase la cadena /nombre-del-prompt … (interactivamente o a través de heredoc / flag -p).

2. Recopilación de contexto: Copilot construye el contexto de ejecución en el siguiente orden: instrucciones-del-repo → instrucciones-de-ruta (applyTo) → modo-de-chat → frontmatter-del-prompt (el frontmatter del prompt tiene la prioridad más alta y puede limitar las herramientas/cambiar el modelo).

3. Análisis de parámetros (dónde y cómo):

   • En el chat: los parámetros van en el mismo mensaje después del nombre, por ejemplo: /security-review prNumber=123 target=apps/web.
   • En la CLI: los parámetros van en la misma cadena /… en stdin o después del flag -p.
   • Dentro del archivo de prompt, son accesibles como ${input:nombre}. Si falta un parámetro obligatorio, el prompt puede solicitarlo mediante texto en el diálogo.

4. Permiso de herramientas:

• La lista efectiva de herramientas permitidas: herramientas del modo de chat, limitadas por las herramientas del prompt y los flags de CLI --allow/--deny.
• Si una herramienta está prohibida, el paso correspondiente se omite o requiere confirmación / cambio de política.

5. Ejecución de pasos del cuerpo del prompt: el agente sigue estrictamente el orden de los pasos, ejecutando solo lo permitido por las políticas/herramientas (búsqueda en la base de código, generación de diff, ejecución de pruebas, etc.). Para acciones potencialmente arriesgadas, solicita confirmación.

6. Puertas de validación: al final, el prompt ejecuta comprobaciones (compilación/pruebas/lint/verificación de tipos). Si la comprobación falla, el agente devuelve una lista de problemas y propone los siguientes pasos (sin fusión automática/guardado de cambios).

7. Dónde aparece el resultado (qué se ve y dónde):

• Respuesta principal — en el panel de chat (IDE) o en stdout (CLI): tablas, listas, informes de texto, bloques de código con diff.
• Cambios en archivos — en su árbol de trabajo: en el IDE se ven diff/parches propuestos; en la CLI los archivos se modifican localmente (si las herramientas lo permiten).
• Artefactos adicionales — por ejemplo, un comentario en el PR, si las herramientas de GitHub están permitidas y el prompt lo indica.

Formato de salida y comprobaciones (recomendaciones)

• Siempre especifique el formato de salida (por ejemplo, tabla "issue | file | line | severity | fix").
• Agregue puertas de validación: compilación/pruebas/lint/verificación de tipos; requiera unified-diff para los cambios propuestos; lista de TODO para cuestiones no resueltas.

Ejemplo de archivo de prompt completo

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Implementar una función a partir de una especificación'
6---
7Objetivo: Implementar la función descrita en @docs/feature.spec.md.
8
9Pasos:
101) Leer @docs/feature.spec.md y producir un plan de implementación corto (viñetas)
112) Listar archivos a añadir/modificar con rutas
123) Proponer parches de código como diff unificado; preguntar antes de instalar nuevas dependencias
134) Generar pruebas mínimas y ejecutarlas (informar resultados)
14
15Puertas de validación:
16- La compilación, las pruebas, el lint/verificación de tipos deben pasar
17- La salida incluye el diff final y una lista de TODO para cualquier cosa pospuesta
18- Si alguna puerta falla, devuelva un plan de remediación en lugar de "hecho"

Antipatrones

• Descripciones vagas: mantenga description en 1–2 líneas.
• Falta de formato de salida.
• Demasiadas herramientas: permita solo las necesarias (tools).

Inicio rápido

• Chat: /implement-from-spec
• CLI: copilot <<<'/implement-from-spec' o copilot -p "Run /implement-from-spec"

3.5. Archivos de contexto — specs/context/memory

Qué es: Archivos Markdown auxiliares (no tipos especiales) a los que se hace referencia a través de @ en el diálogo/prompt. Normalmente se almacenan como documentación.

• docs/*.spec.md — definiciones precisas de tareas (objetivo, criterios de aceptación, casos extremos, no-objetivos).
• docs/*.context.md — referencias cortas (políticas de API, seguridad, guía de estilo de UI, SLA).
• docs/*.memory.md — "registro de decisiones" con fechas y justificaciones, para que el agente no vuelva a cuestiones resueltas hace tiempo.

Ejemplo:

1# Función: Exportar informe a CSV
2Objetivo: Los usuarios pueden exportar la tabla filtrada a CSV.
3Criterios de aceptación:
4- Botón "Exportar CSV" en /reports
5- El servidor genera el archivo ≤ 5s para 10k filas
6- El orden/encabezados de las columnas coinciden con la UI; valores independientes de la localización
7Casos extremos: valores vacíos, números grandes, caracteres especiales
8No objetivos: XLSX, filtros simultáneos de varias columnas

3.6. MCP — .vscode/mcp.json

Qué es: Configuración de servidores del Protocolo de Contexto de Modelo (por ejemplo, GitHub MCP) que proporcionan herramientas al agente.

Propósito: Permitir al agente leer PR/issues, ejecutar pruebas, interactuar con bases de datos/navegadores, dentro de los permisos permitidos.

Ejemplo:

1{
2  "servers": {
3    "github-mcp": {
4      "type": "http",
5      "url": "https://api.githubcopilot.com/mcp"
6    }
7  }
8}

Seguridad. Conecte solo servidores de confianza; utilice listas de allowed/deny de herramientas en prompts/modos de chat/CLI.

3.7. Orden general de combinación de contexto y prioridades (reglas y herramientas)

1. Instrucciones: copilot-instructions + todos los *.instructions.md con applyTo que coincida con las rutas actuales. Una instrucción específica se añade al contexto general.
2. Modo de chat: limita el conjunto de herramientas y (si es necesario) el modelo para la sesión.
3. Frontmatter del prompt: tiene la prioridad más alta; puede limitar herramientas y anular el modelo.
4. Contexto: todo lo que se menciona a través de @, se tiene en cuenta garantizado por el modelo.

Diagnóstico. Compruebe la sección Referencias en las salidas — indica qué archivos de instrucciones se tuvieron en cuenta y qué prompt se ejecutó.

3.8. Ejemplo: ciclo completo de i18n con Goman MCP (creación/actualización/eliminación)

A continuación se presenta el proceso exacto y las plantillas para garantizar lo siguiente: (a) al crear componentes UI, las claves de localización se crean/actualizan en Goman; (b) al eliminar componentes, se detectan las entradas no utilizadas y (tras confirmación) se eliminan.

Los fragmentos de código y el frontmatter están en inglés.

3.8.1. Configuración de MCP — conexión de Goman

/.vscode/mcp.json

1{
2  "servers": {
3    "goman-mcp": {
4      "type": "http",
5      "url": "https://mcp.goman.live/mcp",
6      "headers": {
7        "apiKey": "<TU_API_KEY>",
8        "applicationid": "<TU_APPLICATION_ID>"
9      }
10    }
11  }
12}

3.8.2. Reglas de Repo/Ruta — imposición de i18n por defecto

/.github/instructions/frontend.instructions.md (adición)

1---
2applyTo: "apps/web/**/*.{ts,tsx}"
3---
4- Todas las cadenas dirigidas al usuario **deben** usar claves i18n (sin texto codificado en JSX/TSX)
5- Nomenclatura de claves: `<area_del_componente_ui>.<n>` (ej. `ui_button_primary.label`)
6- Al crear componentes, ejecute `/i18n-component-scaffold` y confirme el código y las claves creadas
7- Al eliminar componentes, ejecute `/i18n-prune` y confirme la eliminación de claves no utilizadas

3.8.3. Modo de chat — herramientas i18n limitadas

/.github/chatmodes/i18n.chatmode.md

1---
2description: "i18n - gestionar claves de localización a través de Goman MCP; aplicar no tener cadenas codificadas"
3model: GPT-4o
4tools:
5  - "files"
6  - "goman-mcp:*"
7---
8En este modo, prefiera:
9- Crear/actualizar claves en Goman antes de escribir código
10- Comprobar claves existentes y reutilizarlas
11- Producir una tabla de cambios (creados/actualizados/omitidos)

3.8.4. Prompt — scaffolding de componente + claves en Goman

/.github/prompts/i18n-component-scaffold.prompt.md

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Scaffold de un componente React con claves i18n sincronizadas con Goman'
6---
7Entradas: componentName, namespace (ej. `ui.button`), path (ej. `apps/web/src/components`)
8
9Objetivo: Crear un componente React y asegurar que todas las cadenas visibles por el usuario utilicen claves i18n almacenadas en Goman.
10
11Pasos:
121) Planificar la estructura del componente y listar todas las cadenas visibles por el usuario
132) Para cada cadena, proponer una clave bajo `${namespace}`; reutilizar si existe
143) Usando Goman MCP, crear/actualizar traducciones para los idiomas: en, be, ru (los valores pueden ser marcadores de posición)
154) Generar el componente usando `t('<key>')` y exportarlo; añadir una prueba básica
165) Salir con una tabla Markdown: key | en | be | ru | action(created/updated/reused)
17
18Puertas de validación:
19- Sin literales codificados en el .tsx producido
20- Confirmar que las acciones de Goman tuvieron éxito (informar respuestas de herramientas)
21- Las pruebas y la verificación de tipos pasan

Ejemplo de código del componente:

1import { t } from '@/i18n';
2import React from 'react';
3
4type Props = { onClick?: () => void };
5
6export function PrimaryButton({ onClick }: Props) {
7  return (
8    <button aria-label={t('ui.button.primary.aria')} onClick={onClick}>
9      {t('ui.button.primary.label')}
10    </button>
11  );
12}

3.8.5. Prompt — eliminación de claves no utilizadas al eliminar componentes

/.github/prompts/i18n-prune.prompt.md

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Encontrar y podar claves de localización no utilizadas en Goman después de eliminaciones de código'
6---
7Entradas: pathOrDiff (ej. una ruta de componente eliminada o un número de PR)
8
9Objetivo: Detectar claves que ya no se referencian en la base de código y eliminarlas de Goman después de la confirmación.
10
11Pasos:
121) Calcular el conjunto de elementos UI eliminados/renombrados (escanear diff de git o rutas proporcionadas)
132) Inferir claves candidatas por namespace (ej. `ui.<component>.*`) y verificar referencias de código
143) Para claves con **cero** referencias, solicitar confirmación y eliminarlas a través de Goman MCP
154) Producir una tabla Markdown: key | status(kept/deleted) | reason | notes
16
17Puertas de validación:
18- Nunca eliminar claves que todavía tengan referencias
19- Requerir confirmación explícita antes de la eliminación
20- Proporcionar una lista de reversión de claves eliminadas

3.8.6. Prompt — sincronización y verificación de traducciones faltantes (opcional)

/.github/prompts/i18n-sync.prompt.md

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Sincronizar claves i18n nuevas/modificadas y comprobar traducciones faltantes'
6---
7Objetivo: Comparar referencias de código con Goman y rellenar huecos.
8
9Pasos:
101) Escanear código en busca de claves `t('...')` bajo los namespaces proporcionados
112) Para claves faltantes en Goman, crearlas (los textos de marcador de posición están bien)
123) Para idiomas faltantes, crear marcadores de posición e informar la cobertura
134) Salir con una tabla de cobertura: key | en | be | de | missing

4) Cómo usarlo (IDE y CLI)

4.1. En VS Code / otro IDE

• Abra Copilot Chat — seleccione Agente/Editar/Preguntar en la lista desplegable.
• Para archivos de prompt, simplemente escriba /nombre-del-archivo sin extensión (por ejemplo, /security-review).
• Añada contexto a través de menciones @ de archivos y directorios.
• Cambie el modo de chat (Planificar/Frontend/DBA) al cambiar el tipo de tarea.

4.2. En Copilot CLI (terminal)

• Ejemplo de instalación: npm install -g @github/copilot → ejecutar copilot.
• Interactivo: «Ejecutar /implement-from-spec en @docs/feature.spec.md».
• Programático / en CI: copilot -p "Implementar función a partir de @docs/feature.spec.md" --deny-tool shell("rm*").
• Añada / limite herramientas a través de flags: --allow-all-tools, --allow-tool, --deny-tool (globalmente o por patrón, por ejemplo shell(npm run test:*)).

4.3. Recetas de comandos para CLI (modos de chat y prompts)

A continuación se presentan recetas listas para usar. Todos los comandos deben ejecutarse desde la raíz del repositorio y respetar sus listas de denegación/permiso.

A. Ejecutar un archivo de prompt en sesión interactiva

1copilot
2# dentro de la sesión (escriba la cadena tal cual)
3/security-review prNumber=123

B. Ejecutar un archivo de prompt en modo no interactivo (heredoc)

1copilot <<'EOF'
2/security-review prNumber=123
3EOF

C. Pasar parámetros a un archivo de prompt

1copilot <<'EOF'
2/implement-from-spec path=@docs/feature.spec.md target=apps/web
3EOF

Dentro del prompt, los valores se pueden leer como ${input:target} y ${input:path}.

D. Ejecutar un prompt con permisos de herramientas seguros

1copilot --allow-tool "shell(npm run test:*)" \
2        --deny-tool  "shell(rm*)" \
3        <<'EOF'
4/security-review prNumber=123
5EOF

E. Usar un modo de chat (modo especializado) en CLI

1copilot
2# dentro de la sesión — pida que cambie al modo deseado y ejecute el prompt
3Use el modo de chat i18n.
4/i18n-component-scaffold componentName=PrimaryButton namespace=ui.button path=apps/web/src/components

Si su cliente admite la selección de modo a través de un menú — seleccione i18n antes de ejecutar el prompt. Si no, especifique las restricciones en el frontmatter del prompt (tools y reglas en el cuerpo del prompt).

F. Pasar referencias a archivos/diff como contexto

1copilot <<'EOF'
2Por favor, revise estos cambios:
3@apps/web/src/components/PrimaryButton.tsx
4@docs/feature.spec.md
5/security-review prNumber=123
6EOF

G. Cambiar el modelo para una ejecución específica

Recomendamos especificar el modelo en el frontmatter del prompt. Si es compatible, también puede pasar el flag del modelo durante la ejecución:

1copilot --model GPT-4o <<'EOF'
2/implement-from-spec
3EOF

H. Ciclo i18n con Goman MCP (CHAT)

Ejecute secuencialmente en la misma rama de chat:

1/i18n-component-scaffold componentName=PrimaryButton namespace=ui.button path=apps/web/src/components
2/i18n-prune pathOrDiff=@last-diff
3/i18n-sync namespace=ui.button

Lo que obtiene:

• tablas/informes finales en el panel de chat;
• cambios de código en su árbol de trabajo (el IDE muestra diff);
• no necesita ejecutar comandos CLI para Goman MCP aquí.

5) Ingeniería de contexto: cómo no "saturar" con contexto excesivo

1. Divida las sesiones por fases: Planificar → Implementar → Revisar/Probar. Cada fase tiene su propio Modo de Chat.
2. Adjunte solo las instrucciones necesarias: utilice *.instructions.md específicas de ruta en lugar de cargar todo.
3. Memoria del proyecto: guarde ADR cortos en project.memory.md — esto reduce el "olvido" del agente entre tareas.
4. Ayudantes de contexto: guarde referencias frecuentes (API/seguridad/UI) en *.context.md y refiérase a ellas desde los archivos de prompt.
5. Enfoque en la tarea: en los archivos de prompt, especifique siempre el objetivo, los pasos y el formato de salida (tabla, diff, checklist).

6) Seguridad y gestión de herramientas

• Solicite confirmación explícita antes de ejecutar comandos/herramientas. En CI, utilice --deny-tool por defecto y añada listas de permiso locales.
• Patrones de permisos: permita solo lo necesario (shell(npm run test:*), playwright:*), deniegue patrones peligrosos (shell(rm*)).
• Secretos: no ponga claves en prompts e instrucciones; utilice Entornos de GitHub o gestores de secretos locales y .env con .gitignore.
• Cualquier MCP — solo de fuentes confiables; verifique el código/configuración antes de conectarse.
• Comprobaciones de parches: requiera unified-diff y explicaciones en los archivos de prompt — esto simplifica la revisión.

7) Receta CI/CD (ejemplo opcional)

Asegúrese de que "todo compila": ejecute Copilot CLI en modo seguro para generar un comentario de PR.

1# .github/workflows/ai-review.yml
2name: AI Review (Copilot CLI)
3on:
4  pull_request:
5    types: [opened, synchronize, reopened]
6
7jobs:
8  ai_review:
9    runs-on: ubuntu-latest
10    permissions:
11      contents: read
12      pull-requests: write
13    steps:
14      - uses: actions/checkout@v4
15      - uses: actions/setup-node@v4
16        with:
17          node-version: 22
18      - name: Instalar Copilot CLI
19        run: npm install -g @github/copilot
20      - name: Ejecutar prompt de revisión de seguridad (sin herramientas peligrosas)
21        env:
22          PR: ${{ github.event.pull_request.number }}
23        run: |
24          copilot -p "Ejecutar /security-review con prNumber=${PR}" \
25            --deny-tool shell("rm*") --deny-tool shell("curl*") \
26            --allow-tool shell("npm run test:*") \
27            --allow-tool "github:*" \
28            > ai-review.txt || true
29      - name: Comentar PR con resultados
30        if: always()
31        run: |
32          gh pr comment ${{ github.event.pull_request.number }} --body-file ai-review.txt

Consejo: mantenga listas de denegación/permiso estrictas; no dé al agente "libertad total" en CI.

8) Escenarios pequeños y consejos útiles

• De la idea al PR: /plan — discutir plan — /implement-from-spec → pruebas locales — PR — /security-review.
• Mantenimiento: /refactor-slice para mejoras locales sin cambiar el comportamiento.
• Pruebas: /test-gen para módulos nuevos + adiciones manuales para casos extremos.
• Introducción gradual: empiece con 1-2 archivos de prompt y un modo de chat; expanda más tarde.

9) Comprobaciones de calidad (puertas de validación)

En cada archivo de prompt, especifique "qué se considera listo":

• Formato de salida: tabla de riesgos, unified-diff, checklist.
• Comprobaciones automáticas: compilación, pruebas unitarias/integración, lint/verificación de tipos.
• Comprobación manual: "¿Se puede fusionar (OK to merge)?" con justificación y riesgos residuales.

10) Antipatrones y hacks

• Antipatrón: un único instructions.md enorme. Prefiera varios *.instructions.md con applyTo.
• Antipatrón: palabras generales en lugar de reglas. Prefiera comandos/pasos específicos.
• Antipatrón: ejecución de comandos shell peligrosos sin verificación. Utilice deny/allow y confirmación manual.
• Antipatrón: especificaciones/memoria olvidadas. Mantenga feature.spec.md y project.memory.md.
• Antipatrón: mezcla de tareas en una misma sesión. Cree Modos de Chat para cada fase.

11) Lista de verificación de implementación

1. Añada .github/copilot-instructions.md (como mínimo 5-8 puntos sobre compilación/pruebas/estilo).
2. Cree 1-2 *.instructions.md con applyTo (frontend/backend o workflows).
3. Añada plan.chatmode.md y un prompt (por ejemplo, implement-from-spec.prompt.md).
4. Cree docs/feature.spec.md y docs/project.memory.md.
5. Conecte MCP (como mínimo GitHub MCP) a través de .vscode/mcp.json.
6. Ejecute el flujo de trabajo en VS Code: /implement-from-spec — verifique — PR.
7. (Opcional) Añada una revisión de IA simple en CI a través de Copilot CLI con listas estrictas de denegación/permiso.

12) Preguntas y respuestas (FAQ)

P: ¿Cómo me aseguro de que Copilot "vea" mis instrucciones? R: Compruebe el resumen/Referencias en la respuesta; mantenga también las reglas cortas y concretas.

P: ¿Se pueden pasar parámetros dinámicamente a los archivos de prompt? R: Sí, generalmente a través de variables de reemplazo (como ${prNumber}) o simplemente a través de una solicitud de texto al ejecutar /prompt en el chat.

P: ¿Dónde almacenar secretos para MCP? R: En Entornos de GitHub o gestores de secretos locales; no en .prompt.md/.instructions.md.

P: ¿Qué elegir: Modo de Chat o Archivo de Prompt? R: El Modo de Chat define el "marco" (modelo/herramientas/rol). El Archivo de Prompt es el "guion" dentro de ese marco.

13) Próximos pasos

• Añada un segundo prompt para su proceso manual más frecuente.
• Haga que project.memory.md sea obligatorio después de todas las decisiones arquitectónicas.
• Mueva gradualmente el conocimiento colectivo a *.context.md y refiérase a él desde los archivos de prompt.

Apéndice A — Plantillas de inicio rápido

Todas las claves, rutas y flags corresponden a la documentación (28 de octubre de 2025).

/.github/copilot-instructions.md — reglas para todo el repositorio

1# Estándares de codificación del repositorio
2- Compilación: `npm ci && npm run build`
3- Pruebas: `npm run test` (cobertura ≥ 80%)
4- Lint/Verificación de tipos: `npm run lint && npm run typecheck`
5- Commits: Conventional Commits; mantenga los PR pequeños y enfocados
6- Documentación: actualice `CHANGELOG.md` en cada PR de lanzamiento

/.github/instructions/frontend.instructions.md — instrucciones para rutas específicas

1---
2applyTo: "apps/web/**/*.{ts,tsx},packages/ui/**/*.{ts,tsx}"
3---
4- React: componentes de función y hooks
5- Estado: Zustand; obtención de datos con TanStack Query
6- Estilo: Tailwind CSS; evite estilos en línea excepto en casos dinámicos
7- Pruebas: Vitest + Testing Library; evite snapshots inestables

/.github/instructions/backend.instructions.md — instrucciones para rutas específicas

1---
2applyTo: "services/api/**/*.{ts,js},packages/server/**/*.{ts,js}"
3---
4- HTTP: Fastify; versione APIs bajo `/v{N}`
5- Acceso a DB: Prisma; migraciones a través de `prisma migrate`
6- Seguridad: validación de esquema (Zod), límites de tasa, registros de auditoría
7- Pruebas: pruebas de integración a través de `vitest --config vitest.integration.ts`

/.github/instructions/actions.instructions.md — GitHub Actions

1---
2applyTo: ".github/workflows/**/*.yml"
3---
4- Mantenga los trabajos pequeños; reutilice a través de acciones compuestas
5- Caché: `actions/setup-node` + caché integrada para npm/pnpm
6- Secretos: solo a través de Entornos de GitHub; nunca codificados

/.github/chatmodes/plan.chatmode.md — modo de chat personalizado

1---
2description: "Planificar - analizar código/especificaciones y proponer un plan; herramientas de solo lectura"
3model: GPT-4o
4tools:
5  - "search/codebase"
6---
7En este modo:
8- Produzca un plan estructurado con riesgos e incógnitas
9- No edite archivos; genere una lista de tareas concisa en su lugar

/.github/prompts/security-review.prompt.md — archivo de prompt

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Realizar una revisión de seguridad de un pull request'
6---
7Objetivo: Revisar el PR ${input:prNumber} en busca de problemas de seguridad comunes.
8
9Lista de verificación:
10- Cobertura de autenticación/autorización
11- Validación de entrada y codificación de salida (XSS/SQLi)
12- Gestión y configuración de secretos
13- Versiones de dependencias y CVEs conocidos
14
15Salida:
16- Una tabla Markdown: issue | file | line | severity | fix
17- Si es trivial, incluya una sugerencia de diff unificada

/.github/prompts/implement-from-spec.prompt.md — archivo de prompt

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Implementar una función a partir de una especificación'
6---
7Su tarea es implementar la función descrita en @docs/feature.spec.md.
8
9Pasos:
101) Leer @docs/feature.spec.md y resumir el plan
112) Listar archivos a añadir o modificar
123) Proponer cambios de código; preguntar antes de instalar nuevas dependencias
134) Generar pruebas mínimas y ejecutarlas
14
15Puertas de validación:
16- La compilación, las pruebas, el lint/verificación de tipos deben pasar
17- Proporcionar una lista de TODO para cualquier cosa pospuesta

/.github/prompts/refactor-slice.prompt.md — archivo de prompt

1---
2mode: 'agent'
3model: GPT-4o
4description: 'Refactorizar una porción de código específica sin cambiar el comportamiento'
5---
6Objetivo: Mejorar la legibilidad y reducir los efectos secundarios en @src/feature/* manteniendo el comportamiento sin cambios. Criterios: menos efectos secundarios, estructura más clara, todas las pruebas pasan.

/.github/prompts/test-gen.prompt.md — archivo de prompt

1---
2mode: 'agent'
3model: GPT-4o-mini
4description: 'Generar pruebas para un archivo/módulo dado'
5---
6Pedir al usuario que mencione `@` el archivo objetivo; generar pruebas unitarias/de integración y casos extremos.

/docs/feature.spec.md — plantilla de especificación

1# Función: Exportar informe a CSV
2Objetivo: Los usuarios pueden exportar la tabla filtrada a CSV.
3Criterios de aceptación:
4- Botón "Exportar CSV" en /reports
5- El servidor genera el archivo ≤ 5s para 10k filas
6- El orden/encabezados de las columnas coinciden con la UI; valores independientes de la localización
7Casos extremos: valores vacíos, números grandes, caracteres especiales
8No objetivos: XLSX, filtros simultáneos de varias columnas

/.vscode/mcp.json — configuración mínima de MCP

1{
2  "servers": {
3    "github-mcp": {
4      "type": "http",
5      "url": "https://api.githubcopilot.com/mcp"
6    }
7  }
8}

Apéndice B — Complementos operativos (ejemplos CLI & CI)

Estos ejemplos complementan el Apéndice A; describen el uso dentro de la ejecución / automatización y no duplican las plantillas anteriores.

Copilot CLI — permisos de herramientas seguros (interactivo / CI)

1# Ejecutar una sesión interactiva en su repositorio
2copilot
3
4# Permitir/denegar herramientas específicas (flags exactos según documentación de GitHub)
5copilot --allow-tool "shell(npm run test:*)" --deny-tool "shell(rm*)"
6
7# Ejecutar un archivo de prompt en modo no interactivo (ejemplo)
8copilot <<'EOF'
9/security-review prNumber=123
10EOF

GitHub Actions — comentar resultados de revisión en PR

1name: AI Security Review (Copilot CLI)
2on:
3  pull_request:
4    types: [opened, synchronize, reopened]
5
6jobs:
7  review:
8    runs-on: ubuntu-latest
9    permissions:
10      contents: read
11      pull-requests: write
12    steps:
13      - uses: actions/checkout@v4
14      - uses: actions/setup-node@v4
15        with:
16          node-version: 22
17      - name: Instalar Copilot CLI
18        run: npm install -g @github/copilot
19      - name: Ejecutar prompt de revisión de seguridad
20        env:
21          PR: ${{ github.event.pull_request.number }}
22        run: |
23          copilot --allow-tool "shell(npm run test:*)" --deny-tool "shell(rm*)" <<'EOF'
24          /security-review prNumber=${PR}
25          EOF
26      - name: Publicar resultados
27        run: |
28          gh pr comment ${{ github.event.pull_request.number }} --body "Revisión de Copilot completada. Consulte artefactos/logs para más detalles."

14) Configuración de contexto en un proyecto existente

Esta sección resuelve una tarea específica: toma un proyecto ya en funcionamiento y crea un contexto e instrucciones completos para GitHub Copilot en una sola pasada. No inventamos nada, todo se toma de lo que ya está en el código.

Cada paso es un prompt que se ejecuta en VS Code en modo Agente. Cada paso siguiente depende del resultado del anterior, por lo que el orden es importante.

14.1. Paso 1 — Auditoría del proyecto

Objetivo: obtener un mapa objetivo del proyecto. Sin él, todo lo demás es una conjetura.

Qué hacemos: abrimos Copilot Chat, seleccionamos el modo Agente, adjuntamos la carpeta raíz a través de @, y ejecutamos:

1@/
2
3Analiza la estructura de este proyecto. Determina:
4
5- stack: lenguaje, frameworks, gestor de paquetes
6- comandos de compilación, prueba, lint (exactos, de package.json / pom.xml / Makefile, etc.)
7- flujos de trabajo de CI existentes (.github/workflows) — qué se ejecuta allí
8- carpetas principales y su propósito
9- configuraciones existentes: lint, prettier, typescript, y similares
10
11Devuelve el resultado como una lista estructurada.
12No adivines, solo lo que sea realmente visible en los archivos.

Resultado: guardamos la respuesta; será necesaria en el paso 2. Este es el "mapa inicial", la calidad de todo lo que sigue depende de él.

14.2. Paso 2 — Generación de instrucciones globales

Objetivo: crear .github/copilot-instructions.md — una fuente unificada de reglas para todo el repositorio.

Qué hacemos: tomamos el resultado del paso 1 y ejecutamos:

1Basado en esta auditoría del proyecto:
2
3[insertamos el resultado del paso 1]
4
5Crea el archivo .github/copilot-instructions.md
6
7Requisitos:
8- solo hechos de la auditoría, nada inventado
9- comandos de compilación, prueba, lint — exactos, copiados de los archivos de configuración
10- estilo de código — solo si existe un archivo de configuración prettier/eslint, y solo lo que está fijado allí
11- política de commit — solo si existe commitlint o un análogo
12- 8–12 puntos máximo
13- cada punto — una sola línea concreta

Resultado: se crea y se fija en el árbol de trabajo el archivo .github/copilot-instructions.md.

14.3. Paso 3 — Generación de instrucciones específicas de ruta

Objetivo: crear reglas separadas para diferentes áreas del código que se adjuntan automáticamente por patrón de ruta.

Cuándo es necesario: si el proyecto tiene al menos dos áreas lógicamente separadas — frontend y backend, apps y packages, varios servicios. Si el proyecto es homogéneo — saltamos este paso.

Qué hacemos: para cada área, adjuntamos la carpeta correspondiente y ejecutamos un prompt separado. Ejemplo para frontend:

1@src/components/
2@src/pages/
3
4Analiza esta parte del proyecto y determina:
5
6- qué framework y cómo se escriben los componentes
7- patrones de gestión de estado (si son visibles)
8- cómo están organizadas las pruebas (si existen)
9- estilo de importaciones y nombres de archivos
10
11Crea el archivo .github/instructions/frontend.instructions.md
12
13Requisitos:
14- applyTo — un glob exacto que cubra solo estas carpetas
15- reglas — solo de lo que ves en el código
16- no duplica lo que ya está en copilot-instructions.md
17- no más de 6–8 puntos

Un prompt similar para backend, si existe, con las carpetas correspondientes en @.

Resultado: archivos en .github/instructions/ para cada área.

14.4. Paso 4 — Generación de una referencia del proyecto

Objetivo: crear docs/project.context.md — una referencia estable que reduce el "ruido" en los chats y no requiere actualización con cada cambio.

Qué hacemos:

1@/
2@README.md
3@package.json
4
5Crea el archivo docs/project.context.md —
6esta es una referencia del proyecto para el asistente de IA.
7
8Incluye:
9- descripción corta: qué hace el proyecto, para quién
10- patrones de arquitectura clave, si son visibles en la estructura de carpetas y las importaciones
11- dependencias externas y sus roles (por qué estas, si es comprensible desde el contexto)
12- lo que NO se debe hacer: carpetas obsoletas, patrones saturados, restricciones conocidas
13
14Restricciones:
15- máximo 30–40 líneas
16- solo lo que es objetivamente visible en el proyecto
17- sin suposiciones ni recomendaciones

Resultado: el archivo docs/project.context.md.

14.5. Paso 5 — Generación de memoria del proyecto

Objetivo: registrar las decisiones que ya se han tomado para que el agente no vuelva a ellas.

Qué hacemos:

1@/
2
3Mira el proyecto y encuentra decisiones que ya estén registradas en el código:
4
5- selección de bibliotecas — si hay alternativas obvias visibles en los archivos de bloqueo o comentarios
6- estructura de carpetas — si es no estándar para este stack
7- cualquier TODO o FIXME que tenga contexto del porqué
8- configuraciones que tengan comentarios con justificación
9
10Crea el archivo docs/project.memory.md en formato:
11
12## [fecha o "desconocido"] | Decisión | Por qué
13
14Cada entrada — máximo 2 líneas.
15No más de 10–12 entradas.
16Solo lo que es realmente visible.

Resultado: el archivo docs/project.memory.md.

14.6. Paso 6 — Primer archivo de prompt

Objetivo: crear un prompt de trabajo para la tarea más frecuente. No es necesario tener los cinco de las plantillas de inmediato — empezamos con uno y añadimos según sea necesario.

Cuándo usar qué prompt: si el equipo implementa nuevas funciones con más frecuencia — usamos implement-from-spec. Si revisan PR con más frecuencia — usamos security-review. Elegimos lo que se usa a diario.

Qué hacemos (ejemplo para implement-from-spec):

1@.github/copilot-instructions.md
2
3Crea el archivo .github/prompts/implement-from-spec.prompt.md
4para este proyecto.
5
6Requisitos:
7- mode: agent
8- tools: solo search/codebase
9- los pasos deben usar los comandos de compilación y prueba
10  de copilot-instructions.md
11- validation gates: compilación, pruebas, lint deben pasar
12- description — una línea

Resultado: el archivo .github/prompts/implement-from-spec.prompt.md, adaptado al stack específico del proyecto.

14.7. Conclusión y próximos pasos

Después de estos seis pasos, el repositorio tendrá:

1.github/
2  copilot-instructions.md          ← reglas globales (paso 2)
3  instructions/
4    frontend.instructions.md       ← reglas para frontend (paso 3)
5    backend.instructions.md        ← reglas para backend (paso 3)
6  prompts/
7    implement-from-spec.prompt.md  ← primer prompt (paso 6)
8docs/
9  project.context.md               ← referencia del proyecto (paso 4)
10  project.memory.md                ← memoria de decisiones (paso 5)

Este es un conjunto mínimo y funcional. Luego, de forma iterativa:

• añada archivos de prompt a medida que surjan nuevas tareas típicas
• actualice project.memory.md después de cada decisión arquitectónica
• añada modos de chat cuando empiece a notar que diferentes fases de trabajo se interfieren entre sí
• conecte MCP solo después de que el contexto base funcione

Todo lo descrito anteriormente se puede realizar en una sola sesión de trabajo. Cada prompt se puede ejecutar en secuencia, sin cambiar manualmente entre archivos — el agente creará los archivos en el árbol de trabajo por sí mismo.

Fuentes

Modos de chat personalizados en VS Code

Uso de servidores MCP en VS Code

Adición de instrucciones de repositorio personalizadas para GitHub Copilot

Cómo crear flujos de trabajo de IA confiables con primitivas de agente e ingeniería de contexto

🙌 PS:

¡Gracias por leer hasta el final! Si el material le pareció útil, le agradeceríamos si usted:

Las tecnologías se vuelven más accesibles cuando se entienden. Y usted ha dado el primer paso importante 💪