GzmSTAR/master-learning-skill

Master Learning

O Master Learning faz o Codex agir como um aprendiz sério antes de atuar como especialista. Use-o para estudar o domínio, ecossistema, material de origem e padrões de implementação antes de planejar ou alterar código.

Regra Principal

Não pule diretamente para a implementação quando a tarefa depender de conhecimento de domínio que o Codex não tenha fundamentado em fontes atuais. Primeiro produza um Briefing de Aprendizado. Em seguida, use o briefing como base para o plano, design, testes ou implementação.

Decisão de Acionamento

Use esta habilidade quando qualquer uma das seguintes condições for verdadeira:

• O usuário pede para construir em um domínio, framework, área de pesquisa, protocolo, padrão ou ecossistema de hardware/software desconhecido.
• A tarefa menciona "pesquisar", "aprender primeiro", "melhores práticas", "mais recente", "artigos", "GitHub", "exemplos", "benchmarks", "padrões" ou intenção equivalente em qualquer idioma.
• Uma suposição errada poderia causar trabalho de implementação desperdiçado, design inseguro, baixa qualidade acadêmica/de engenharia ou APIs incompatíveis.
• A tarefa envolve selecionar bibliotecas, reproduzir um artigo, adaptar um repositório de muitas estrelas, seguir documentação oficial ou entender convenções de projetos locais antes de editar.

Não use esta habilidade para edições triviais, correções diretas de bugs com evidências locais claras, trabalhos apenas de formatação ou tarefas onde o usuário explicitamente diz para não pesquisar.

Fluxo de Trabalho

1. Defina o objetivo de aprendizado. Reafirme o objetivo do projeto, público, ambiente alvo, critérios de sucesso e as incógnitas que devem ser resolvidas.
2. Escolha a profundidade da pesquisa. Comece com scout a menos que a tarefa seja de alto risco, nova, regulamentada, baseada em artigos ou com fontes conflitantes; então use deep. Use refresh para tarefas de manutenção onde o domínio é conhecido, mas as dependências podem ter mudado.
3. Colete fontes em ordem de prioridade. Prefira documentação oficial e a verdade do repositório local primeiro, depois padrões/especificações, artigos, repositórios GitHub de alta qualidade, exemplos/testes/issues e artigos de engenharia confiáveis.
4. Aprenda padrões, não trivia. Extraia conceitos do domínio, fluxo de dados/controle, contratos de API, arquiteturas comuns, casos extremos, modos de falha, abordagens de teste e antipadrões.
5. Audite a cobertura das fontes. Marque lacunas claramente. Se não houver fonte oficial, nenhum exemplo de código ou nenhuma fonte atual existir, rotule a conclusão como provisória.
6. Produza um Briefing de Aprendizado. Mantenha-o acionável: o que construir, o que evitar, o que verificar e quais suposições permanecem.
7. Proceda apenas após fundamentação. Use o Briefing de Aprendizado para fazer o plano de implementação ou alterações de código. Se o briefing expor riscos críticos não resolvidos, pergunte ou pesquise mais antes da implementação.

Portal de Validação no Estilo SkillOpt

Esta habilidade é otimizada com um loop inspirado em SkillOpt: tarefas em rollout, refletir sobre falhas, aplicar edições limitadas e manter um candidato somente quando a validação melhora. No momento da tarefa, use a mesma disciplina:

• Trate o Briefing de Aprendizado como o procedimento treinável para o projeto atual, não como um relatório decorativo.
• Faça atualizações limitadas quando a evidência mudar: adicione, exclua ou substitua apenas as regras necessárias para melhorar a próxima decisão.
• Preserve suposições rejeitadas no briefing para que não sejam reintroduzidas posteriormente.
• Antes da implementação, execute um portal de validação: cobertura de fontes, adequação ao código local, revisão de riscos e critérios de aceitação.
• Se o portal de validação falhar, melhore o briefing em vez de codificar através da incerteza.

Disciplina de Treinamento

Use estes controles no estilo SkillOpt durante projetos longos ou melhoria repetida da habilidade:

• Taxa de aprendizado textual: prefira uma ou duas edições precisas de regras após cada falha, não uma reescrita completa.
• Buffer de suposições rejeitadas: registre suposições que foram refutadas, como APIs desatualizadas, repositórios abandonados, licenças incompatíveis, artigos fracos ou exemplos que não correspondem ao tempo de execução do usuário.
• Validação retida: teste o briefing atualizado contra um cenário diferente antes de confiar na nova regra.
• Atualização lenta: se a mesma falha aparecer em várias tarefas, promova-a de uma nota única para SKILL.md ou um arquivo de referência.
• Verificação de regressão: confirme que a habilidade ainda ignora tarefas triviais e não pesquisa excessivamente correções diretas.

Regras de Tratamento de Cenários

• Para tarefas de framework/API mais recentes, verifique documentação oficial, notas de versão, notas de migração e versões de dependências locais antes de recomendar código.
• Para tarefas de reprodução de artigo, leia o método do artigo, suposições, configuração de avaliação, disponibilidade de código/dados e incompatibilidade com o ambiente do usuário.
• Para tarefas de adaptação do GitHub, inspecione licença, atividade recente, exemplos, testes, issues, saúde das dependências e se a reutilização é permitida ou apenas o aprendizado é apropriado.
• Para tarefas de projeto local, inspecione manifestos, configurações, testes, documentos e convenções existentes antes de fontes externas.
• Para correções diretas de baixo risco, pule explicitamente a pesquisa profunda e declare por que a habilidade não é necessária.
• Para tarefas com rede degradada, rotule a verificação externa ausente e continue apenas com evidências locais ou peça permissão/entrada quando necessário.

Contrato de Saída

Todo Briefing de Aprendizado deve incluir:

• Tarefa: objetivo de aprendizado, ambiente alvo, critérios de sucesso, profundidade da pesquisa e confiança.
• Fontes: URLs/caminhos, tipo, data/atualidade quando disponível, confiabilidade e uso principal.
• Modelo de Domínio: conceitos-chave, objetos, termos e relacionamentos.
• Lições do Código Local: estrutura do projeto, convenções, restrições e arquivos relevantes quando existir código local.
• Lições do GitHub/Código: repositórios revisados, padrões úteis, notas de licença/reutilização e issues.
• Lições de Artigos/Padrões: métodos, requisitos, limites e suposições.
• Padrões de Implementação: arquitetura, APIs/contratos, fluxo de dados/controle, testes e restrições operacionais.
• Riscos e Antipadrões: casos extremos, suposições fracas e coisas a evitar.
• Recomendação: abordagem recomendada, critérios de aceitação e próximos passos.
• Perguntas em Aberto: decisões não resolvidas ou evidências ausentes.

Use references/learning-brief-template.md quando um artefato Markdown estruturado for útil.

Recursos Anexados

Leia estes arquivos apenas quando relevante:

• references/research-depths.md: escolha scout, deep ou refresh.
• references/source-quality-rubric.md: avalie e compare fontes.
• references/github-mining.md: inspecione repositórios GitHub sem ser enganado apenas por estrelas.
• references/paper-learning.md: transforme artigos em restrições de engenharia.
• references/skillopt-training.md: protocolo de otimização inspirado em SkillOpt usado para esta habilidade.
• references/learning-brief-template.md: produza um briefing consistente.
• references/anti-patterns.md: evite modos de falha comuns.
• training/benchmark-scenarios.json: conjunto de cenários retidos usado para teste de regressão desta habilidade.

Scripts são ajudantes opcionais:

• scripts/create_learning_brief.py: crie um esqueleto de Briefing de Aprendizado.
• scripts/github_scan.py: pesquise repositórios GitHub e exporte candidatos.
• scripts/paper_scan.py: pesquise APIs públicas CrossRef, arXiv e PubMed.
• scripts/source_audit.py: verifique a cobertura de fontes e avise sobre fundamentação fraca.
• scripts/merge_learning_brief.py: mescle saídas de varredura em um rascunho de briefing.
• scripts/skillopt_train.py: execute o benchmark de treinamento e validação local no estilo SkillOpt.

Regras de Integridade

• Nunca invente descobertas de fontes, citações, conteúdos de repositório ou comportamento de API.
• Se o acesso à rede falhar, diga que a pesquisa foi degradada e explique o que não foi verificado.
• Prefira fontes primárias em vez de resumos.
• Para alegações de "mais recente", verifique a documentação ou lançamentos atuais antes de confiar na memória.
• Trate uma postagem de blog, uma resposta Stack Overflow ou um README como insuficientes para decisões de alto risco.
• Quando as fontes discordarem, preserve a discordância e recomende o caminho verificável mais seguro.