mental

O que mental faz?

Explique o sistema por meio de seus atores, limites e comunicação.

Contrato de saída: diagrama primeiro

Uma explicação mental completa DEVE incluir um diagrama na própria resposta. Escreva uma frase curta para orientar o leitor e, em seguida, inclua imediatamente:

• Um bloco mermaid com cercadura usando sequenceDiagram e autonumber (o padrão).
• Uma imagem D2 renderizada incorporada, se a renderização estiver disponível e D2 for solicitado.

Em seguida, explique o fluxo e sua evolução em prosa concisa. Construa o diagrama antes de escrever a explicação mais longa, para que o visual não possa ser descartado no final. Este contrato também se aplica a respostas curtas e explicações complementares que dêem continuidade a uma discussão de modelo mental invocada explicitamente. Uma pergunta de esclarecimento isolada não precisa de diagrama. Se o usuário solicitar explicitamente nenhum diagrama, atenda a essa solicitação.

Setas ASCII, listas com marcadores, tabelas, blocos de código comuns, um link para um diagrama, uma promessa de desenhar um depois e código-fonte D2 não renderizado não satisfazem este contrato. Não pergunte se o usuário quer um diagrama. Se nenhum renderizador estiver disponível, emita mesmo assim o código-fonte Mermaid; não o substitua por texto porque o chat pode não renderizá-lo. Nenhuma ferramenta de geração de diagrama é necessária para um bloco de código Mermaid.

Exemplo da forma de resposta exigida (adapte os atores ao contexto real):

O navegador pede à API para salvar dados; a API possui o acesso ao banco de dados.

```mermaid
sequenceDiagram
    autonumber
    participant Navegador
    participant API
    participant BancoDeDados
    Navegador->>API: Salvar dados do formulário
    API->>BancoDeDados: Armazenar dados aceitos
    BancoDeDados-->>API: Registro salvo
    API-->>Navegador: Resposta de sucesso
```

O formulário começa no navegador. Adicionar uma API permite salvar remotamente; adicionar um
banco de dados permite que os dados salvos sobrevivam a uma requisição individual.

Invocação explícita

Use esta skill apenas quando o usuário a solicitar explicitamente: /mental, $mental, ou um pedido direto para usar a habilidade mental. Um pedido genérico de explicação não ativa esta skill. Trate isso como uma solicitação de explicação, não como permissão para implementar, instalar, publicar ou alterar o sistema que está sendo explicado.

Use o tópico que segue a invocação, ou infira-o a partir da conversa. Faça uma pergunta focada apenas se o tópico não puder ser razoavelmente inferido.

Construa a explicação

1. Fundamente o modelo na conversa e nas evidências disponíveis. Para uma base de código existente, inspecione apenas os pontos de entrada ou a configuração necessária para estabelecer os relacionamentos relevantes. Distinga fatos observados de suposições. Não invente serviços, implantações bem-sucedidas ou comportamento verificado.
2. Comece com o menor sistema útil: um script executado localmente, um navegador exibindo uma página ou um serviço respondendo a uma requisição. Explique o que já funciona antes de introduzir a infraestrutura.
3. Progrida em direção ao sistema em discussão. Em cada estágio significativo, explique a nova necessidade, o ator ou conexão adicionado para satisfazê-la e como uma ação agora percorre o sistema. Estes são estágios explicativos, não alegações sobre cronologia histórica. Se o usuário perguntar sobre a evolução real do projeto, use o histórico disponível e identifique lacunas.
4. Escolha atores por contexto: pessoas, processos, serviços, armazenamento, registros, filas ou provedores externos. Atribua a cada um um papel concreto. Agrupe atores relacionados por máquina, processo ou limite de rede quando a localização afetar o entendimento.
5. Trace uma ação concreta através dos atores em ordem, incluindo o resultado retornando ao chamador. Rotule o que cruza cada limite: código-fonte, pacote de arquivos, requisição HTTP, resposta JSON, evento ou dado armazenado. Separe configuração e distribuição da comunicação em tempo de execução quando ambos forem importantes.
6. Explique as distinções apenas onde elas resolvem confusão. Por exemplo, um nome de pacote seleciona o que buscar, um nome de comando seleciona o que executar e um argumento se torna entrada para esse comando. Para um exemplo navegador/API, distinga entre entrega de código e requisições posteriores à API.

Prefira uma progressão curta com prosa conectada em vez de um glossário ou um catálogo de componentes. Se o usuário quiser apenas a interação atual, mostre esse fluxo sem forçar uma longa evolução. Comandos e trechos devem ancorar o modelo; evite inventários de flags, guias de implementação e alternativas não relacionadas. Retenha detalhes que alteram o modelo, como um cache que evita um download ou uma confirmação assíncrona que chega antes da conclusão do trabalho.

Precisão do diagrama

Cada resposta produzida com esta skill deve conter pelo menos um diagrama Mermaid ou uma imagem D2 renderizada. O padrão é um bloco mermaid com cercadura: ele não requer ferramentas de renderização e o código-fonte permanece legível quando a renderização não está disponível.

• Prefira um diagrama de sequência numerado: inicie diagramas Mermaid com sequenceDiagram seguido de autonumber. Torne a ordem das chamadas, mensagens e respostas visível. Introduza os participantes em uma ordem legível da esquerda para a direita.
• Numere tanto as respostas quanto as requisições para que o leitor possa acompanhar a interação completa. Trace as etapas numeradas na prosa; mantenha as referências consistentes com o diagrama. A numeração mostra o cenário ilustrado, não uma alegação de que o trabalho concorrente sempre ocorre em uma ordem fixa. Use par, alt ou opt quando concorrência, alternativas ou etapas opcionais alterarem o modelo.
• Para uma evolução, use sequências numeradas pequenas e separadas para estágios significativos; mantenha os nomes dos participantes estáveis e explique qual ator ou mensagem foi adicionado.
• Use um fluxograma apenas quando a topologia ou estrutura for a questão principal e uma sequência a obscureceria, ou quando o usuário solicitar um. Para imagens D2 que mostram uma interação, prefira um layout de sequência e numere explicitamente as mensagens.
• Use nomes de atores concretos e setas direcionais rotuladas com ações ou dados. Evite setas não rotuladas e caixas decorativas que não explicam nada.
• Mantenha cada diagrama focado na interação que está sendo explicada. Divida fases diferentes ou sistemas com muitos atores em diagramas pequenos. Em diagramas em estágios, marque quais atores e conexões são recém-introduzidos.
• Mantenha os rótulos simples e coloque entre aspas os rótulos de fluxograma que contêm pontuação. Verifique referências de nós, direção das setas, subgráficos e sintaxe de cercadura antes de enviar.
• Um registro de pacotes distribui código; não o desenhe como executando a CLI do usuário. Um banco de dados armazena dados; não o desenhe como iniciando requisições comuns de aplicação, a menos que isso seja uma característica real do sistema.
• Se o usuário preferir D2 e um renderizador estiver disponível, renderize e inspecione o resultado e, em seguida, incorpore a imagem. Apenas o código-fonte D2 não satisfaz o requisito de imagem. Se a renderização não estiver disponível, use Mermaid e informe a alternativa brevemente. Não instale um renderizador apenas para explicar o modelo.

Siga o diagrama com uma breve explicação da ação concreta. Termine quando o modelo estiver claro; não anexe tarefas de implementação ou resumos genéricos.

Antes de enviar

Inspecione a própria resposta: ela contém um bloco mermaid com cercadura ou uma imagem D2 renderizada incorporada? Se nenhum dos dois estiver presente, a explicação está incompleta. Adicione o diagrama antes de enviar. Para um diagrama de sequência Mermaid, verifique se autonumber está presente. Verifique se as setas correspondem à prosa e traçam pelo menos uma interação real com atores concretos e comunicação rotulada.

Exemplos

Leia referencias/exemplos.md quando exemplos ajudarem a calibrar a explicação. Inclui distribuição npm, chamadas frontend/backend, chamadas serviço a serviço e trabalhos assíncronos. Adapte a abordagem ao contexto real, em vez de importar esses atores para cada explicação.