Prompts

Gerador de Documentação para Design System

Este prompt otimizado ajuda a automatizar a criação da documentação escrita de componentes do seu Design System no GitBook. Ele estrutura as informações de forma clara, cobrindo Descrição, Uso, Anatomia e Variantes. Se algo faltar, o prompt é inteligente e pergunta exatamente o que precisa, garantindo uma documentação completa e consistente para designers e desenvolvedores.

Abaixo estao os dados estruturados de um componente do Design System. Com base nos dados de input, gere os textos da documentacao dos blocos de output.

---

Inputs:

Nome do componente:
[ex: Botao Primario]

Explicacao geral sobre o componente:
[ex: Componente usado para acionar acoes em uma interface]

Anatomias (comum a todas as variantes):
[Descrever os elementos anatomicos e o que cada um faz. Preencha apenas se a anatomia for a mesma para todas as variantes.]

Variantes:

  Nome da Variante:
  [ex: Fill, Tonal, Outlined]
  
  Explicacao da Variante:
  [ex: Os Fill Buttons tem o maior impacto visual e devem ser usados para acoes importantes e finais.]
  
  Anatomia da Variante (se for especifica):
  [Descrever os elementos anatomicos e o que cada um faz, se diferentes da anatomia comum.]

Conteudo Existente (Opcional):

  Texto atual da Descricao:
  [Cole o texto da Descricao ja existente no Gitbook, se houver.]
  
  Texto atual do Uso:
  [Cole o texto do Uso ja existente no Gitbook, se houver.]
  
  Texto atual da Anatomia:
  [Cole o texto da Anatomia ja existente no Gitbook, se houver.]
  
  Texto atual das Variantes:
  [Cole o texto das Variantes ja existente no Gitbook, se houver.]
  
  Texto atual de Comportamento:
  [Cole o texto de Comportamento ja existente no Gitbook, se houver.]
  
  Texto atual de Posicionamento:
  [Cole o texto de Posicionamento ja existente no Gitbook, se houver.]
  
  Texto atual de Layout Responsivo:
  [Cole o texto de Layout Responsivo ja existente no Gitbook, se houver.]

---

Output:

Gere os textos estruturados a seguir, seguindo estas regras de cada bloco. O conteudo existente fornecido nos Inputs deve servir como **referencia e base**, mas o output final deve priorizar a **otimizacao e adaptacao** com base nos novos inputs e nas boas praticas de Design Systems similares (Material Design principalmente), mesmo que isso signifique reescrever ou complementar o texto existente. Me entregar dentro de um code snippet.

Descricao:
Texto conciso (1 frase) explicando de forma simples e clara o que o componente faz. Foque na funcao principal e proposito. Se um "Texto atual da Descricao" foi fornecido nos Inputs, use-o como referencia para gerar um output que siga estas regras, usando o Material Design para reforcar o conteudo.

Uso:
Explique quando e por que o componente deve ser usado. Se um "Texto atual do Uso" foi fornecido nos Inputs, use-o como referencia para gerar um output que siga estas regras, usando o Material Design para reforcar o conteudo.

Anatomia:
Se o campo "Anatomias (comum a todas as variantes)" foi preenchido, liste cada elemento com:
- Titulo: Index + Nome do elemento
- Que informacoes esse elemento do componente recebe
- Se e obrigatorio receber alguma informacao (Em casos de texto ou imagem).
- Como ele deve se comportar em diferentes casos de uso.
Use estrutura numerada. Para elementos nao numeraveis, como containers, use ❖.
Se o campo "Anatomias (comum a todas as variantes)" nao for preenchido, esta secao nao sera gerada. Se um "Texto atual da Anatomia" foi fornecido nos Inputs, use-o como referencia para gerar um output que siga estas regras.

Variantes:
Para cada variante, crie uma breve frase que explique sua funcao e quando usa-la, destacando o nivel de enfase visual e incluindo regras visuais ou comportamentais se fornecidas.
Se houver anatomia especifica, liste os pontos como na secao Anatomia. Se um "Texto atual das Variantes" foi fornecido nos Inputs, use-o como referencia para gerar um output que siga estas regras.

Obs.: Os blocos abaixo nao sao obrigatorios e devem ser gerados apenas se houver conteudo claro e consistente para eles. Caso considere aplicavel, me pergunte antes se devem ser criados, explicando o porque que eles devem existir.

Comportamento:
Descreve interacoes especificas, efeitos visuais, animacoes, destaque de conteudo, mudancas de estado ou acoes relacionadas ao contexto de uso. Siga como referencia a secao “Behavior” da documentacao do Material Design. Se um "Texto atual de Comportamento" foi fornecido nos Inputs, use-o como referencia para gerar um output que siga estas regras.

Posicionamento:
Quando houver informacoes claras sobre onde o componente deve ser posicionado na tela ou dentro de um layout. Se um "Texto atual de Posicionamento" foi fornecido nos Inputs, use-o como referencia para gerar um output que siga estas regras.

Layout Responsivo:
Quando houver dados sobre como o componente se adapta a diferentes tamanhos de tela, tamanhos de texto ou restricoes de container. Se um "Texto atual de Layout Responsivo" foi fornecido nos Inputs, use-o como referencia para gerar um output que siga estas regras.

---

Processamento e Validacao:

1. Verificacao semantica ativa com base em Design Systems de mercado:
Antes de gerar o output, compare o nome e a explicacao do componente com padroes conhecidos de outros sistemas. Se houver semelhanca direta com um componente padrao, utilize esse conhecimento para refinar e enriquecer os textos gerados. Se houver divergencia entre o nome do componente e o padrao de mercado, pergunte ao usuario: “O nome 'X' esta correto? Esse comportamento e comumente atribuido ao componente 'Y' em outros Design Systems. Deseja ajustar o nome ou manter como esta?” Se houver conflito semantico ou ambiguidade critica, nao gere o output ate que o usuario confirme ou corrija o nome e a descricao.

2. Validacao final contextual:
Ao concluir o processamento, revise os dados fornecidos e os blocos gerados. Para qualquer secao onde houver lacunas, inconsistencias ou informacoes insuficientes, gere perguntas pontuais ao usuario para esclarecer os pontos necessarios. Se qualquer bloco do output estiver com dados incompletos, nao o gere ate que as perguntas relacionadas tenham sido respondidas. Evite perguntas genericas. Foque em duvidas especificas que bloqueiem a construcao do conteudo final. Seu objetivo e garantir que a documentacao final esteja clara, precisa e aplicavel em contexto real de uso por designers e desenvolvedores.

---

Regras gerais:
- Respeite os titulos dos blocos nos outputs.
- Nao invente informacoes fora da estrutura esperada.
- Use inferencia apenas se for logica e segura, com base em padroes conhecidos.
- Linguagem clara, tecnica e acessivel, voltada para uso interno por designers e desenvolvedores.
- Gere apenas os blocos para os quais ha informacoes completas nos Inputs.