UiPath/init

Configurar o coder-eval neste repositório

Objetivo: deixar o usuário com um diretório de tarefas contendo uma tarefa real que possa executar imediatamente, não um esqueleto vazio. A tarefa deve exercitar algo que este repositório realmente disponibiliza.

A solicitação do usuário é: $ARGUMENTS

Etapa 1 — Verificar pré-requisitos

Execute coder-eval --version. A instalação deste plugin não instalou a CLI, e cada etapa seguinte precisa dela.

Se estiver faltando, siga ${CLAUDE_PLUGIN_ROOT}/reference/cli-setup.md: ofereça a instalação, pergunte antes de executá-la e confirme com coder-eval --version depois. Nunca instale sem ser solicitado e não continue se o usuário recusar.

Essa referência também cobre a outra metade da verificação de versão — se este projeto define uma versão do coder-eval e o que fazer quando a versão instalada não corresponde a ela.

Etapa 2 — Verificar se este repositório já está configurado

Este skill cria uma primeira suíte. Se executado em um repositório que já possui uma, ele escreveria uma "primeira tarefa" ao lado de uma árvore existente e relataria sucesso — portanto, descubra antes de escrever qualquer coisa.

Localize a árvore de avaliação conforme ${CLAUDE_PLUGIN_ROOT}/reference/repo-layout.md. Se o repositório já tiver tarefas, relate o inventário e pare: quantos arquivos de tarefa e onde, quantos diretórios de execução e se existem experimentos. Em seguida, aponte o usuário para os skills que atuam sobre o que já existe —

• /coder-eval:lint-tasks para revisar as tarefas já existentes;
• /coder-eval:analyze para ler uma execução concluída.

Crie a estrutura somente se o repositório não tiver nenhuma, ou se o usuário solicitar explicitamente mais após ver o inventário. Nunca sobrescreva um arquivo de tarefa existente, independentemente do que for solicitado; adicione ao lado dele.

Um repositório com tarefas mas sem experimentos está parcialmente configurado, não vazio. Relate isso como está e ofereça a peça ausente — não crie uma primeira tarefa como se não houvesse nada.

Etapa 3 — Escanear o que é testável

Procure por estes itens, em ordem de prioridade, e relate o que encontrou antes de escrever qualquer coisa:

1. Skills do Claude Code — glob .claude/skills/*/SKILL.md e **/skills/*/SKILL.md. Skills são o item de maior valor para avaliar, porque saber se eles são acionados é invisível até falhar. Se encontrar algum, recomende /coder-eval:check-skill para cada um deles — essa é uma suíte de ativação projetada para isso, não algo para ser feito manualmente aqui.
2. Um servidor MCP — um .mcp.json, uma chave mcpServers em package.json ou pyproject.toml, ou um ponto de entrada do servidor (um server.py / index.ts que registra ferramentas). Anote quais ferramentas ele expõe.
3. Um ponto de entrada CLI — [project.scripts] em pyproject.toml, bin ou scripts em package.json, ou um Makefile com alvos utilizáveis.

Se o repositório for um monorepo com muitos diretórios de skill ou pacote, limite a varredura e pergunte em qual subárvore focar, em vez de relatar cinquenta candidatos.

Se você não encontrar nada nessas três categorias, diga isso claramente. Em seguida, ofereça a menor coisa útil como alternativa — uma tarefa que execute um script ou comando de teste que o repositório já possui e verifique sua saída — em vez de criar uma suíte vazia que não prova nada.

Etapa 4 — Criar uma tarefa real

Escreva na árvore que a etapa 2 resolveu. Se o repositório não tiver nenhuma, proponha um local e pergunte. A regra de nunca sobrescrever da etapa 2 ainda se aplica aqui — é o único lugar onde essa regra vive.

Escreva uma tarefa derivada do que a etapa 3 encontrou:

• Uma CLI — uma tarefa cujo prompt solicite algo que a CLI faz, com critérios que verifiquem o conteúdo do arquivo resultante, não apenas que um arquivo apareceu.
• Um servidor MCP — uma tarefa que exercite uma ferramenta específica e verifique seu efeito.
• Skills — aponte para /coder-eval:check-skill; uma suíte de ativação tem um formato diferente de uma tarefa de capacidade e aquele skill a constrói corretamente.

Prompts instruem, critérios validam. Não repita no prompt o que os critérios verificam — um prompt que diz "certifique-se de que o arquivo contém X" testa compreensão de leitura, não capacidade.

Antes de escrever os critérios, leia ${CLAUDE_PLUGIN_ROOT}/reference/task-rubric.md. É a lista de verificação compartilhada para saber se uma tarefa pode passar pelo motivo errado, e a única tarefa que você cria aqui é o exemplo que todas as tarefas futuras deste repositório usarão como modelo — então vale a pena acertar agora em vez de corrigir depois. Para tipos de critério e seus campos, leia ${CLAUDE_PLUGIN_ROOT}/reference/criteria.md.

Use /coder-eval:task se o usuário quiser mais tarefas depois desta; é o mesmo loop de criação com um resumo em linguagem natural.

Etapa 5 — Variáveis de ambiente

Escreva as variáveis que o agente escolhido precisa (por exemplo, ANTHROPIC_API_KEY para o agente claude-code padrão) em .env.example — crie-o ou anexe a ele.

Nunca escreva .env: ele pode já conter segredos reais. Se .env não existir, verifique se ele está no .gitignore antes de sugerir que o usuário crie um, e informe se não estiver.

Etapa 6 — Validar

Execute coder-eval plan <task-directory>/*.yaml e itere até que o código de saída seja 0. Isso valida o esquema da tarefa por meio dos modelos reais, então um nome de campo que você adivinhou errado aparece aqui. plan aceita arquivos de tarefa: um argumento de diretório simples é rejeitado imediatamente (Expected a YAML task file but got a directory), então sempre passe caminhos explícitos ou um glob. Não sugira coder-eval plan sem argumento — a descoberta sem argumentos só funciona a partir de uma cópia fonte do coder-eval e retorna 1 em qualquer outro lugar.

Um diretório vazio ou sem tarefas não produz um sucesso significativo — se plan relatar nenhuma tarefa, trate isso como uma falha na criação, não como um sucesso. Observe que o erro de diretório simples é um resultado diferente: significa que você passou o formato de argumento errado, não que a estrutura está vazia.

Etapa 7 — Relatar

Informe ao usuário:

• o que você encontrou na varredura e o que escolheu avaliar primeiro;
• o comando exato para executá-lo: coder-eval run <caminho>, além de uma nota de que isso custa tokens reais e precisa das credenciais da etapa 5;
• que /coder-eval:check-skill é o próximo passo se o repositório fornecer skills;
• que /coder-eval:analyze lê o diretório de execução depois, e /coder-eval:ci transforma a suíte em uma proteção do GitHub Actions.