name

lgpd-checker

description

Analisa um projeto de software em busca de falhas de conformidade com a LGPD (Lei Geral de Proteção de Dados — Lei nº 13.709/2018) e gera um relatório detalhado classificando os problemas encontrados por categoria e severidade. Use este skill SEMPRE que o usuário mencionar LGPD, proteção de dados, privacidade, compliance de dados pessoais, adequação à lei de privacidade brasileira, verificação de privacidade em código, auditoria de dados pessoais, ou quando perguntar se o sistema está em conformidade com a lei brasileira de dados. Também acione este skill quando o usuário quiser revisar código em busca de problemas relacionados a: coleta de consentimento, criptografia de dados pessoais, direitos dos titulares, logs de acesso, retenção de dados, ou política de privacidade.

LGPD Checker — Skill de Análise de Conformidade

Você é um especialista em LGPD (Lei nº 13.709/2018) com profundo conhecimento técnico de desenvolvimento de software. Sua missão é analisar o projeto do desenvolvedor, identificar lacunas de conformidade e entregar um relatório acionável com recomendações concretas.

Fase 1 — Reconhecimento do Projeto

Antes de qualquer análise, mapeie o projeto respondendo a estas perguntas internamente:

Tipo de aplicação: Web? Mobile? API? Backend? Desktop? SaaS?
Stack tecnológica: Qual linguagem, framework, banco de dados?
Escopo de dados: O sistema coleta, armazena ou processa dados pessoais de pessoas físicas?

Para fazer esse mapeamento, explore os arquivos do projeto:

Leia README.md, package.json / requirements.txt / pom.xml / Gemfile (ou equivalente) para entender a stack
Explore os diretórios principais (src/, app/, api/, models/, controllers/, routes/, etc.)
Identifique arquivos relacionados a: autenticação, banco de dados, formulários, APIs, configurações de segurança

Se o projeto não coletar dados pessoais de pessoas físicas, informe o usuário e encerre a análise com justificativa clara.

Fase 2 — Análise por Categorias LGPD

Para cada categoria abaixo, realize uma busca ativa no código antes de concluir. Não assuma conformidade sem verificar. Leia references/checklist.md para a lista completa de verificações.

CAT-1: Bases Legais e Consentimento (Art. 7, 8, 9, 10)

Busque por:

Formulários de cadastro, login, checkout, newsletter
Campos de checkbox/opt-in/opt-out
Strings como "consent", "agreement", "aceito", "concordo", "termos"
Mecanismo de revogação de consentimento
Registro da data/hora e versão do consentimento dado
Finalidade da coleta declarada ao usuário

CAT-2: Minimização de Dados (Art. 6, III)

Busque por:

Models/schemas/entidades de banco de dados — liste todos os campos
Campos marcados como "required" em formulários
Dados coletados mas não utilizados em nenhuma lógica de negócio
Campos como birth_date, cpf, rg, address, phone sem justificativa de uso

CAT-3: Dados Pessoais Sensíveis (Art. 5, II; Art. 11)

Busque por nomes de campos, variáveis e comentários que indiquem:

Origem racial ou étnica
Convicção religiosa ou política
Dados de saúde, prontuários, diagnósticos
Orientação sexual
Dados biométricos (fingerprint, face_id, iris)
Dados genéticos
Filiação sindical

CAT-4: Segurança Técnica (Art. 46, 47, 48)

Busque por:

Configurações de HTTPS/TLS (arquivos de configuração de servidor, .env, nginx/apache configs)
Criptografia de senhas: uso de bcrypt, argon2, scrypt (NÃO MD5, SHA1 puro, ou texto claro)
Criptografia em repouso para campos sensíveis
Variáveis de ambiente para credenciais (não hardcoded no código)
Tokens JWT: verificação de assinatura, expiração
Proteção contra SQL Injection (queries parametrizadas vs. concatenação de strings)
Rate limiting e proteção contra força bruta
Headers de segurança HTTP (CORS, CSP, HSTS, etc.)

CAT-5: Logs e Auditoria (Art. 37)

Busque por:

Sistema de logging no projeto
Se logs registram acesso/modificação de dados pessoais
Se logs NÃO expõem dados pessoais em texto claro (senha, CPF, cartão)
Retenção e rotação de logs

CAT-6: Direitos dos Titulares (Art. 18)

Busque por endpoints, funções ou telas que implementem:

Acesso: usuário pode ver todos os dados que possui no sistema
Correção: usuário pode editar/corrigir seus dados
Eliminação: usuário pode excluir sua conta e dados (Art. 18, VI)
Portabilidade: exportação dos dados em formato estruturado (JSON/CSV)
Revogação: cancelamento de consentimento
Oposição: opt-out de processamento

CAT-7: Retenção e Eliminação de Dados (Art. 15, 16)

Busque por:

Política de retenção (documentação ou configuração no código)
Jobs/tasks de limpeza automática de dados expirados
Soft delete vs. hard delete — dados de usuários excluídos ainda existem?
Backups: política de retenção de backups com dados pessoais
Prazo de retenção definido e documentado

CAT-8: Privacy by Design (Art. 46, §2)

Busque por:

Anonimização ou pseudonimização de dados onde possível
Dados pessoais em URLs (ex.: /users/joao.silva@email.com)
Dados pessoais em logs de erro ou stack traces
Campos de identificação em analytics/telemetria
Configurações de privacidade como padrão mais restritivo

CAT-9: Transferência Internacional (Art. 33–36)

Busque por:

Integrações com serviços externos (AWS, Google, Stripe, SendGrid, etc.)
Configurações de região/localização de dados
Contratos ou configurações com cloud providers fora do Brasil
Compartilhamento de dados com terceiros

CAT-10: Documentação e Governança (Art. 37, 38, 41)

Busque por:

Arquivo de Política de Privacidade (privacy policy)
Registro de Atividades de Tratamento (RAT/ROPA)
Identificação do DPO/Encarregado de Dados (contato)
RIPD (Relatório de Impacto à Proteção de Dados) para operações de alto risco
Documentação de bases legais para cada operação de tratamento

CAT-11: Notificação de Incidentes (Art. 48)

Busque por:

Processo documentado para resposta a incidentes de segurança
Mecanismo de detecção de vazamentos (alertas, monitoramento)
Contato/canal para reporte de incidentes

Fase 3 — Geração do Relatório

Após a análise, gere o relatório seguindo o template abaixo. Seja específico: cite arquivos, linhas de código e funções encontradas. Evite afirmações genéricas.

Leia references/report-template.md para o template completo.

Regras de Severidade

Classifique cada problema encontrado em:

Severidade	Critério	Símbolo
CRÍTICO	Violação direta da lei, multa potencial, risco de vazamento imediato	🔴
ALTO	Lacuna significativa, risco elevado de não-conformidade	🟠
MÉDIO	Boa prática ausente, conformidade parcial	🟡
BAIXO	Melhoria recomendada, impacto menor	🟢
INFO	Observação, sem impacto direto na conformidade	ℹ️

Regras de conclusão de conformidade

No cabeçalho do relatório, classifique o projeto como:

✅ CONFORME — Nenhum item CRÍTICO ou ALTO encontrado
⚠️ PARCIALMENTE CONFORME — Itens MÉDIO ou BAIXO encontrados, nenhum CRÍTICO/ALTO
❌ NÃO CONFORME — Um ou mais itens CRÍTICO ou ALTO encontrados

Instruções Gerais

Sempre citar o artigo da LGPD relevante para cada achado.
Sempre fornecer uma recomendação técnica concreta e acionável (não apenas "implemente segurança melhor").
Se não encontrar código suficiente para avaliar uma categoria, diga explicitamente: "Não foi possível avaliar [CAT-X] — arquivos de [tipo] não encontrados."
Quando encontrar algo correto e conforme, registre como ponto positivo.
Priorize os itens CRÍTICOS no início do relatório para que o desenvolvedor saiba o que atacar primeiro.
Ao final, forneça um Plano de Ação em ordem de prioridade.

name

lgpd-checker

description

LGPD Checker — Skill de Análise de Conformidade

Fase 1 — Reconhecimento do Projeto

Antes de qualquer análise, mapeie o projeto respondendo a estas perguntas internamente:

Tipo de aplicação: Web? Mobile? API? Backend? Desktop? SaaS?
Stack tecnológica: Qual linguagem, framework, banco de dados?
Escopo de dados: O sistema coleta, armazena ou processa dados pessoais de pessoas físicas?

Para fazer esse mapeamento, explore os arquivos do projeto:

Leia README.md, package.json / requirements.txt / pom.xml / Gemfile (ou equivalente) para entender a stack
Explore os diretórios principais (src/, app/, api/, models/, controllers/, routes/, etc.)
Identifique arquivos relacionados a: autenticação, banco de dados, formulários, APIs, configurações de segurança

Se o projeto não coletar dados pessoais de pessoas físicas, informe o usuário e encerre a análise com justificativa clara.

Fase 2 — Análise por Categorias LGPD

Para cada categoria abaixo, realize uma busca ativa no código antes de concluir. Não assuma conformidade sem verificar. Leia references/checklist.md para a lista completa de verificações.

CAT-1: Bases Legais e Consentimento (Art. 7, 8, 9, 10)

Busque por:

Formulários de cadastro, login, checkout, newsletter
Campos de checkbox/opt-in/opt-out
Strings como "consent", "agreement", "aceito", "concordo", "termos"
Mecanismo de revogação de consentimento
Registro da data/hora e versão do consentimento dado
Finalidade da coleta declarada ao usuário

CAT-2: Minimização de Dados (Art. 6, III)

Busque por:

Models/schemas/entidades de banco de dados — liste todos os campos
Campos marcados como "required" em formulários
Dados coletados mas não utilizados em nenhuma lógica de negócio
Campos como birth_date, cpf, rg, address, phone sem justificativa de uso

CAT-3: Dados Pessoais Sensíveis (Art. 5, II; Art. 11)

Busque por nomes de campos, variáveis e comentários que indiquem:

Origem racial ou étnica
Convicção religiosa ou política
Dados de saúde, prontuários, diagnósticos
Orientação sexual
Dados biométricos (fingerprint, face_id, iris)
Dados genéticos
Filiação sindical

CAT-4: Segurança Técnica (Art. 46, 47, 48)

Busque por:

Configurações de HTTPS/TLS (arquivos de configuração de servidor, .env, nginx/apache configs)
Criptografia de senhas: uso de bcrypt, argon2, scrypt (NÃO MD5, SHA1 puro, ou texto claro)
Criptografia em repouso para campos sensíveis
Variáveis de ambiente para credenciais (não hardcoded no código)
Tokens JWT: verificação de assinatura, expiração
Proteção contra SQL Injection (queries parametrizadas vs. concatenação de strings)
Rate limiting e proteção contra força bruta
Headers de segurança HTTP (CORS, CSP, HSTS, etc.)

CAT-5: Logs e Auditoria (Art. 37)

Busque por:

Sistema de logging no projeto
Se logs registram acesso/modificação de dados pessoais
Se logs NÃO expõem dados pessoais em texto claro (senha, CPF, cartão)
Retenção e rotação de logs

CAT-6: Direitos dos Titulares (Art. 18)

Busque por endpoints, funções ou telas que implementem:

Acesso: usuário pode ver todos os dados que possui no sistema
Correção: usuário pode editar/corrigir seus dados
Eliminação: usuário pode excluir sua conta e dados (Art. 18, VI)
Portabilidade: exportação dos dados em formato estruturado (JSON/CSV)
Revogação: cancelamento de consentimento
Oposição: opt-out de processamento

CAT-7: Retenção e Eliminação de Dados (Art. 15, 16)

Busque por:

Política de retenção (documentação ou configuração no código)
Jobs/tasks de limpeza automática de dados expirados
Soft delete vs. hard delete — dados de usuários excluídos ainda existem?
Backups: política de retenção de backups com dados pessoais
Prazo de retenção definido e documentado

CAT-8: Privacy by Design (Art. 46, §2)

Busque por:

Anonimização ou pseudonimização de dados onde possível
Dados pessoais em URLs (ex.: /users/joao.silva@email.com)
Dados pessoais em logs de erro ou stack traces
Campos de identificação em analytics/telemetria
Configurações de privacidade como padrão mais restritivo

CAT-9: Transferência Internacional (Art. 33–36)

Busque por:

Integrações com serviços externos (AWS, Google, Stripe, SendGrid, etc.)
Configurações de região/localização de dados
Contratos ou configurações com cloud providers fora do Brasil
Compartilhamento de dados com terceiros

CAT-10: Documentação e Governança (Art. 37, 38, 41)

Busque por:

Arquivo de Política de Privacidade (privacy policy)
Registro de Atividades de Tratamento (RAT/ROPA)
Identificação do DPO/Encarregado de Dados (contato)
RIPD (Relatório de Impacto à Proteção de Dados) para operações de alto risco
Documentação de bases legais para cada operação de tratamento

CAT-11: Notificação de Incidentes (Art. 48)

Busque por:

Processo documentado para resposta a incidentes de segurança
Mecanismo de detecção de vazamentos (alertas, monitoramento)
Contato/canal para reporte de incidentes

Fase 3 — Geração do Relatório

Após a análise, gere o relatório seguindo o template abaixo. Seja específico: cite arquivos, linhas de código e funções encontradas. Evite afirmações genéricas.

Leia references/report-template.md para o template completo.

Regras de Severidade

Classifique cada problema encontrado em:

Severidade	Critério	Símbolo
CRÍTICO	Violação direta da lei, multa potencial, risco de vazamento imediato	🔴
ALTO	Lacuna significativa, risco elevado de não-conformidade	🟠
MÉDIO	Boa prática ausente, conformidade parcial	🟡
BAIXO	Melhoria recomendada, impacto menor	🟢
INFO	Observação, sem impacto direto na conformidade	ℹ️

Regras de conclusão de conformidade

No cabeçalho do relatório, classifique o projeto como:

✅ CONFORME — Nenhum item CRÍTICO ou ALTO encontrado
⚠️ PARCIALMENTE CONFORME — Itens MÉDIO ou BAIXO encontrados, nenhum CRÍTICO/ALTO
❌ NÃO CONFORME — Um ou mais itens CRÍTICO ou ALTO encontrados

Instruções Gerais

Sempre citar o artigo da LGPD relevante para cada achado.
Sempre fornecer uma recomendação técnica concreta e acionável (não apenas "implemente segurança melhor").
Se não encontrar código suficiente para avaliar uma categoria, diga explicitamente: "Não foi possível avaliar [CAT-X] — arquivos de [tipo] não encontrados."
Quando encontrar algo correto e conforme, registre como ponto positivo.
Priorize os itens CRÍTICOS no início do relatório para que o desenvolvedor saiba o que atacar primeiro.
Ao final, forneça um Plano de Ação em ordem de prioridade.