UiPath/init

Configurar coder-eval en este repositorio

Objetivo: dejar al usuario con un directorio de tareas que contenga una tarea real que pueda ejecutar de inmediato, no un esqueleto vacío. La tarea debe ejercitar algo que este repositorio realmente distribuya.

La solicitud del usuario es: $ARGUMENTS

Paso 1 — Verificar requisitos previos

Ejecuta coder-eval --version. La instalación de este plugin no instaló el CLI, y todos los pasos posteriores lo necesitan.

Si falta, sigue ${CLAUDE_PLUGIN_ROOT}/reference/cli-setup.md: ofrece la instalación, pregunta antes de ejecutarla y confirma con coder-eval --version después. Nunca instales sin preguntar y no continúes si el usuario lo rechaza.

Esa referencia también cubre la otra mitad de la verificación de versión: si este proyecto fija una versión de coder-eval y qué hacer cuando la instalada no coincide.

Paso 2 — Verificar si este repositorio ya está configurado

Esta habilidad crea un primer conjunto de pruebas. Si se ejecuta contra un repositorio que ya tiene uno, escribiría una "primera tarea" junto a un árbol existente y reportaría éxito. Por lo tanto, averigua antes de escribir nada.

Localiza el árbol de evaluación según ${CLAUDE_PLUGIN_ROOT}/reference/repo-layout.md. Si el repositorio ya tiene tareas, reporta el inventario y detente: cuántos archivos de tarea y dónde, cuántos directorios de ejecución y si hay experimentos. Luego señala al usuario las habilidades que actúan sobre lo que existe:

• /coder-eval:lint-tasks para revisar las tareas ya existentes;
• /coder-eval:analyze para leer una ejecución finalizada.

Solo crea la estructura si el repositorio no tiene ninguna, o si el usuario pide explícitamente más después de ver el inventario. Nunca sobrescribas un archivo de tarea existente, sea lo que sea que pidan; añade junto a él.

Un repositorio con tareas pero sin experimentos está parcialmente configurado, no vacío. Repórtalo tal cual y ofrece la pieza faltante; no crees una primera tarea como si no hubiera nada.

Paso 3 — Escanear qué es evaluable

Busca lo siguiente, en orden de prioridad, y reporta lo que encontraste antes de escribir nada:

1. Habilidades de Claude Code — busca con glob .claude/skills/*/SKILL.md y **/skills/*/SKILL.md. Las habilidades son lo más valioso de evaluar porque si se activan o no es invisible hasta que falla. Si encuentras alguna, recomienda /coder-eval:check-skill para cada una; es un conjunto de activación diseñado específicamente, no algo para improvisar aquí.
2. Un servidor MCP — un .mcp.json, una clave mcpServers en package.json o pyproject.toml, o un punto de entrada de servidor (un server.py / index.ts que registre herramientas). Anota qué herramientas expone.
3. Un punto de entrada CLI — [project.scripts] en pyproject.toml, bin o scripts en package.json, o un Makefile con objetivos utilizables.

Si el repositorio es un monorepositorio con muchos directorios de habilidades o paquetes, limita el escaneo y pregunta en qué subárbol enfocarse en lugar de reportar cincuenta candidatos.

Si no encuentras nada en estas tres categorías, dilo claramente. Luego ofrece la cosa útil más pequeña en su lugar: una tarea que ejecute un script o comando de prueba que el repositorio ya tenga y verifique su salida, en lugar de crear un conjunto vacío que no demuestre nada.

Paso 4 — Crear una tarea real

Escribe dentro del árbol que resolvió el paso 2. Si el repositorio no tiene ninguno, propón una ubicación y pregunta. La regla de nunca sobrescribir del paso 2 sigue aplicando aquí — es el único lugar donde vive esa regla.

Escribe una tarea derivada de lo que encontró el paso 3:

• Un CLI — una tarea cuyo prompt pida algo que el CLI haga, con criterios que verifiquen el contenido del archivo resultante, no solo que apareció un archivo.
• Un servidor MCP — una tarea que ejercite una herramienta específica y verifique su efecto.
• Habilidades — apunta a /coder-eval:check-skill en su lugar; un conjunto de activación tiene una forma diferente a una tarea de capacidad y esa habilidad lo construye correctamente.

Los prompts instruyen, los criterios validan. No repitas en el prompt lo que los criterios verifican: un prompt que dice "asegúrate de que el archivo contenga X" evalúa comprensión lectora, no capacidad.

Antes de escribir los criterios, lee ${CLAUDE_PLUGIN_ROOT}/reference/task-rubric.md. Es la lista de verificación compartida para saber si una tarea puede aprobarse por la razón equivocada, y la única tarea que creas aquí es el ejemplo sobre el que se modelará cada tarea futura en este repositorio, por lo que vale la pena hacerlo bien desde el principio en lugar de arreglarlo después. Para los tipos de criterio y sus campos, lee ${CLAUDE_PLUGIN_ROOT}/reference/criteria.md.

Usa /coder-eval:task si el usuario quiere más tareas después de esta; es el mismo bucle de creación con un resumen en lenguaje natural.

Paso 5 — Variables de entorno

Escribe las variables que necesita el agente elegido (por ejemplo, ANTHROPIC_API_KEY para el agente claude-code predeterminado) en .env.example — créalo o agrégalo al final.

Nunca escribas .env: puede que ya contenga secretos reales. Si .env no existe, verifica si está en gitignore antes de sugerir al usuario que lo cree, y dilo si no lo está.

Paso 6 — Validar

Ejecuta coder-eval plan <directorio-de-tarea>/*.yaml e itera hasta que termine con código 0. Esto valida el esquema de la tarea a través de los modelos reales, por lo que un nombre de campo que hayas adivinado mal se detecta aquí. plan toma archivos de tarea: un argumento de directorio desnudo es rechazado directamente (Expected a YAML task file but got a directory), así que siempre pasa rutas explícitas o un glob. No sugieras coder-eval plan sin argumento: la detección sin argumentos solo funciona desde un checkout fuente de coder-eval y termina con código 1 en cualquier otro lugar.

Un directorio vacío o sin tareas no produce un éxito significativo — si plan reporta cero tareas, trátalo como un fallo al crear la estructura, no como un éxito. Ten en cuenta que el error de directorio desnudo es un resultado diferente: ese significa que pasaste la forma de argumento incorrecta, no que la estructura esté vacía.

Paso 7 — Reportar

Informa al usuario:

• qué encontraste en el escaneo y qué elegiste evaluar primero;
• el comando exacto para ejecutarlo: coder-eval run <ruta>, más una nota de que cuesta tokens reales y necesita las credenciales del paso 5;
• que /coder-eval:check-skill es el siguiente paso si el repositorio incluye habilidades;
• que /coder-eval:analyze lee el directorio de ejecución después, y /coder-eval:ci convierte el conjunto en una puerta de GitHub Actions.