> For the complete documentation index, see [llms.txt](https://docs.adapta.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adapta.org/skip/comece-aqui/guia-de-engenharia-de-prompt-para-skip.md).

# Guia de Engenharia de Prompt para Skip

* **Agent (Automático):** O Skip decide o melhor caminho para o seu pedido.
* **Build:** Use quando tiver certeza de que quer mudar o código ou criar uma nova tela.
* **Chat:** Ideal para tirar dúvidas ou planejar ideias gastando apenas 1 crédito de construção (dependendo do seu plano).
* **Upload:** Use especificamente para enviar arquivos (PDF, Planilhas) que devem servir de base para o projeto.

{% embed url="<https://drive.google.com/file/d/1t7PmuIp33lC3tEVyMWW2TnnmuvCDYXQD/view?usp=drive_link>" %}

No Skip, escrever um bom prompt não exige "engenharia complexa" nem frameworks misteriosos. Exige ser **direto e específico**. Quanto mais clareza você der ao agente, melhor será o resultado — e menos créditos você vai gastar refazendo.

### A Regra de Ouro**Tudo o que você não especifica, você está terceirizando a decisão para o agente.** Se você não disser como quer, o Skip decide por você — e pode decidir diferente do que você imaginava.Por isso, um bom prompt sempre traz três pilares: **Objetivo, Especificações e Restrições**.

### Os Três Pilares na Prática

Vamos usar um exemplo simples e didático: imagine que você quer construir um sistema para uma escola.

#### 1. Objetivo

A **meta principal** — o que o sistema é na sua essência.

> 💬 *"Crie um sistema de gerenciamento para escolas."*

Esse é o núcleo. Sem ele, o agente não tem direção.

#### 2. Especificações

Os **detalhes** do que o sistema precisa ter ou como ele deve se parecer. Funcionalidades, telas, integrações, referências visuais.

> 💬 *"Tenha funcionalidade de cadastrar alunos e professores, e inspire-se no design do \[referência]."*

Quanto mais específico você for aqui, menos o agente vai precisar "chutar".

#### 3. Restrições

As **fronteiras** — o que o sistema deve ou **não** fazer. É aqui que você evita surpresas.

> 💬 *"Deve ter três tipos de acesso: professores, alunos e admin. Não deve ter nenhum outro tipo de acesso."*

As restrições protegem o projeto de decisões automáticas que podem fugir do escopo.

### Tamanho Ideal do Primeiro Prompt

No primeiro prompt, **foque apenas no básico**. Não tente descrever o sistema inteiro de uma vez — isso aumenta a chance de erro e o consumo desnecessário de créditos.

* Comece pela **funcionalidade principal**.
* Deixe o Skip entregar uma **base sólida**.
* **Evolua o projeto** em prompts seguintes, uma camada por vez.

{% hint style="danger" %}
**Evite prompts gigantes no início.** Eles sobrecarregam o agente, produzem resultados inconsistentes e gastam mais créditos do que a construção incremental.
{% endhint %}

### Momento Certo para o Banco de Dados

Esta é uma recomendação oficial para qualquer projeto que vai precisar guardar dados (cadastros, usuários, transações, conteúdo, etc.):

**Ative o Skip Cloud antes de enviar o primeiro prompt.**

Para isso, clique no ícone **"+"** na área do projeto e selecione **Skip Cloud: Banco de Dados, Autenticação e Segredos**.

Se esquecer, conecte **no máximo até o terceiro, quarto ou quinto prompt**. Evite deixar para depois da maior parte do app construída — adicionar banco mais tarde costuma exigir retrabalho significativo na estrutura de dados.

### Construção Incremental

O Skip rende muito melhor quando você constrói em **camadas**:

1. **Estrutura visual:** Defina as telas principais e os campos básicos.
2. **Lógica e navegação:** Adicione a lógica de negócio e as conexões entre as telas.
3. **Banco de dados e permissões:** Implemente o banco e defina os níveis de acesso de cada tipo de usuário.

Essa ordem preserva coerência e permite que você valide cada etapa antes de avançar.

### Corrigindo e Refinando

Se o resultado não for o que você esperava, **não refaça tudo do zero**. Siga este fluxo:

* Use o **Bug Scanner** (ícone de lupa na barra da pré-visualização) para identificar falhas específicas.
* Entre no **Modo Chat** para planejar a correção **antes de executar** — o Chat custa 3 créditos e não altera código, ideal para refinar.
* Seja **cirúrgico** nos pedidos de correção: *"corrija apenas o erro X na página Y, sem alterar o restante"*.

Essa abordagem cirúrgica evita que a IA introduza novos bugs em partes do app que já estavam prontas.

### Exemplo completo de um bom prompt

> 💬 *"Crie um sistema de gerenciamento para escolas. Tenha funcionalidade de cadastrar alunos e professores, com campos de nome, e-mail, turma e data de nascimento. Inspire-se em interfaces minimalistas como o Linear. Deve ter três tipos de acesso: professores (veem suas próprias turmas), alunos (veem apenas suas notas) e admin (acesso total). Não deve ter nenhum outro tipo de acesso."*

Veja como o prompt contém **Objetivo + Especificações + Restrições** em um único parágrafo enxuto.

{% hint style="success" %}
**Agora que você sabe escrever bons prompts**, conheça os diferentes [**Modos do Chat no Skip**](/skip/comece-aqui/entendendo-os-modos-do-skip-agent-build-e-chat.md) para decidir quando usar Build, Chat, Agent ou Upload em cada situação.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.adapta.org/skip/comece-aqui/guia-de-engenharia-de-prompt-para-skip.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
