---
title: Engenharia de prompts
description: Boas práticas para escrever prompts eficazes
---

---

Prompts eficazes são a base de um desenvolvimento assistido por IA bem-sucedido. Solicitações claras e específicas, com o contexto adequado, permitem que o Verdent entregue resultados precisos e relevantes.

### O que você vai aprender

- Boas práticas para escrever prompts eficazes
- Como fornecer contexto e evitar erros comuns
- Técnicas avançadas como @-menções e delegação a subagentes
- Exemplos de prompts bem estruturados
- Estratégias de refinamento iterativo

---

## O que torna um prompt eficaz

Prompts eficazes são claros, específicos e fornecem o contexto necessário para que o Verdent entenda sua intenção e entregue resultados precisos.

**Princípios-chave:**
- **Seja específico** - Diga exatamente o que você precisa, não faça solicitações vagas
- **Inclua detalhes** - Forneça especificações técnicas quando tiver preferências
- **Defina o escopo** - Esclareça quais arquivos/componentes estão envolvidos
- **Forneça contexto** - Ajude o Verdent a entender sua arquitetura
- **Indique os resultados** - Descreva como é o sucesso
- **Use linguagem natural** - Nenhuma sintaxe especial é necessária

**Exemplos de transformação:**

**Ruim:**
```
Fix the code
```

**Bom:**
```
Add input validation to the email field in ContactForm.js to reject invalid email formats
```

**Ruim:**
```
Add authentication
```

**Bom:**
```
Add JWT authentication using the same middleware pattern as auth.js, store tokens in httpOnly cookies
```

---

## Erros comuns em prompts

<Tabs>
  <Tab title="Ser vago demais">
    **Exemplos de prompts:**
    ```
    Make the app better
    ```
    ```
    Fix the bugs
    ```

    | Problema | Solução |
    |---------|----------|
    | O Verdent não sabe quais melhorias você quer nem quais bugs corrigir | Especifique exatamente o que precisa de melhoria ou qual bug corrigir |
  </Tab>

  <Tab title="Omitir contexto">
    **Exemplos de prompts:**
    ```
    Add authentication
    ```

    | Problema | Solução |
    |---------|----------|
    | O Verdent pode implementar JWT quando você usa OAuth, ou vice-versa | Especifique a abordagem de implementação, os padrões existentes e os requisitos técnicos |
  </Tab>

  <Tab title="Muito de uma vez">
    **Exemplos de prompts:**
    ```
    Build the entire user management system with authentication, authorization, profiles, settings, and admin dashboard
    ```

    | Problema | Solução |
    |---------|----------|
    | Solicitações complexas envolvendo múltiplos sistemas são mais difíceis de executar corretamente de uma só vez | Divida em tarefas menores - comece com autenticação, depois autorização e, por fim, perfis |
  </Tab>

  <Tab title="Escopo ausente">
    **Exemplos de prompts:**
    ```
    Update the validation logic
    ```

    | Problema | Solução |
    |---------|----------|
    | Não está claro quais arquivos ou validações modificar | Especifique o escopo: "Atualize a validação em UserController.js para exigir senhas fortes" |
  </Tab>

  <Tab title="Requisitos não declarados">
    **Exemplos de prompts:**
    ```
    Expecting Verdent to know your specific business rules or constraints
    ```

    | Problema | Solução |
    |---------|----------|
    | O Verdent implementa soluções genéricas sem seus requisitos específicos | Declare explicitamente todas as restrições, regras de negócio e requisitos |
  </Tab>

  <Tab title="@-menções ausentes">
    **Exemplos de prompts:**
    ```
    Referencing files without including them in context
    ```

    | Problema | Solução |
    |---------|----------|
    | O Verdent pode não ter acesso aos arquivos que você está discutindo | Use @nomedoarquivo.js para incluir explicitamente os arquivos relevantes |
  </Tab>

  <Tab title="Ignorar erros">
    **Exemplos de prompts:**
    ```
    Repeatedly asking for the same thing when Verdent encounters errors
    ```

    | Problema | Solução |
    |---------|----------|
    | A mesma abordagem produz os mesmos erros | Leia as mensagens de erro e ajuste o prompt com base no que falhou |
  </Tab>

  <Tab title="Pular o Plan Mode">
    **Exemplos de prompts:**
    ```
    Requesting large refactorings or multi-file changes without using Plan Mode first
    ```

    | Problema | Solução |
    |---------|----------|
    | Você só vê o escopo completo quando os arquivos já foram modificados | Mude para o Plan Mode em tarefas complexas para revisar a abordagem antes da execução |

    <Tip>
    Ative o Plan Mode para mudanças complexas a fim de revisar a abordagem antes da execução; isso identifica mal-entendidos cedo.
    </Tip>
  </Tab>

  <Tab title="Sem controle de versão">
    **Exemplos de prompts:**
    ```
    Using Auto-Run or Skip Permission Mode without Git initialized
    ```

    | Problema | Solução |
    |---------|----------|
    | Não há rede de segurança se o Verdent fizer mudanças indesejadas | Sempre tenha o Git inicializado e com commit antes de usar modos permissivos |
  </Tab>

  <Tab title="Sem pedido de entrevista">
    **Exemplos de prompts:**
    ```
    Providing incomplete requirements and expecting Verdent to guess correctly
    ```

    | Problema | Solução |
    |---------|----------|
    | O Verdent implementa com base em suposições que podem não corresponder às suas necessidades | Peça ao Verdent que entreviste você: "Faça perguntas esclarecedoras sobre os requisitos antes de criar o plano" |
  </Tab>
</Tabs>

---

## Exemplos de prompts bem estruturados

<Tabs>
  <Tab title="Implementação de funcionalidade">
    Criar novas funcionalidades com requisitos e restrições claros:

    ```
    Create a POST /api/tasks endpoint that:
    - Accepts task title (required), description (optional), and category_id (required)
    - Validates that the category exists in the database
    - Returns 400 if validation fails with descriptive error messages
    - Saves the task to the database and returns the created task with 201 status
    - Add this to the existing tasks router in routes/tasks.js
    - Create the controller method in controllers/taskController.js
    - Use the existing error handling pattern from other controllers
    ```

    **O que torna isso eficaz:**
    - Requisitos claros para entradas e validação
    - Locais específicos de arquivo para implementação
    - Referência a padrões existentes para manter a consistência
    - Códigos de status HTTP esperados e tratamento de erros
  </Tab>

  <Tab title="Correção de bug">
    Descrever problemas com contexto e soluções propostas:

    ```
    Fix the race condition in payment processing at checkout. When multiple users submit payments simultaneously, some transactions fail with "duplicate order ID" errors. The issue appears to be in PaymentController.js around line 45 where we generate order IDs. Implement proper locking or use UUID generation to ensure unique IDs even under concurrent load.
    ```

    **O que torna isso eficaz:**
    - Descrição clara do problema com sintomas
    - Localização específica do problema (arquivo e número da linha)
    - Contexto sobre quando acontece (usuários simultâneos)
    - Sugestões de abordagens de solução
  </Tab>

  <Tab title="Refatoração">
    Alterar a implementação preservando o comportamento:

    ```
    Refactor the authentication middleware in middleware/auth.js to use JWT tokens instead of session cookies. Keep the same authorization logic, but:
    - Replace session validation with JWT verification
    - Store tokens in httpOnly cookies
    - Maintain the existing user object structure that routes expect
    - Update only the authentication mechanism, don't change authorization rules
    - Ensure all existing routes continue to work without modification
    ```

    **O que torna isso eficaz:**
    - Objetivo claro (JWT em vez de sessões)
    - Arquivo específico a refatorar
    - Restrições explícitas (o que NÃO deve mudar)
    - Requisito de compatibilidade retroativa
  </Tab>

  <Tab title="Testes">
    Escrever testes com cobertura abrangente:

    ```
    Write comprehensive unit tests for the UserService class in services/UserService.js. Cover:
    - User creation with valid and invalid data
    - Email validation edge cases (empty, malformed, duplicate)
    - Password hashing verification
    - User lookup by ID and email
    - Error handling for database failures
    Use Jest and follow the testing patterns in existing service tests
    ```

    **O que torna isso eficaz:**
    - Classe/arquivo específico a testar
    - Lista completa de cenários a cobrir
    - Framework de testes especificado
    - Referência a padrões de teste existentes
  </Tab>

  <Tab title="Criação de componente">
    Construir componentes de UI com especificações detalhadas:

    ```
    Create a reusable SearchBar component for the product catalog with:
    - Text input with real-time debounced search (300ms delay)
    - Category dropdown filter (fetch options from /api/categories)
    - Price range slider (min $0, max $1000)
    - Clear filters button
    - Use Material-UI components to match existing design
    - Emit search parameters via onChange callback to parent
    - Include PropTypes for all props
    ```

    **O que torna isso eficaz:**
    - Lista completa de funcionalidades com detalhes específicos
    - Especificações técnicas (debounce de 300ms, faixa de preço)
    - Biblioteca de UI especificada (Material-UI)
    - Abordagem de integração (callback para o componente pai)
  </Tab>
</Tabs>

---

## Técnicas avançadas de prompt

<Tabs>
  <Tab title="@-menções">
    Faça referência a arquivos, componentes ou subagentes específicos:

    ```
    @auth.js @UserController.js Refactor authentication to use the same validation pattern
    ```

    **Benefícios:**
    - Garante que o Verdent tenha o contexto exato ao incluir explicitamente arquivos específicos
    - Evita ambiguidade em bases de código grandes com nomes de arquivos semelhantes
    - Garante que todo o código relevante esteja visível simultaneamente para refatoração precisa e correspondência de padrões
    - Essencial ao referenciar padrões de implementação de um arquivo para aplicar em outro
  </Tab>

  <Tab title="Plan Mode">
    Mude para o Plan Mode antes da execução em mudanças grandes:

    ```
    Switch to Plan Mode
    Refactor the entire API layer to use TypeScript with strict type checking
    ```

    **Benefícios:**
    - Revise a abordagem completa do Verdent antes que qualquer arquivo seja modificado
    - Evita erros custosos em refatorações grandes ou mudanças arquiteturais
    - Itere no plano, adicione restrições ou redirecione completamente antes do início da execução
    - Peça que o Verdent entreviste você com perguntas esclarecedoras para reunir todos os requisitos antecipadamente
  </Tab>

  <Tab title="Delegação a subagentes">
    Delegue tarefas especializadas a subagentes integrados ou personalizados:

    ```
    @Code-reviewer Review the security vulnerabilities in authentication flow
    @Explorer Find all files that import the deprecated API client
    @Verifier Validate the authentication logic in the middleware
    ```

    **Benefícios:**
    - Aproveite agentes especializados otimizados para tarefas específicas (exploração, verificação, revisão de código)
    - Expertise focada e resultados mais rápidos do que o processamento de uso geral
    - Execute várias análises em paralelo para reduzir drasticamente o tempo total de execução
    - Crie subagentes personalizados com conhecimento específico de domínio para os requisitos únicos do seu projeto

    **Subagentes padrão integrados:**
    - `@Verifier` - Verificações rápidas de código e validação
    - `@Explorer` - Exploração rápida da base de código e localização de arquivos
    - `@Code-reviewer` - Avaliação da qualidade do código

    <Tip>
    Use @Explorer para perguntas sobre a base de código e @Code-reviewer para análise de segurança; a delegação direcionada é mais rápida do que o roteamento pelo agente principal.
    </Tip>
  </Tab>

  <Tab title="Think Hard Mode">
    Ative o raciocínio estendido para desafios sofisticados:

    ```
    Think: Design the optimal database schema for a multi-tenant SaaS application
    ```

    **Benefícios:**
    - Ativa o raciocínio estendido para uma análise mais profunda de problemas complexos sob múltiplos ângulos
    - Avalia abordagens alternativas e casos extremos de forma mais completa
    - Produz soluções robustas onde a correção é fundamental
    - Respostas mais lentas e maior uso de créditos, mas evita retrabalho custoso decorrente de soluções apressadas e subótimas

    <Tip>
    Think Hard Mode se destaca em decisões de arquitetura, depuração complexa e problemas algorítmicos que exigem análise profunda.
    </Tip>
  </Tab>

  <Tab title="Refinamento iterativo">
    Construa sobre respostas anteriores com refinamento progressivo:

    ```
    Initial: "Create a dashboard component"
    Follow-up: "Add real-time data updates using WebSockets"
    Follow-up: "Now add filtering and sorting capabilities"
    ```

    **Benefícios:**
    - Permite o desenvolvimento incremental com testes em cada etapa antes de adicionar complexidade
    - Reduz riscos ao validar que cada camada funciona corretamente antes de construir sobre ela
    - Corrija o rumo imediatamente se as iterações produzirem resultados inesperados
    - Facilita identificar qual mudança específica introduziu um bug, já que cada iteração é pequena e contida

    <Tip>
    O refinamento iterativo reduz riscos: comece com escopo pequeno, verifique os resultados e expanda gradualmente.
    </Tip>
  </Tab>

  <Tab title="Baseado em restrições">
    Especifique o que NÃO deve mudar junto com o que deve mudar:

    ```
    Add caching to the API endpoints, but:
    - Don't modify the authentication middleware
    - Keep the existing error handling unchanged
    - Maintain backward compatibility with mobile clients
    ```

    **Benefícios:**
    - Define explicitamente os limites para evitar modificar sistemas críticos (autenticação, pagamentos)
    - Protege sistemas estáveis que devem permanecer inalterados por requisitos de conformidade ou risco
    - Evita ciclos custosos de implementar mudanças, descobrir funcionalidades quebradas e refazer soluções
    - Mantém a compatibilidade retroativa e protege código testado em produção de refatorações desnecessárias
  </Tab>

  <Tab title="Padrões de referência">
    Aponte para código existente como exemplos de implementação:

    ```
    Implement the new ProductService following the same pattern as UserService.js, including error handling, validation, and database transaction management
    ```

    **Benefícios:**
    - Garante que novas implementações mantenham consistência com as convenções estabelecidas
    - Torna a base de código mais sustentável e previsível
    - Reduz drasticamente a explicação necessária - aponte para exemplos em vez de descrever abordagens em detalhe
    - Aproveita padrões comprovados e testados em produção em vez de reinventar soluções
    - Reduz bugs e garante integração perfeita com os sistemas existentes
  </Tab>

  <Tab title="Planejamento com todos.md">
    Crie um arquivo todos.md para acompanhar tarefas complexas de múltiplas etapas:

    ```
    Create a todos.md file with these tasks:
    1. Refactor authentication to use JWT tokens
    2. Update all controllers to use new auth middleware
    3. Add tests for authentication flow
    4. Update API documentation
    ```

    **Benefícios:**
    - Cria um roteiro claro e escrito que pode ser revisado, refinado e compartilhado com colegas de equipe
    - Ajusta-se facilmente à medida que os requisitos evoluem ao longo do projeto
    - Persiste entre sessões, permitindo pausar o trabalho, retomar depois e entender imediatamente onde você parou
    - Serve como um artefato do projeto que documenta o que foi planejado, concluído e o que resta para manutenção e onboarding futuros
  </Tab>

  <Tab title="Limpar contexto">
    Inicie novas sessões entre diferentes todos para um contexto limpo:

    ```
    After completing todo #1: "Start a new session"
    Then: "Let's work on todo #2 from todos.md"
    ```

    **Benefícios:**
    - Evita contaminação de contexto, em que detalhes de tarefas anteriores influenciam indevidamente o trabalho atual
    - Garante o foco apenas no todo atual, sem bagagem de tarefas anteriores
    - Reduz o uso de tokens ao não carregar histórico de conversa desnecessário
    - Torna as respostas mais rápidas e mais eficientes em créditos
    - Cria checkpoints naturais para testar e fazer commit das mudanças, mantendo um histórico Git limpo e facilitando o isolamento de problemas
  </Tab>

  <Tab title="Servidores MCP">
    Use servidores MCP (Model Context Protocol) para injetar contexto especializado:
    - Documentação específica do projeto
    - Especificações de API (OpenAPI, schemas GraphQL)
    - Conhecimento específico de framework

    **Benefícios:**
    - Aprimora a compreensão do Verdent sobre frameworks personalizados, ferramentas internas e domínios especializados que não estão em seus dados de treinamento
    - Elimina a necessidade de explicar repetidamente sistemas personalizados ao injetar diretamente especificações de API e documentação específicas da organização
    - Permite o uso correto de APIs internas e sistemas proprietários que seriam impossíveis de transmitir apenas por prompts
  </Tab>
</Tabs>

---

## Incluindo contexto nos prompts

<Tabs>
  <Tab title="@-menções para arquivos">
    Inclua explicitamente arquivos relevantes no contexto:

    ```
    @models/User.js @controllers/UserController.js Add password reset functionality
    ```

    **Quando usar:**
    - Ao trabalhar com arquivos fortemente acoplados (model e controller, service e testes)
    - Ao referenciar padrões de implementação de um arquivo para aplicar em outro
    - Ao coordenar mudanças entre vários arquivos relacionados
    - Em bases de código grandes com nomes de arquivos semelhantes, onde a detecção automática pode perder contexto
    - Sempre use ao pedir ao Verdent para "seguir o mesmo padrão de..." a fim de garantir que ele tenha o código exato
  </Tab>

  <Tab title="Arquitetura do projeto">
    Inclua contexto de alto nível sobre sua stack:

    ```
    This is a MERN stack application (MongoDB, Express, React, Node.js) with JWT authentication. Add role-based access control following our existing middleware pattern.
    ```

    **Quando usar:**
    - Ao implementar funcionalidades que precisam se integrar à sua stack tecnológica existente
    - No primeiro trabalho em uma base de código ou em funcionalidades que abrangem múltiplas camadas (do frontend ao banco de dados)
    - Quando sua stack tem opiniões fortes (GraphQL vs REST, Redux vs Context API) que afetam as escolhas de implementação
    - Quando você precisa que o Verdent escolha a abordagem que se encaixa no seu sistema em vez de uma solução genérica
  </Tab>

  <Tab title="Padrões existentes">
    Aponte para código que demonstra suas convenções:

    ```
    Follow the same error handling pattern used in ProductController.js - return consistent error objects with status codes and descriptive messages
    ```

    **Quando usar:**
    - Quando você quer que o novo código mantenha consistência com as convenções estabelecidas (tratamento de erros, validação, logging, testes)
    - Ao implementar funcionalidade semelhante em uma nova área da base de código
    - No onboarding em partes desconhecidas da base de código, onde você quer aprender e replicar padrões existentes
    - Quando você quer evitar descrever padrões em detalhe e precisa que o Verdent capture nuances difíceis de articular
  </Tab>

  <Tab title="Restrições técnicas">
    Indique limitações ou requisitos:

    ```
    We're using TypeScript with strict mode enabled, React 18 with hooks only (no class components), and Material-UI v5 for styling
    ```

    **Quando usar:**
    - Quando seu projeto tem requisitos tecnológicos específicos (modo strict do TypeScript, apenas React hooks, sem dependências externas)
    - Ao trabalhar com restrições legadas (suporte ao IE11, compatibilidade com Node.js 14)
    - Quando requisitos de conformidade ditam escolhas (acessibilidade WCAG, tratamento de dados GDPR)
    - Ao usar versões específicas de bibliotecas com mudanças incompatíveis entre versões
    - Quando você precisa impedir que o Verdent proponha soluções que violem os limites técnicos do seu projeto
  </Tab>

  <Tab title="Lógica de negócio">
    Explique regras específicas do domínio:

    ```
    Users can only view tasks assigned to them or their team. Managers can view all tasks in their department. Admins can view everything.
    ```

    **Quando usar:**
    - Ao implementar funcionalidades com regras específicas do domínio que o Verdent não pode inferir apenas do código
    - Lógica de autorização (quem pode acessar o quê), fluxos de trabalho de negócio (processos de aprovação, máquinas de estado)
    - Regras de validação (políticas de senha, restrições de dados), restrições de domínio (limites de estoque, regras de preço)
    - Ao construir modelos de dados em que relacionamentos entre entidades e cardinalidade precisam de explicação
    - Ao implementar cálculos (regras de desconto, cálculo de impostos, estruturas de comissão)
    - Quando você precisa que o Verdent aplique corretamente as regras de negócio da sua organização, não apenas código funcional
  </Tab>

  <Tab title="Contexto de erro">
    Compartilhe mensagens de erro ou logs ao depurar:

    ```
    Getting "TypeError: Cannot read property 'id' of undefined" at UserController.js:42 when trying to update user profiles. The req.user object exists but doesn't have an id property after the recent auth middleware changes.
    ```

    **Quando usar:**
    - Sempre inclua mensagens de erro completas, stack traces e logs ao corrigir bugs
    - Erros em tempo de execução (exceções, crashes), falhas de build (erros de compilação, violações de linting)
    - Falhas de teste (erros de asserção, problemas de timeout), comportamento inesperado (saída errada, dados ausentes)
    - Quando você tem mensagens de erro exatas com números de linha e o stack trace completo mostrando a cadeia de chamadas
    - Quando você pode fornecer contexto sobre quando ocorre (sempre, intermitentemente, condições específicas)
    - Quando você quer melhorar drasticamente a capacidade do Verdent de identificar causas-raiz em vez de adivinhar
  </Tab>

  <Tab title="Carregamento automático">
    O Verdent carrega automaticamente arquivos relevantes com base na sua solicitação:
    - Arquivos mencionados pelo nome nos prompts
    - Arquivos relacionados no mesmo diretório
    - Arquivos do projeto acessados com frequência

    **Quando confiar nisso:**
    - Para referências de arquivo padrão, em que os relacionamentos são óbvios
    - Ao mencionar componentes pelo nome e o Verdent precisa carregar aquele arquivo específico
    - Ao trabalhar com arquivos no mesmo diretório que costumam funcionar juntos
    - Ao acessar arquivos do projeto usados com frequência (package.json, arquivos de configuração)
    - Funciona bem para cenários simples em bases de código bem organizadas
    - Para refatorações complexas de múltiplos arquivos, partes distantes da base de código ou nomes de arquivo ambíguos, use @-menções explícitas
  </Tab>

  <Tab title="Regras de projeto/usuário">
    Configure contexto persistente por meio de arquivos de regras (Settings → Rules):

    **Regras de usuário (VERDENT.md):**
    Preferências globais aplicadas a todos os projetos

    **Regras de projeto (AGENTS.md):**
    Padrões específicos do projeto - padrões arquiteturais, padrões de código

    **Regras de plano (plan_rules.md):**
    Personalize o formato e o conteúdo do plano no Plan Mode

    **Quando usar:**
    - Quando você fornece repetidamente o mesmo contexto entre sessões
    - Regras de usuário para preferências pessoais (estilo de código, bibliotecas preferidas, padrões que você favorece)
    - Regras de projeto para padrões da equipe (decisões arquiteturais, convenções de nomenclatura, requisitos de teste)
    - Valiosas para o onboarding de novos membros da equipe (codifica o conhecimento tribal)
    - Para manter a consistência em equipes grandes e reduzir a verbosidade dos prompts
    - Invista em arquivos de regras quando seu projeto estiver maduro o suficiente para ter padrões estabelecidos que valha a pena documentar
  </Tab>

  <Tab title="Imagens">
    Inclua capturas de tela, mockups ou diagramas:

    ```
    @screenshot.png Implement this UI design with React components
    ```

    **Quando usar:**
    - Quando a informação visual comunica os requisitos de forma mais eficaz do que o texto
    - Implementação de UI/UX (mockups de design, wireframes, fluxos de usuário)
    - Depuração de problemas visuais (captura de tela de um layout quebrado, problemas de renderização)
    - Compreensão de arquiteturas complexas (diagramas de sistema, schemas de banco de dados, fluxogramas)
    - Essencial para design responsivo, análise de acessibilidade e reprodução de erros
    - Traduzir designs de ferramentas como Figma ou Sketch em código
    - Uma única captura de tela bem feita costuma transmitir detalhes que levariam parágrafos para descrever
  </Tab>

  <Tab title="Links de sites">
    Faça referência a documentação ou exemplos externos:

    ```
    Ultrathink: Read this API documentation at https://api-docs.example.com/v1/endpoints and implement the authentication flow
    ```

    **Quando usar:**
    - Ao implementar integrações com APIs ou bibliotecas externas que tenham documentação oficial online
    - Especialmente valioso quando a biblioteca tem opções de configuração complexas ou fluxos de autenticação
    - Use o prefixo "Ultrathink:" para instruir o Verdent a buscar e analisar o conteúdo da web antes de gerar código
    - Essencial para APIs em rápida evolução, em que a documentação é mais atual do que os dados de treinamento
    - Ao seguir padrões específicos de framework (Next.js App Router, Vue Composition API)
    - Garante que as implementações correspondam às versões atuais da API e sigam as recomendações oficiais
  </Tab>
</Tabs>

---

## Estratégias de refinamento iterativo

<Tabs>
  <Tab title="Do amplo ao específico">
    **Prompt inicial:**
    ```
    Add authentication to the API
    ```

    A resposta do Verdent pode ser genérica. Refine:

    ```
    Use JWT tokens stored in httpOnly cookies, implement refresh token rotation, and follow the authentication pattern from our existing UserController
    ```

    **Quando usar:** Começar com uma solicitação geral e depois adicionar detalhes com base na resposta inicial
  </Tab>

  <Tab title="Revisar e corrigir">
    Se a implementação do Verdent não corresponder às expectativas:

    ```
    The validation logic is good, but use Joi schema validation instead of manual checks. Match the validation pattern in ProductController.js
    ```

    **Quando usar:** Após revisar a saída e identificar melhorias específicas
  </Tab>

  <Tab title="Prompts de acompanhamento">
    Construa de forma incremental:

    ```
    Initial: "Create a UserProfile component"
    Follow-up: "Add an avatar upload feature with image preview"
    Follow-up: "Add validation - max 5MB, only jpg/png formats"
    Follow-up: "Show upload progress with a progress bar"
    ```

    **Quando usar:** Construir funcionalidades progressivamente na mesma sessão
  </Tab>

  <Tab title="Pedir explicações">
    Se a implementação parecer inesperada:

    ```
    Why did you use Redux instead of Context API? Can you explain the trade-offs for this use case?
    ```

    Depois refine com base na compreensão:

    ```
    Actually, use Context API for consistency with the rest of our application
    ```

    **Quando usar:** Entender o raciocínio antes de solicitar mudanças
  </Tab>

  <Tab title="Refinamento no Plan Mode">
    Para mudanças complexas:

    ```
    Switch to Plan Mode
    Show me how you would refactor the authentication system to support OAuth providers
    ```

    Revise o plano, faça perguntas e itere na abordagem antes da execução.

    **Quando usar:** Mudanças arquiteturais importantes que exigem revisão
  </Tab>

  <Tab title="Fornecer exemplos">
    Se o estilo do Verdent não corresponder ao seu:

    ```
    The component structure is close, but use this pattern instead:
    [paste example of your preferred structure]
    Apply this same pattern to the remaining components
    ```

    **Quando usar:** Estabelecer ou reforçar preferências de estilo de código
  </Tab>

  <Tab title="Esclarecer restrições">
    Se a saída violar restrições não declaradas:

    ```
    Good approach, but don't modify the database schema - work within the existing User table structure
    ```

    **Quando usar:** Adicionar restrições descobertas após ver a implementação inicial
  </Tab>

  <Tab title="Aprimoramento progressivo">
    Comece com a funcionalidade central e adicione recursos iterativamente:

    ```
    Step 1: "Create basic CRUD endpoints for tasks"
    Step 2: "Add pagination to the GET endpoint"
    Step 3: "Add filtering by status and priority"
    Step 4: "Add full-text search across title and description"
    ```

    **Quando usar:** Construir funcionalidades complexas de forma incremental com testes em cada etapa
  </Tab>
</Tabs>

---

## Perguntas frequentes

<Accordion title="Quão específicos meus prompts devem ser?">
Seja específico o suficiente para eliminar ambiguidade, mas não explique demais detalhes óbvios. Inclua: caminhos exatos de arquivo, abordagem de implementação, resultados esperados e restrições. Ruim: "Corrija o código" - vago demais. Bom: "Adicione validação de entrada ao campo de e-mail em `ContactForm.js` para rejeitar formatos de e-mail inválidos" - escopo e objetivo claros. Na dúvida, opte por mais especificidade.
</Accordion>

<Accordion title="Qual é a diferença entre @-menções e carregamento automático de arquivos?">
O Verdent carrega automaticamente arquivos mencionados pelo nome nos prompts e arquivos relacionados no mesmo diretório. `@-mentions` (`@filename.js`) garantem explicitamente que um arquivo está no contexto, o que é fundamental ao trabalhar com arquivos fortemente acoplados, referenciar padrões de um arquivo para aplicar em outro ou quando a detecção automática pode perder contexto em bases de código grandes. Sempre use `@-mentions` ao pedir ao Verdent para "seguir o mesmo padrão de..." a fim de garantir a referência exata ao código.
</Accordion>

<Accordion title="Quando devo usar o Plan Mode em vez do modo normal?">
Use o Plan Mode para: refatorações grandes ou mudanças arquiteturais, modificações em múltiplos arquivos em que você quer revisar o escopo antes da execução, tarefas complexas em que você está incerto sobre os requisitos, ou quando você quer que o Verdent entreviste você com perguntas esclarecedoras antes da implementação. Pule o Plan Mode para: tarefas simples e bem definidas, correções rápidas de bugs ou operações de rotina. O Plan Mode adiciona sobrecarga, mas evita erros custosos em trabalhos complexos.
</Accordion>

<Accordion title="E se o Verdent não entender ou não seguir corretamente meu prompt?">
Use o refinamento iterativo: revise a saída, identifique o que está errado e forneça correções em um prompt de acompanhamento. Exemplo: "A lógica de validação está boa, mas use validação por schema Joi em vez de verificações manuais. Siga o padrão de validação em `ProductController.js`." Você também pode pedir explicações: "Por que você usou Redux em vez de Context API?" e depois refinar com base na compreensão. Não repita o mesmo prompt - ajuste com base no que falhou.
</Accordion>

<Accordion title="Preciso repetir o contexto do projeto em todos os prompts durante uma sessão?">
Não - o Verdent mantém o contexto da conversa dentro de uma sessão, então você não precisa repetir detalhes de arquitetura ou convenções já discutidos. No entanto, para restrições críticas ou quando as sessões ficam longas (`100+` mensagens), reafirme o contexto importante. Abordagem melhor: use regras de projeto (`AGENTS.md`) para documentar contexto persistente como stack tecnológica, padrões de código e padrões - assim você nunca precisa repeti-los.
</Accordion>

<Check>
Prompts bem estruturados, com intenção clara, contexto relevante e restrições específicas, produzem resultados melhores de forma consistente.
</Check>

---

## Veja também

<CardGroup cols={3}>
  <Card title="Gerenciamento de contexto" href="/docs/verdent-for-vscode/best-practices/context" icon="layer-group">
    Gerenciamento de janelas de contexto e estratégias de otimização
  </Card>
  <Card title="Modos de execução" href="/docs/verdent-for-vscode/execution-modes/overview" icon="toggle-on">
    Entendendo os modos de execução para diferentes cenários
  </Card>
  <Card title="Tratamento de erros" href="/docs/verdent-for-vscode/error-handling/recovery" icon="triangle-exclamation">
    Tratamento de erros e solução de problemas
  </Card>
</CardGroup>
