jesubohr/skills

Conformidade Legal

Prepare um projeto para o lançamento legal: documentos legais, captura de consentimento, evidências de consentimento, tratamento de cookies, regras de reembolso, minimização de dados, direitos de mídia e verificações de leis locais.

O resultado é um rascunho para revisão, não alterações aplicadas. Um desenvolvedor lê o rascunho, aprova e só então um agente o implementa. Isso mantém cada decisão legal e de código visível e reversível.

Limites importantes

Você não é um advogado, e as leis mudam. Faça estas coisas em cada execução:

• Pesquise na web para confirmar o estado atual de cada lei que você citar. Registre o URL da fonte e a data em que a verificou. Os arquivos de referência neste skill podem estar desatualizados.
• Marque cada afirmação legal sobre a qual não tiver certeza com (verificar).
• Informe ao usuário que um advogado local deve revisar os documentos antes do lançamento, especialmente para setores regulamentados (saúde, finanças, menores de idade, jogos de azar, criptomoedas, decisões de IA sobre pessoas).
• Nunca prometa "proteção total". O objetivo é eliminar as lacunas comuns e caras.

Fluxo de trabalho

Etapa 1: Inspecione o projeto primeiro

Antes de fazer perguntas, aprenda o que o código já diz. Isso reduz as perguntas àquelas que apenas o usuário pode responder. Procure por:

• Pilha tecnológica, frontend e backend, mobile ou web, onde fica o banco de dados.
• Páginas legais existentes (pesquise por "terms", "privacy", "cookies", "refund", "legal", "términos", "privacidade").
• Fluxos de registro e login, e todos os formulários que coletam dados pessoais. Liste cada campo.
• Scripts e SDKs de terceiros: análises, anúncios, pixels, replay de sessão, widgets de chat, mapas, vídeos incorporados, fontes de CDNs, rastreamento de erros, testes A/B.
• Cookies e armazenamento local que o aplicativo define.
• Pagamentos: provedor, pagamento único ou assinatura, produtos digitais ou físicos.
• E-mails e SMS: transacionais e de marketing.
• Imagens, vídeos, fontes, ícones e áudio no repositório ou carregados de URLs.
• Hospedagem e localização dos dados (região da nuvem).
• Quaisquer recursos de IA que processam dados do usuário.

Se ainda não houver código, pule esta etapa e pergunte mais na Etapa 2.

Etapa 2: Entreviste o usuário

Leia references/intake-questionnaire.md. Faça apenas as perguntas que a Etapa 1 não respondeu. Faça perguntas em pequenos grupos (5 a 8 perguntas de cada vez), começando pelo grupo mais importante: entidade legal e países. Ofereça respostas padrão sensatas sempre que possível para que o usuário possa responder rapidamente.

Não adivinhe fatos sobre o negócio. Um nome de empresa, país ou uso de dados errado em um documento legal é pior do que um ausente. Se o usuário não souber uma resposta, escreva um espaço reservado claro [TODO: ...] e adicione-o à lista de perguntas em aberto.

Etapa 3: Encontre as leis que se aplicam

As leis se aplicam com base em onde o negócio está estabelecido e onde seus usuários estão. Uma startup colombiana que vende para o México e os EUA deve seguir partes de todos os três.

1. Construa a lista de países (e estados dos EUA) a partir da entrevista.
2. Leia o arquivo correspondente em references/jurisdictions/:
   • latam.md para Colômbia, México, Brasil, Argentina, Chile, Peru e notas gerais da América Latina.
   • united-states.md para leis federais e estaduais.
   • other.md para qualquer outro país (notas curtas sobre UE e Reino Unido, e um método para pesquisar um país desconhecido).
3. Pesquise na web para confirmar que cada lei ainda está atualizada e para encontrar alterações após a data de referência.
4. Use a regra mais rigorosa aplicável quando as regras entrarem em conflito e um único fluxo global for mais simples. Por exemplo, um único período de reembolso que atenda ao mínimo legal mais longo é mais fácil do que um por país. Informe ao usuário quando fizer essa escolha e qual o custo.

Etapa 4: Audite e projete cada item

Trabalhe em cada item abaixo. Para cada um, leia o arquivo de referência que ele nomeia.

Item	Referência
Termos e Condições	references/documents.md
Política de Privacidade	references/documents.md
Política de Cookies e decisão de consentimento	references/cookies.md
Checkboxes de formulário de registro com links	references/consent-records.md
Registros de consentimento rastreáveis	references/consent-records.md
Política de Reembolso	references/documents.md (seção de reembolso) e o arquivo de jurisdição
Minimização de dados	references/data-minimization.md
Direitos de imagem e mídia	references/media-rights.md
Lista de verificação de leis locais	os arquivos de jurisdição

Regra do período de reembolso: o padrão do usuário é 5 dias após a compra. Use o maior entre este padrão e o mínimo legal de cada país que se aplica. Observe se a lei conta dias úteis ou dias corridos, e a partir de qual evento (data de compra, data de entrega ou data do contrato).

Etapa 5: Escreva o rascunho

Crie a pasta de rascunho no projeto. Caminho padrão: docs/legal-compliance/. Use a estrutura em assets/draft-structure.md. Em resumo:

docs/legal-compliance/
├── README.md                  # Resumo, perfil do negócio, leis, lista de verificação, perguntas em aberto
├── documents/
│   ├── terms-and-conditions.md
│   ├── privacy-policy.md
│   ├── cookies-policy.md
│   └── refund-policy.md
├── data-inventory.md          # Cada campo de dados, sua finalidade, base legal, retenção
├── media-inventory.md         # Cada ativo de mídia, fonte, licença, status
└── implementation-plan.md     # Alterações de código a serem feitas, passo a passo, na pilha do projeto

Escreva os documentos legais no idioma (ou idiomas) dos usuários-alvo. Use os dados reais do negócio da entrevista. Escreva em linguagem simples: frases curtas, títulos claros. A linguagem simples é mais fácil para os usuários entenderem, e muitas leis (por exemplo, no Brasil, México e Califórnia) exigem avisos claros e acessíveis.

Escreva implementation-plan.md para a pilha real do projeto, com caminhos de arquivo e esboços de código, para que um agente possa implementá-lo sem mais trabalho de design. Se não houver código, descreva as alterações em termos neutros em relação à pilha (modelo de dados, comportamento da interface do usuário, comportamento da API).

Etapa 6: Apresente e aguarde aprovação

Dê ao usuário um breve resumo:

• Leis que se aplicam e por quê.
• A lista de verificação com status: concluído, ausente ou precisa de uma decisão.
• Lacunas de alto risco primeiro (por exemplo: rastreadores que carregam antes do consentimento, nenhuma evidência de consentimento, mídia sem licença).
• Perguntas em aberto e itens [TODO].
• Itens que um advogado deve revisar.

Em seguida, pare. Não altere o código do aplicativo até que o usuário aprove o plano. Quando aprovar, implemente implementation-plan.md passo a passo e atualize a lista de verificação em README.md à medida que os itens forem concluídos.

Deveres contínuos para informar ao usuário

A conformidade não é uma tarefa única. Adicione estes ao README:

• Atualize os documentos quando o produto, o uso de dados, terceiros ou a lei mudarem. Aumente o número da versão, mantenha as versões antigas e peça aos usuários que aceitem novamente quando uma alteração for relevante.
• Mantenha os registros de consentimento pelo tempo que a lei exigir (veja references/consent-records.md).
• Responda às solicitações dos titulares dos dados (acesso, correção, exclusão, exclusão) dentro do prazo legal.
• Tenha um plano de resposta a violações de dados com os prazos de cada país.
• Verifique novamente antes de entrar em um novo país ou adicionar um novo uso de dados.