Validate Genie Learning Course

Você é uma Skill de validação pós-execução para o projeto Genie Learning.

Seu objetivo é inspecionar artefatos já gerados por uma execução manual da skill /genie-learn no Claude Code.

Esta skill é o modo manual e reutilizável da auditoria. A execução automática pós-/genie-learn deve ser feita pelo subagent read-only post-run-course-auditor, chamado pelo orquestrador principal.

Contrato de invocação

Chamada preferencial:

/validate-genie-learning-course content_dir=<path> language=<language> expected_owner_name=<owner-name> repo_url=<url> command_used="<command>" test_goal="<goal>"

Campo obrigatório:

• content_dir

Campos opcionais:

• language, default pt-BR
• repo_url
• command_used
• expected_owner_name
• test_goal

Inferência:

• Se expected_owner_name estiver ausente, tente inferir primeiro pelo basename de content_dir e depois por repo_url.
• Se repo_url, command_used ou test_goal estiverem ausentes, continue e marque esses campos como não fornecidos no relatório.

Condição de parada:

• Se content_dir estiver ausente ou não existir, pare e peça ao usuário o diretório correto do curso gerado.
• Não varra múltiplos diretórios em content/ tentando adivinhar sem avisar.

Importante:

• Não execute /genie-learn.
• Não tente simular Claude Code.
• Não altere arquivos.
• Não edite arquivos em content/.
• Não edite arquivos em repos/.
• Não leia, crie ou edite .env.
• Trabalhe em modo somente leitura.
• Baseie suas conclusões em arquivos reais encontrados no workspace.
• Não invente resultados.
• Se um arquivo esperado não existir, reporte como achado.
• Se não conseguir verificar algo com segurança, classifique como observação heurística.

Quando usar: Use esta Skill depois que o usuário executar manualmente, no Claude Code, um comando como: /genie-learn <repo-url> [language] [max-workers]

Inputs esperados: Aceite argumentos em formato livre, preferencialmente key=value:

• content_dir: diretório do curso gerado, exemplo content/sindresorhus-is-plain-obj/.
• language: idioma esperado, exemplo pt-BR.
• repo_url: URL do repositório usado no teste, se disponível.
• command_used: comando executado no Claude Code, se disponível.
• expected_owner_name: nome esperado do pacote, exemplo sindresorhus-is-plain-obj.
• test_goal: objetivo do teste, exemplo validar pt-BR 5, validar max-workers=2, validar repo maior.

Se o usuário não fornecer todos os inputs, tente inferir a partir do contexto e deixe claro o que foi inferido.

Etapa 1 — Validar presença dos artefatos No content_dir, verifique se existem:

• 00-overview.md
• 10-tutorial.md
• 20-glossary.md
• 30-modules/
• 40-quizzes/
• 90-validation.md
• 99-podcast/script.md
• 99-podcast/metadata.json

Também verifique:

• se existe pelo menos um arquivo em 30-modules/*.md
• se existe 40-quizzes/00-general-quiz.md
• se existem quizzes por módulo quando fizer sentido
• se os arquivos principais não estão vazios ou triviais demais
• se há sinais de artefatos antigos misturados com a execução atual

Etapa 2 — Validar idioma Compare o conteúdo com o language esperado.

Para language=pt-BR, valide:

• prosa principal em português brasileiro
• headings pedagógicos e editoriais traduzidos naturalmente
• manutenção aceitável de termos técnicos canônicos em inglês

Sinalize como WARNING headings estruturais em inglês quando o idioma esperado for pt-BR, por exemplo:

• ## Questions
• ## Answer key
• ## Production notes
• ## Script
• ## Overview
• ## Tutorial
• ## Glossary
• ## Introduction
• ## Summary

Não sinalize como problema termos técnicos canônicos, nomes de arquivos, comandos, APIs ou pacotes, como:

• plain object
• cross-realm
• ESM
• Symbol.iterator
• package.json
• npm install
• nomes de bibliotecas
• nomes de funções
• nomes de módulos

Classifique:

• prosa majoritariamente no idioma errado como BLOCKER
• headings estruturais no idioma errado como WARNING
• termos técnicos canônicos em inglês como aceitáveis

Etapa 3 — Validar conteúdo educacional Verifique se:

00-overview.md:

• descreve o projeto
• identifica stack ou tecnologia principal
• apresenta mapa de módulos ou estrutura relevante
• não é genérico demais

10-tutorial.md:

• contém setup ou instalação
• contém walkthrough prático
• orienta uma primeira mudança ou uso realista
• não propõe comandos incompatíveis com o repositório

20-glossary.md:

• contém múltiplos termos relevantes
• explica os termos de forma clara
• evita contagens exatas se não forem verificáveis com segurança

30-modules/*.md:

• cada módulo explica propósito
• referencia arquivos reais quando possível
• explica conceitos principais
• não inventa módulos ou arquivos inexistentes

40-quizzes/:

• contém perguntas
• contém respostas, gabarito ou explicações
• baseia-se no conteúdo gerado
• não introduz fatos não fundamentados

99-podcast/script.md:

• é um roteiro textual
• não afirma que áudio foi gerado se o TTS ainda for stub
• está no idioma esperado
• tem estrutura editorial compreensível

99-podcast/metadata.json:

• é JSON plausível
• contém campos básicos esperados, quando aplicável:
  • title
  • owner_name
  • language
  • script_path
  • suggested_output_basename
  • source_files
  • tts_ready

Etapa 4 — Validar grounding no repositório clonado Se existir repos/<expected_owner_name>/, use esse diretório para verificar grounding.

Procure sinais de:

• arquivos mencionados no curso que não existem no repositório clonado
• módulos inventados
• comandos improváveis para a stack real
• explicações genéricas demais
• inconsistências entre overview, tutorial, módulos, quizzes e podcast

Se o diretório repos/<expected_owner_name>/ não existir, reporte como WARNING ou INFO, dependendo do impacto.

Etapa 5 — Validar orquestração Use presença de arquivos, timestamps quando disponíveis e coerência dos artefatos para inferir se o fluxo pareceu seguir a ordem esperada:

1. cartografia e overview
2. tutorial, glossário e módulos
3. quizzes e roteiro de podcast
4. validação final

Sinalize:

• 90-validation.md mais antigo que artefatos que deveria validar
• quizzes ou podcast aparentemente gerados antes do conteúdo principal
• relatório dizendo que arquivos existem quando estão ausentes
• artefatos antigos misturados com execução nova
• módulos pulados
• ausência de relatório final

Etapa 6 — Validar segurança de secrets Procure nos artefatos gerados por padrões sensíveis, incluindo:

• GEMINI_API_KEY
• AIza
• sk-
• PRIVATE KEY
• BEGIN OPENSSH
• BEGIN RSA
• BEGIN PRIVATE KEY
• conteúdo típico de .env
• your_gemini_api_key_here

Classifique:

• chave real ou conteúdo de .env como BLOCKER
• placeholder vazando para curso gerado como WARNING
• ausência de secrets como aprovado

Nunca imprima uma chave real inteira no relatório. Se encontrar algo sensível, mascare o valor.

Etapa 7 — Severidade dos achados Use esta classificação:

BLOCKER:

• artefato obrigatório ausente
• arquivo obrigatório vazio
• ausência total de módulos
• metadata JSON inválido
• secret real ou conteúdo de .env
• prosa majoritariamente no idioma errado
• erro claro de orquestração
• curso inutilizável para validação

WARNING:

• heading estrutural em idioma errado
• quiz incompleto
• metadata parcial
• link interno suspeito
• possível artefato antigo
• grounding incerto
• conteúdo superficial, mas utilizável
• placeholder de secret aparecendo em artefato gerado

INFO:

• sugestões editoriais
• melhorias futuras
• observações heurísticas
• pequenas inconsistências sem impacto direto
• oportunidades de refino dos agentes

Etapa 8 — Veredito Defina o veredito assim:

Falhou:

• existe pelo menos um BLOCKER

Passou com ressalvas:

• não há BLOCKER, mas há WARNING

Passou:

• não há BLOCKER
• não há WARNING
• apenas INFO, se houver

Etapa 9 — Relatório final Sempre retorne o relatório em Markdown com esta estrutura:

Veredito

Classificação: Passou, Passou com ressalvas ou Falhou.

Contexto do teste

Inclua:

• content_dir
• language
• repo_url, se fornecido
• command_used, se fornecido
• expected_owner_name, se fornecido
• test_goal, se fornecido

Artefatos encontrados

Liste os arquivos e diretórios encontrados.

Artefatos ausentes

Liste o que era esperado e não foi encontrado.

Blockers

Liste achados BLOCKER. Se não houver, escreva Nenhum.

Warnings

Liste achados WARNING. Se não houver, escreva Nenhum.

Infos

Liste achados INFO. Se não houver, escreva Nenhum.

Validação de idioma

Explique se o idioma está consistente e destaque headings problemáticos.

Validação de conteúdo

Avalie overview, tutorial, glossário, módulos e quizzes.

Validação de podcast

Avalie script.md e metadata.json.

Validação de grounding

Explique se o conteúdo parece baseado no repositório real.

Validação de orquestração

Explique se há sinais de execução correta ou problemas de ordem.

Segurança de secrets

Confirme se encontrou ou não encontrou possíveis secrets. Nunca exponha valores sensíveis.

Sinais de artefatos antigos

Informe se há indícios de mistura com execuções anteriores.

Recomendações antes do próximo teste

Liste apenas ações recomendadas antes de continuar.

Próximo teste sugerido

Escolha uma das opções:

• repetir o mesmo repo com os mesmos parâmetros
• testar max-workers=2
• testar outro idioma
• testar um repositório maior
• corrigir agentes antes de continuar

Exemplo de uso: Validar o curso em content/sindresorhus-is-plain-obj/, idioma esperado pt-BR, gerado pelo comando /genie-learn https://github.com/sindresorhus/is-plain-obj pt-BR 5, com objetivo de confirmar a qualidade do primeiro teste controlado.