Master Prompts

Usar como premissa ao iniciar qualquer sistema novo.

Quero criar um sistema X que faça Y… Importante: Como premissa desse projeto: Nada, absolutamente nada deve ser hard coded. Por menor que seja o ajuste, todos eles, devem contar em alguma página, no frontend, para que seja amplamente configurável e personalizável. Nada pode ser hardcoded dentro do nosso codigo. Todos os parâmetros, configuráveis, por tanto. Crie uma pagina dentro das configurações e, sempre que precisar preencher seus códigos com uma constante ou variável, deixe a lacuna configurável, editável e personalizável, atrelando-a a um campo configurável lá deste menu criado.

Sempre durante longas sessões de inputs.

Verifique que NADA, do nosso código do nosso projeto inteiro, que, deveria ser personalizável e editável, no front end, esta hardcoded por detrás dos panos. Se encontrar valor hardcoded, voce deve apontar aqui, quais são para tratarmos juntos, como criar botões/sessões/menus/campos personalizáveis para estes. Nosso código deve ser limpo e 100% personalizado.

Criar página de configuração de variáveis.

Quero que vc crie uma página, e que essa pagina não seja divulgada, chamada: /variables. Nela teremos como editar todas as variáveis hardcodeds e configura-las como deve-se ser. Elenque-as por categorias, de forma que faça sentido.

Use para forçar execução cronológica e iterativa em tarefas complexas.

Ataque em ordem cronológica, uma etapa por vez, seguindo o looping básico de implementação: Planejamento > Execução > Revisão > Teste

Framework completo de desenvolvimento. Usar no início de projetos grandes.

1. RESEARCH: primeiro eu rodo pesquisa pra entender o que eu vou criar de fato, seja de mercado, seja de tech.
2. PRD: research vira um doc de negócio, com explicação dos casos de uso e motivação. Aqui, já entra o que preciso medir
3. TECHSPEC: com prd na mão, e contexto atual do sistema, mapeio todos os pontos de contato que a tarefa vai ter, arquivos, funções etc
(as vezes tem uma etapa de research tecnico, pra entender melhores praticas e etc)
4. EXEC: aqui quebro a techspec em tarefas completas e executo uma a uma
5. QUALITY GATE: rodo em cima do que foi criado, pra saber se nao desviou do plano
6. TRACKING: focado apenas em tracking, saber o que o usuário fez no sistema (se for relevante, pro fluxo de analise de uso/conversão)
7. REVIEW: code review pra garantir que seguiu todas as diretrizes tecnicas (code paterns, arquitetura)
8. SEC: aqui eu busco por vulnerabilidades. Se acha alguma, pode ser que tenha que voltar pro passo 4.

Para projetos que precisam de specs formais antes do código.

Metodologia de implementação SDD: Framework de meta-prompting, context engineering e spec-driven development (SDD).
Detalhes da metodologia Spec-Driven Development (SDD): Especificações viram artefatos executáveis de primeira classe; você escreve a spec primeiro (PROJECT.md, ROADMAP.md etc.), e a IA gera código que respeita esse contrato como fonte da verdade.

Para auditoria completa de interface e experiência.

Utilizando a sua skill de front-end: realize uma auditoria relatorial completa em UI, UX, funcionalidades e engajamento da nossa plataforma. Quais os pontos de otimização e melhoria? Quais os gargalos encontrados? Quais elementos devemos retirar?

Para auditoria completa de backend e arquitetura.

Utilizando a sua skill de back-end: realize uma auditoria relatorial completa quanto a Componentes e funcionalidades do nosso sistema. Engenharia e arquitetura do sistema está adequada ou cabe otimização? Como otimizar, melhorar e consertar o que é necessário?

Para auditoria de segurança pré-lançamento.

Utilizando o seu skill de security: realize uma auditoria relatorial completa de segurança da nossa plataforma. Seu objetivo é preparar o software para receber diversos usuários, pós-lançamento e garantir escalabilidade com segurança total. Quais os pontos de otimização e melhoria? Quais os gargalos encontrados? Quais elementos devemos retirar?

Para auditoria técnica completa de sistemas SaaS.

Você é um engenheiro de software sênior especializado em segurança, performance e arquitetura de sistemas SaaS. Sua tarefa é auditar um sistema existente e produzir um relatório técnico detalhado.

ANÁLISE REQUERIDA:
1. SEGURANÇA - RLS, chaves expostas, autenticação, sanitização
2. PERFORMANCE - Índices, N+1, JSON vs relacional, paginação
3. ARQUITETURA - Lógica no frontend, tratamento de erros, transações
4. ESCALABILIDADE - Rate limiting, uploads, cache, multi-tenancy

FORMATO: Sumário executivo + problemas com severidade (🔴🟠🟡🟢) + tabela de prioridades + recomendações estruturais.

REGRAS: Seja específico, cite arquivos reais, não reporte falsos positivos, não sugira reescrever do zero.

Para blindar servidores antes de produção.

PRD: Security Hardening - Checklist completo:
1. Telegram Allowlist (CRÍTICO)
2. Firewall (UFW)
3. Fail2ban (proteção SSH)
4. Cloudflare Tunnel (acesso remoto seguro)
5. Portas de aplicação (127.0.0.1)
6. SSH Hardening
7. Credenciais: Auditar e Corrigir (.env)
8. Sync systemd + .env

Checklist: dmPolicy allowlist, UFW ativo, Fail2ban ativo, Cloudflare Tunnel, SSH key-only, zero hardcode, rotação trimestral.

Para implementar autenticação com OAuth e painel admin.

Crie um sistema de signup e login de usuários que tenha por base Google oauth ou Apple Oauth e deixe login/senha ocultos. Configure lucio.amorim@gmail.com diretamente no banco como primeiro usuário e admin do sistema, e inclua uma rota /admin onde o admin visualize logs de tentativas de login, resets de senha, e demais atividades dos usuários da aplicação. Por fim, inclua toggles de [on/off] para 1) permissão de criação de novos usuários e 2) modo de manutenção, que avise em todas as telas da aplicação.

Para documentar evolução e backlog do projeto.

Documente toda a evolução desse projeto desde o prompt inicial e gere um arquivo de roadmap em markdown na raiz do projeto, que contenha de maneira hierárquica e em ordem decrescente de implementação, tudo o que já foi executado, o que falta executar e o que ficou no backlog. Utilize emojis coloridos para facilitar a sinalização e discrimine funcionalidades e subtarefas, de forma que eu tenha uma visão completa de tudo o que está planejado e tudo o que já aconteceu com essa aplicação.

Para criar changelog formal do projeto.

Construa um changelog dessa aplicação, implementando versionamentos major e minor de acordo com a metodologia Keep a Changelog. Discrimine em uma linha cada modificação de maneira individual, incluindo justificativa ou expectativa de cada movimento e de cada alteração de versão.

Para documentação técnica completa do projeto.

Construa um PRD a partir de uma análise aprofundada dessa aplicação, incluindo conceitos centrais de utilização, critérios de sucesso, escolhas de stack tecnológico, justificativas de priorização e todas as outras informações que sejam necessárias para documentar tecnicamente o projeto no estado atual.

Para mapear visualmente a estrutura da página.

Gere um resumo esquemático da página atual, da aplicação atual, em wireframe, incluindo todas as seções, hierarquias, elementos interativos, textos, botões e tudo que impacta no layout e na experiência do usuário final.

Para mapear fluxos e conexões do sistema.

Gere um diagrama Mermaid que documente todas as interações, conexões e fluxos de usuário dessa aplicação, incluir assimetrias, dissonâncias, fragilidades de conexão e pontos de contato com implementação incompleta.

Para clonar sites usando ai-website-cloner-template.

Fluxo para clonar sites:
1. Copie o template para nova pasta e npm install
2. Abra Claude Code com --chrome (obrigatório para screenshots)
3. Execute: /clone-website https://site-alvo.com
4. Pipeline automático: screenshots, extração de cores/fontes, download de assets, specs, build paralelo, merge e QA
5. npm run dev para ver resultado
6. Customize depois - clone sai 1:1

Sempre durante longas sessões de inputs.

Encontre arquivos que não são utilizadas pelo nosso sistema, CODE ORPHANED, no sistema como um todo. Ao encontrá-los, elimine-os só, e SOMENTE SÓ se, tiver certeza que aquele arquivo não é utilizada para nada e que se trata de "lixo" - Se ficar alguma dúvida, aponte o caminho do arquivo para mim, aqui no chat, que verifico e agimos.

Use após enviar um prompt complexo para garantir que tudo foi implementado sem lacunas.

Certifique que o ultimo prompt foi assimilado, em sua totalidade por você e que, a implementação irrestrita, de todo o arcabouço necessário, foi, exaustivamente feita sem deixar qualquer lacuna.

Para revisão completa do codebase com geração de QUESTIONS.md.

Você atuará como revisor de código profissional e líder técnico de toda a base de código. Revise toda a estrutura do código do meu projeto, cada arquivo, cada página (se houver), cada endpoint (se houver), cada lógica e escreva um arquivo QUESTIONS.md com todas as perguntas arquiteturais, de refatoração e técnicas que você achou estranhas ou sobre as quais precisa de mais informações.
A ideia aqui é que você compreenda e entenda do que se trata este projeto, o que ele faz e o que lhe falta em termos de desempenho, arquitetura e segurança. Quaisquer falhas, problemas, bugs ou sugestões de melhoria devem ser relatados no arquivo QUESTIONS.md como perguntas independentes, para que eu possa respondê-las neste arquivo, explicando o que deve ser feito e como, e o que é um bug e o que é o comportamento esperado.
Este arquivo pode ficar bem grande (com muitas perguntas), então não tenha receio nem preguiça, escreva todas as perguntas ou pontos que você achar importantes!
Assim que você escrever o arquivo, eu responderei às perguntas do QUESTIONS.md e farei novas perguntas para que você possa começar a implementar melhorias no código-fonte com base nas suas próprias perguntas respondidas por mim no QUESTIONS.md. Ultrathink about this!

Sempre depois de um prompt longo, para certificar-se da total implementação.

Certifique que o ultimo prompt foi assimilado, em sua totalidade por você e que, a implementação irrestrita, de todo o arcabouço necessário, foi, exaustivamente feita sem deixar qualquer lacuna.

Para medir o avanço do projeto após execuções.

Qual progresso atual, numa escala entre 0 a 100% que nos encontramos, após a última execução feita por você? 0% = Nenhum progresso, ou seja, tudo está igual era antes e, 100% Não há mais melhorias, otimizações ou alterações a serem feitas pois, todas já foram implementadas e são plenamente funcionais.

Inserir como primeira seção do system prompt em qualquer agente que produza conteúdo factual.

## REGRA ZERO — FIDELIDADE SOBRE PERFORMANCE (NÃO NEGOCIÁVEL)

Você prefere uma resposta fraca e verdadeira a uma resposta forte e inventada.

NUNCA adicione:
- Números, porcentagens ou métricas que não estejam explicitamente na fonte
- Nomes de modelos, versões, produtos ou empresas não mencionados na entrada
- Comparações (X vs Y), rankings ou benchmarks que você não pode rastrear à fonte
- Previsões ou afirmações com prazo ("em 6 meses", "80% dos casos") sem citação

QUANDO NÃO SOUBER OU A FONTE FOR INSUFICIENTE:
- Diga explicitamente: "a fonte não menciona esse dado"
- Retorne null/skip/insufficient_data em vez de preencher com suposições
- Uma resposta curta e honesta vale mais do que uma resposta longa e inventada

EXEMPLOS DE COMPORTAMENTO CORRETO:
- Fonte diz "OpenAI lançou novo modelo" → você escreve "OpenAI lançou novo modelo" (sem adicionar versão)
- Fonte não menciona performance → você não adiciona "processa X tokens/s"
- Comentário vago sem dados → você faz uma pergunta em vez de inventar um insight

OS EXEMPLOS NO PROMPT SÃO DE ESTILO, NÃO DE CONTEÚDO:
- Nunca use os números dos exemplos como se fossem fatos reais
- Adapte a ESTRUTURA, não copie os DADOS

HIERARQUIA:
1. Fatos explícitos na fonte → use sempre
2. Inferência lógica direta da fonte → use com "isso sugere que..."
3. Conhecimento geral do domínio → use com "tipicamente..." ou "em geral..."
4. Dado ausente → declare ausência, não invente

---
Onde inserir: sempre como primeira seção do system prompt, antes de qualquer instrução de estilo, tom ou formato. O modelo lê em ordem — se a regra de fidelidade vier depois da regra de "seja específico", perde a briga.

Regra fundamental: nenhum botão decorativo.

Todos, repito: TODOS os botoes, configurações, ativações e relacionados que forem configurados na dashboard DEVEM FUNCIONAR de verdade. Toda alteracao feita na dashboard deve persistir no banco, sempre. Ampla e irrestritamente. Voce NUNCA pode criar botoes de "enfeite"

Regra para evitar planos excessivamente longos.

Nunca trace planos ou emita planejamentos longo demais. Acostume-se a fasear estes conteúdos para garantirmos que a aplicação destes, sera ampla e irrestrita sem penalidade por overcontent