UiPath/init

Configurer coder-eval dans ce dépôt

Objectif : laisser l'utilisateur avec un dossier de tâche contenant une vraie tâche qu'il peut exécuter immédiatement, et non un squelette vide. La tâche doit exercer quelque chose que ce dépôt fournit réellement.

La requête de l'utilisateur est : $ARGUMENTS

Étape 1 — Vérifier les prérequis

Exécutez coder-eval --version. L'installation de ce plugin n'a pas installé la CLI, et chaque étape suivante en a besoin.

Si elle est absente, suivez ${CLAUDE_PLUGIN_ROOT}/reference/cli-setup.md : proposez l'installation, demandez avant de l'exécuter, et confirmez avec coder-eval --version après. N'installez jamais sans sollicitation, et ne continuez pas si l'utilisateur refuse.

Cette référence couvre également l'autre moitié de la vérification de version — si ce projet impose une version de coder-eval, et que faire quand la version installée ne correspond pas.

Étape 2 — Vérifier si ce dépôt est déjà configuré

Cette compétence crée une première suite. Exécutée sur un dépôt qui en possède déjà une, elle écrirait une "première tâche" à côté d'une arborescence existante et signalerait un succès — donc renseignez-vous avant d'écrire quoi que ce soit.

Localisez l'arborescence d'évaluation selon ${CLAUDE_PLUGIN_ROOT}/reference/repo-layout.md. Si le dépôt a déjà des tâches, faites l'inventaire et arrêtez-vous : combien de fichiers de tâches et où, combien de répertoires d'exécution, et s'il y a des expériences. Puis orientez l'utilisateur vers les compétences qui agissent sur l'existant —

• /coder-eval:lint-tasks pour examiner les tâches déjà présentes ;
• /coder-eval:analyze pour lire une exécution terminée.

Ne créez une structure que si le dépôt n'en a aucune, ou si l'utilisateur demande explicitement plus après avoir vu l'inventaire. Ne remplacez jamais un fichier de tâche existant, quoi qu'il demande ; ajoutez à côté.

Un dépôt avec des tâches mais sans expériences est configuré partiellement, pas vide. Signalez-le tel quel et proposez la pièce manquante — ne créez pas une première tâche comme s'il n'y avait rien.

Étape 3 — Scanner ce qui est testable

Cherchez les éléments suivants, par ordre de priorité, et rapportez ce que vous avez trouvé avant d'écrire quoi que ce soit :

1. Compétences Claude Code — globez .claude/skills/*/SKILL.md et **/skills/*/SKILL.md. Les compétences sont ce qu'il y a de plus précieux à évaluer, car leur déclenchement est invisible jusqu'à l'échec. Si vous en trouvez, recommandez /coder-eval:check-skill pour chacune d'elles — c'est une suite d'activation conçue pour cela, pas quelque chose à bricoler ici.
2. Un serveur MCP — un .mcp.json, une clé mcpServers dans package.json ou pyproject.toml, ou un point d'entrée de serveur (un server.py / index.ts qui enregistre des outils). Notez quels outils il expose.
3. Un point d'entrée CLI — [project.scripts] dans pyproject.toml, bin ou scripts dans package.json, ou un Makefile avec des cibles utilisables.

Si le dépôt est un monorepo avec de nombreux répertoires de compétences ou de paquets, limitez le scan et demandez sur quelle sous-arborescence se concentrer plutôt que de signaler cinquante candidats.

Si vous ne trouvez rien dans ces trois catégories, dites-le clairement. Proposez alors la plus petite chose utile à la place — une tâche qui exécute un script ou une commande de test que le dépôt possède déjà et vérifie sa sortie — plutôt que de créer une suite vide qui ne prouve rien.

Étape 4 — Créer une vraie tâche

Écrivez dans l'arborescence résolue à l'étape 2. Si le dépôt n'en a pas, proposez un emplacement et demandez. La règle de non-écrasement de l'étape 2 s'applique toujours ici — c'est le seul endroit où cette règle vit.

Écrivez une tâche dérivée de ce que l'étape 3 a trouvé :

• Une CLI — une tâche dont le prompt demande quelque chose que la CLI fait, avec des critères qui vérifient le contenu du fichier résultant, pas seulement qu'un fichier est apparu.
• Un serveur MCP — une tâche qui exerce un outil spécifique et vérifie son effet.
• Compétences — orientez vers /coder-eval:check-skill à la place ; une suite d'activation a une forme différente d'une tâche de capacité et cette compétence la construit correctement.

Les prompts instruisent, les critères valident. Ne répétez pas dans le prompt ce que les critères vérifient — un prompt qui dit "assurez-vous que le fichier contient X" teste la compréhension de lecture, pas la capacité.

Avant d'écrire les critères, lisez ${CLAUDE_PLUGIN_ROOT}/reference/task-rubric.md. C'est la liste de contrôle partagée pour savoir si une tâche peut réussir pour la mauvaise raison, et la tâche unique que vous créez ici est l'exemple sur lequel chaque tâche ultérieure de ce dépôt sera modelée — donc cela vaut la peine de bien faire plutôt que de corriger plus tard. Pour les types de critères et leurs champs, lisez ${CLAUDE_PLUGIN_ROOT}/reference/criteria.md.

Utilisez /coder-eval:task si l'utilisateur veut plus de tâches après celle-ci ; c'est la même boucle de création avec un brief en langage naturel.

Étape 5 — Variables d'environnement

Écrivez les variables dont l'agent choisi a besoin (par exemple ANTHROPIC_API_KEY pour l'agent claude-code par défaut) dans .env.example — créez-le ou ajoutez-y.

N'écrivez jamais .env : il peut déjà contenir de vrais secrets. Si .env n'existe pas, vérifiez s'il est dans le gitignore avant de suggérer à l'utilisateur d'en créer un, et dites-le si ce n'est pas le cas.

Étape 6 — Valider

Exécutez coder-eval plan <dossier-de-tâche>/*.yaml et itérez jusqu'à ce qu'il se termine avec le code 0. Cela valide le schéma de la tâche via les vrais modèles, donc un nom de champ mal deviné apparaît ici. plan prend des fichiers de tâche : un argument de répertoire nu est rejeté catégoriquement (Expected a YAML task file but got a directory), donc passez toujours des chemins explicites ou un glob. Ne suggérez pas coder-eval plan sans argument — la découverte sans argument ne fonctionne qu'à partir d'une copie source de coder-eval et se termine par 1 partout ailleurs.

Un répertoire vide ou sans tâche ne produit pas un succès significatif — si plan ne signale aucune tâche, traitez cela comme un échec de création, pas une réussite. Notez que l'erreur de répertoire nu est un résultat différent : cela signifie que vous avez passé la mauvaise forme d'argument, pas que la structure est vide.

Étape 7 — Rapporter

Dites à l'utilisateur :

• ce que vous avez trouvé dans le scan, et ce que vous avez choisi d'évaluer en premier ;
• la commande exacte pour l'exécuter : coder-eval run <chemin>, avec une note indiquant que cela coûte de vrais tokens et nécessite les identifiants de l'étape 5 ;
• que /coder-eval:check-skill est l'étape suivante si le dépôt fournit des compétences ;
• que /coder-eval:analyze lit le répertoire d'exécution ensuite, et /coder-eval:ci transforme la suite en barrière GitHub Actions.