Casos de uso comuns

Esta página reúne cenários típicos do Jarvis Code CLI junto com exemplos de prompt prontos para usar — copie-os como estão ou adapte-os à sua necessidade.

Entender um projeto desconhecido

Ao assumir um repositório desconhecido, um bom primeiro passo é usar jarvis --plan ou pressionar Shift-Tab para entrar no Plan mode (modo de planejamento), assim o agente produz um plano de investigação antes de tocar em qualquer coisa:

Me dê uma visão geral da arquitetura deste repositório. Especificamente:
1. Onde fica o ponto de entrada e o que acontece na inicialização?
2. Como os módulos principais dependem uns dos outros?
3. Como configuração e dados são carregados?
Por fim, desenhe um diagrama simples de dependência entre módulos.

Você também pode focar em uma pergunta específica:

Como funciona o event loop em src/runtime? De onde vêm os eventos e quem os consome?

Como a "aprovação de permissão" está implementada neste projeto? Quais arquivos estão envolvidos e quais são os tipos principais?

Para investigações de grande porte, você pode fazer o agente principal despachar subagentes para tratar subtarefas em paralelo. Veja Agentes e subagentes.

Implementar uma nova funcionalidade

Descreva o requisito e os critérios de aceitação com clareza. Para mudanças complexas, use o Plan mode para confirmar a abordagem antes da execução:

Adicione um utilitário de retry em src/utils:
- Assinatura: retry<T>(fn: () => Promise<T>, options): Promise<T>
- Opções: maxAttempts, initialDelayMs, backoffFactor
- Em caso de falha, lance o erro da última tentativa
- Adicione uma suíte de testes unitários cobrindo: sucesso na primeira tentativa, sucesso após retries e falha em todas as tentativas

Se o resultado não estiver certo, basta descrever o que quer mudar — não precisa editar manualmente:

O cálculo de backoff usou um valor fixo. Quero adicionar algum jitter para evitar o efeito de thundering herd. Atualize a implementação e os testes.

Corrigir um bug

Informe o sintoma, os passos de reprodução e o comportamento esperado de uma vez só, para evitar idas e vindas:

Executar npm test ocasionalmente produz este erro:

  TypeError: Cannot read properties of undefined (reading 'id')
      at SessionStore.update (src/session/store.ts:142:18)

Só aparece em casos de teste que disparam várias atualizações concorrentes. Localize a causa e corrija, depois rode a suíte completa para confirmar.

Quando a causa raiz não estiver clara, peça ao agente para investigar antes de mudar:

Feedback de usuário: depois de um login bem-sucedido, o primeiro refresh da página devolve para a tela de login; o segundo refresh funciona. Encontre primeiro as causas mais prováveis e liste os pontos mais suspeitos. Vou confirmar a direção antes de você começar a mudar.

Para tarefas puramente mecânicas, você pode deixar o agente correr livre:

Rode a suíte de testes, corrija todos os casos que falharem e rode de novo para confirmar que está tudo verde.

Escrever testes e refatorar

Tarefas com fronteiras claras e critérios de aceitação explícitos são especialmente adequadas para o agente:

src/parser/markdown.ts hoje quase não tem testes. Adicione uma suíte de testes unitários cobrindo: parágrafos normais, listas aninhadas, blocos de código, tabelas, citações e conteúdo misto. Siga o estilo de teste já usado no projeto.

Extraia para um middleware o padrão repetido "ler body → validar → logar → responder" em src/handlers. Rode os testes depois para garantir que o comportamento existente não mudou.

Para refatorações que tocam vários arquivos, use o Plan mode primeiro para confirmar a abordagem. Você também pode usar /fork para criar uma bifurcação experimental da sessão e trocar para ela pelo /sessions — bifurcar nunca atrapalha a sessão original, então basta voltar se não gostar do resultado.

Scripts pontuais e automação

Edições de arquivo em lote, coleta de estatísticas e comparações de pesquisa podem ser feitas com um único prompt:

Troque todas as declarações var em arquivos .js sob src por const ou let, preferindo const quando possível. Rode o lint ao terminar para confirmar.

Analise os logs de acesso em logs/ dos últimos 7 dias. Para cada caminho de API, calcule a contagem de chamadas e os tempos de resposta p50 e p99, e produza o resultado como uma tabela Markdown.

Pesquise as principais opções de injeção de dependência para TypeScript (tsyringe, inversify, awilix). Compare-as em três dimensões: estilo de API, necessidade de decorators e overhead em runtime. Me dê uma recomendação que caiba em uma página.

Para tarefas em lote que você sabe serem seguras, use --yolo ou /yolo para pular os pedidos de aprovação, ou adicione regras de allowlist pré-aprovadas para ferramentas específicas em Arquivos de configuração.

Tarefas agendadas e lembretes

Dentro de uma sessão interativa, você pode pedir ao agente que crie lembretes únicos ou tarefas recorrentes. O agente gera uma expressão cron no seu fuso horário local e reinjeta o prompt na mesma sessão quando ela dispara:

Me lembre às 14:30 de verificar o deploy.

Todo dia útil às 9h, resuma para mim as falhas recentes de CI.

Verifique o endpoint de saúde de produção a cada hora e me avise se algo parecer errado.

Volte em uns 10 minutos e verifique se o build terminou.

Tarefas agendadas ficam vinculadas à sua sessão — fechar o terminal não é problema, e elas são recarregadas e continuam disparando quando você retoma a mesma sessão com jarvis --session. Elas não são levadas para sessões novas. Tarefas recorrentes com mais de 7 dias disparam uma última vez com stale: true e então o sistema as remove. Para continuar um agendamento, peça ao agente que o crie novamente.

Para ver quais tarefas estão pendentes, basta perguntar ao agente (ele chama a ferramenta somente leitura CronList). Para cancelar uma tarefa, diga ao agente que a remova ou informe o ID de 8 caracteres. Para a referência completa das ferramentas, veja Tarefas agendadas. O interruptor global é JARVIS_DISABLE_CRON=1.

Gerar e manter documentação

Acabei de mudar a assinatura da interface em src/auth/login.ts. Atualize o JSDoc correspondente, o código de exemplo do README e qualquer parágrafo em docs/en/guides que mencione essa interface.

Para toda função pública sob src/api que esteja sem docstring, adicione um comentário de documentação seguindo o estilo dos existentes.

Com base nas implementações de comando em src/cli, gere um rascunho de referência de comandos listando cada subcomando, seus argumentos e valores padrão. Coloque em docs/en/reference para eu revisar depois.

Quando precisar de um registro ou de uma retrospectiva, use jarvis export <sessionId> para empacotar a sessão como ZIP, ou use /export-md dentro da TUI para exportar uma transcrição legível em Markdown.

Coordenar tarefas maiores

Para uma tarefa multiagente experimental, use o modo Tower. Ele coordena workers em git worktrees isolados e faz um agente revisor controlar os merges.

Para trabalho autônomo em direção a um resultado delimitado, use o modo de metas. Ele mantém uma meta ativa ao longo dos turnos e expõe controles de status, pausa, retomada e cancelamento.

Próximos passos

• Agentes e subagentes — como fazer o agente despachar subtarefas para execução em paralelo
• Hooks — dispare scripts locais na conclusão de tarefas e em outros pontos do ciclo de vida
• Ferramentas integradas — referência completa de todas as ferramentas que o agente pode chamar