Los agentes de Stellaris

[!TIP] Descarga este kit de aprendizaje y usa la guía de extracción y preparación. Mantén intacto el starter original.

---
config:
  theme: base
  look: classic
  themeVariables:
    darkMode: false
    background: "#ffffff"
    primaryColor: "#f5f5f5"
    primaryTextColor: "#111111"
    primaryBorderColor: "#555555"
    secondaryColor: "#e0e0e0"
    secondaryTextColor: "#111111"
    secondaryBorderColor: "#666666"
    tertiaryColor: "#bdbdbd"
    tertiaryTextColor: "#111111"
    tertiaryBorderColor: "#444444"
    lineColor: "#444444"
    textColor: "#111111"
    mainBkg: "#f5f5f5"
    nodeBorder: "#555555"
    clusterBkg: "#ffffff"
    clusterBorder: "#999999"
    edgeLabelBackground: "#ffffff"
    actorBkg: "#e0e0e0"
    actorBorder: "#555555"
    actorTextColor: "#111111"
    actorLineColor: "#777777"
    signalColor: "#333333"
    signalTextColor: "#111111"
    labelBoxBkgColor: "#f5f5f5"
    labelBoxBorderColor: "#777777"
    labelTextColor: "#111111"
    loopTextColor: "#111111"
    activationBkgColor: "#bdbdbd"
    activationBorderColor: "#555555"
    noteBkgColor: "#f5f5f5"
    noteTextColor: "#111111"
    noteBorderColor: "#777777"
    attributeBackgroundColorOdd: "#f5f5f5"
    attributeBackgroundColorEven: "#e0e0e0"
---
flowchart LR
    accTitle: Mapa de capacidades de The Agents of Stellaris
    accDescr: Los roles deben tener responsabilidades y salidas distintas. La detección de herramientas y la disponibilidad de transferencias requieren evidencia en el host elegido.
    S["Explorador de pruebas: inspeccionar y probar"] --> F["Hallazgos y casos propuestos"]
    F --> H{"¿El humano acepta el alcance?"}
    H -->|No| S
    H -->|Sí| A["Agent: implementar el fragmento revisado"]
    A --> R["Revisión limpia y evidencia de pruebas"]

Leyenda. El rombo es una compuerta de alcance humano, no una concesión automática de autoridad de implementación.

Explicación. Los roles deben tener responsabilidades y salidas distintas. La detección de herramientas y la disponibilidad de transferencias requieren evidencia en el host elegido.

Referencias oficiales

Estas fuentes oficiales son la autoridad sobre el comportamiento y la disponibilidad del producto. Vuelve a consultarlas cuando uses otra superficie o después de una actualización del producto.

• Agentes personalizados de VS Code
• Configuración de agentes personalizados
• Agentes personalizados para Copilot cloud agent

Historia

En Stellaris, la navegación está a cargo de especialistas: uno cartografía los peligros, otro repara los motores y otro verifica la ruta. Ninguno recibe todos los instrumentos.

La fantasía es una ayuda para la memoria; la lección de ingeniería exige evidencia observable y reproducible.

Objetivos de aprendizaje

• Define un agente enfocado en pruebas, sin herramienta de edición de origen y con capacidad de comando de prueba acotada.
• Separa las instrucciones del rol, las herramientas disponibles y una transferencia revisada por humanos.
• Verifica la detección del perfil e informa los fallos restantes en lugar de autoaprobar una implementación.

Requisitos previos

Para preparar las herramientas y las cuentas personales, completa la guía de requisitos previos. Para estudiar solo desde el terminal, sigue la ruta de la CLI desde el kit extraído; la evidencia específica de VS Code sigue siendo independiente.

Límite de evidencia: Una herramienta de comandos puede seguir teniendo efectos secundarios. La intención de solo lectura no es un sandbox; revisa los comandos de prueba y los permisos exactos.

Tiempo estimado de la sesión: 45–75 minutos después de los prerrequisitos; la duración real varía. Nunca uses secretos de producción ni datos de clientes.

Explicación de conceptos

Un agente personalizado es un rol reutilizable con instrucciones específicas, herramientas seleccionadas y transferencias opcionales. Usa el formato .agent.md; no se enseñan los modos de chat personalizados obsoletos. Aplica la autoridad mínima: un revisor puede necesitar herramientas de lectura y pruebas, pero no de edición. Las transferencias deben transmitir un artefacto o una decisión concretos. Los nombres y la disponibilidad de las herramientas varían según el host.

Caso de uso concreto

Un explorador de pruebas puede inspeccionar y ejecutar una prueba acotada y luego recomendar un caso que falta. Un implementador separado es el dueño de las ediciones de origen; la transferencia transmite un plan revisado, no autoridad ilimitada.

Comprobación de vocabulario

• Rol: Ask, Plan, Agent o un agente personalizado.
• Harness/superficie: el entorno de ejecución o la superficie del producto en que opera un rol.
• Destino: el destino de sesión seleccionado, como Local, Copilot o Cloud cuando se ofrecen.
• Entorno: la carpeta, el worktree, la máquina local, el Codespace o el entorno remoto.
• Instrucciones: contexto duradero que se aplica automáticamente.
• Prompt: una plantilla de tarea invocada manualmente.
• Skill: conocimientos reutilizables que se cargan cuando son pertinentes.
• Agente personalizado: un rol con instrucciones, herramientas y transferencias opcionales.
• MCP: Model Context Protocol.
• Evidencia: una ruta, un diff, el resultado de un comando, una traza o una decisión de revisión.

Flujo de trabajo Ask → Plan → Agent

Ask — investigar

1. Identifica el resultado real que busca el usuario y la fuente de verdad actual.
2. Inspecciona los archivos, las instrucciones, las herramientas, los permisos y las comprobaciones existentes que sean relevantes.
3. Cita rutas concretas o evidencia de la plataforma para cada hallazgo importante.
4. Registra la incertidumbre y no deduzcas capacidades que no estén disponibles.

Punto de control: No implementes nada hasta comprender el estado actual y la evidencia.

Plan — diseñar

1. Establece el alcance, los objetivos excluidos, las suposiciones, los riesgos y los límites de confianza.
2. Selecciona el mínimo rol, herramientas, autoridad y entorno necesarios.
3. Define los criterios de aceptación, los comandos de verificación, la revisión y el restablecimiento.
4. Señala cualquier dependencia en versión preliminar o experimental y proporciona una alternativa.

Punto de control: Otra persona que esté aprendiendo debería poder anticipar qué significa completar el trabajo a partir del plan.

Agent — ejecutar

1. Realiza el cambio reversible más pequeño o produce el artefacto planificado.
2. Usa ciclos cortos de inspeccionar → cambiar → verificar.
3. Conserva la salida de los comandos, el estado de salida, los diffs, las trazas o los registros de la plataforma.
4. Detente cuando se cumplan los criterios de aceptación; no realices tareas de limpieza ajenas al alcance.

Revisión — cuestionar

1. Inspecciona el diff o el artefacto completo.
2. Compara cada resultado con el plan y los criterios de aceptación.
3. Ejecuta la comprobación existente más específica que sea pertinente y amplía su alcance solo cuando esté justificado.
4. Registra las limitaciones y los riesgos sin resolver.
5. Puntúa el trabajo con rubric.md.

Misión guiada

1. Prepara una copia aislada

1. Descarga y extrae el kit stellaris-agents en un nuevo directorio de trabajo.
2. Lee KIT-START.md en su raíz. Abre starter/ como el espacio de trabajo de VS Code cuando pruebes la detección, pero ejecuta el verificador desde la raíz del kit.
3. Inspecciona starter/.github/agents/test-scout.agent.md, verify.js antes de editar.
4. Desde la raíz del kit extraído, ejecuta node verify.js.
5. Registra el rechazo documentado del starter. Un runtime faltante o un fallo no relacionado no es el resultado esperado del ejercicio.

2. Investiga y planifica

Comando de comprobación inicial listo para copiar, desde la raíz del kit extraído:

node verify.js

En Ask, solicita un rastreo de los archivos inspeccionados y de lo que el verificador observa realmente. Cuestiona cualquier afirmación sobre ejecución en vivo que no esté respaldada por la salida.

Usa este prompt de planificación:

Define test-scout metadata and a minimal tool list consistent with the verifier. Keep recommendations test-focused, preserve source-read-only intent and require a reviewed handoff to Agent.
Do not implement yet. Identify affected files, the negative case and a safe reset.

3. Implementa el fragmento revisado

1. Aprueba solo el artefacto starter nombrado y las pruebas enfocadas necesarias.
2. Pide a Agent que implemente un solo fragmento; inspecciona los comandos propuestos antes de ejecutarlos.
3. Ejecuta node verify.js otra vez desde la raíz del kit, o node ../verify.js desde starter/.
4. Compara el resultado exacto con el punto de control de abajo y revisa el diff completo.
5. Registra por separado el descubrimiento del host o la actividad en vivo cuando esté disponible. No habilites servicios extra para fabricar un resultado aprobado.

[!IMPORTANT] Punto de control: El perfil tiene búsqueda y una herramienta de comandos enfocada, no una herramienta de edición, y un prompt de transferencia concreto. Una herramienta de comandos puede seguir teniendo efectos secundarios. La intención de solo lectura no es un sandbox; revisa los comandos de prueba y los permisos exactos.

4. Demuestra que una comprobación puede rechazar un error

Añade temporalmente una herramienta de edición al perfil copiado. Verifica el rechazo y luego restaura la lista restringida de herramientas.

Termina con la evidencia de capacidad específica de la aventura en la rúbrica, no solo con la presencia de un archivo.

Fallo intencional: El mago estelar omnipotente

Haz esto únicamente en un entorno desechable:

Dale al agente todas las herramientas y la misión «ayuda con el proyecto». Puede editar mientras revisa o ampliar el alcance porque la responsabilidad y la autoridad no tienen límites.

Recuperación

Vuelve a Ask, identifica el límite vulnerado, acota el plan, elimina la autoridad o el contexto innecesarios y repite la verificación pertinente más pequeña. Documenta la lección sobre las causas en lugar de limitarte a afirmar que el intento falló.

Desafío independiente

Construye una cadena de investigador, implementador y revisor con artefactos explícitos y sin responsabilidades duplicadas.

Restricciones:

• No copies literalmente la misión guiada.
• No añadas herramientas, permisos ni recursos en la nube sin una necesidad declarada.
• No afirmes calidad, rendimiento, compatibilidad ni disponibilidad sin evidencia obtenida mediante ejecución.
• Mantén el lenguaje fantástico subordinado a la claridad técnica.

Lista de comprobación de evidencia

• Hallazgos de Ask fundamentados en las fuentes.
• Plan aprobado con alcance, objetivos excluidos, riesgos, comprobaciones y restablecimiento.
• Diff o artefacto de Agent limitado al alcance declarado.
• Salida de verificación con comando, estado o registro de la plataforma.
• Causa raíz del fallo intencional y recuperación.
• Resultado del desafío independiente.
• Limitaciones explícitas y notas sobre el estado de las funciones.
• rubric.md completada.

Instrucciones de restablecimiento

1. Guarda tu diff, la salida del comando y las limitaciones del kit desechable.
2. Detén solo el proceso o la sesión de aprendizaje que iniciaste. No detengas otros proyectos.
3. Si inicializaste Git en el kit, inspecciona git status --short allí y restaura solo tus archivos de ejercicio nombrados desde su línea base local.
4. De lo contrario, extrae el ZIP original en un nuevo directorio sin usar para otro intento; no sobrescribas tu trabajo actual.
5. Elimina solo configuraciones, worktrees o recursos remotos propiedad del ejercicio después de revisar lo que valga la pena conservar.

La fuente del currículo y los demás proyectos deben permanecer sin cambios. Un restablecimiento de la copia del kit no es un reinicio completo del repositorio.

Siguiente aventura

Siguiente en la rutaLas protecciones de StonevaleIntermedio