David-Li0406/meta-skill-evloving

Gerenciador de Arquivos de Skill Local

Propósito

Manter os arquivos de skill locais pessoais do usuário como um sistema de memória leve e auto-aprimorativo. O objetivo padrão não é produzir skills genéricas prontas para marketplace; é preservar comportamentos reutilizáveis que ajudem este usuário, esta equipe ou este workspace em sessões futuras. Um bom candidato pode codificar preferências pessoais de workflow, convenções de projeto, contratos de estilo, escolhas de ferramentas ou portas de revisão que não seriam úteis para outros usuários, desde que seja reutilizável para o proprietário pretendido e aprovado.

Esta skill não depende de código específico de projeto, servidores, armazenamentos vetoriais, bancos de dados ou layouts de armazenamento. Ela opera apenas em pastas de skill locais comuns:

<skill-root>/
  <skill-name>/
    SKILL.md
    agents/openai.yaml   (opcional)
    scripts/             (opcional)
    references/          (opcional)
    assets/              (opcional)

Use esta skill para decidir quando uma sessão contém material de skill reutilizável, descobrir se uma skill similar já existe e então descartar, melhorar, mesclar ou criar uma skill local. O modelo deve iniciar esta verificação quando sinais aparecerem; não deve esperar o usuário perguntar. A verificação deve permanecer leve e não bloqueante, a menos que o usuário peça explicitamente para focar na manutenção de skills.

Coordenação com Skills Relacionadas

Esta skill é dona do ciclo de vida da decisão: quando extrair, se deve descartar, se deve melhorar ou mesclar e onde escrever. Coordene com skills próximas quando estiverem instaladas:

• Use skill-creator para nova estrutura de skill, nomeação, colocação de recursos, agents/openai.yaml e validação.
• Use skill-improvement ou orientação de melhoria equivalente para iteração de skill existente, prompts de teste, análise de falhas, ajuste de descrição de gatilho e comparação antes/depois.
• Use skill-finder, find-skills ou ferramentas de descoberta equivalentes para pesquisar ecossistemas de skill locais ou externos antes de criar uma duplicata.
• Pegue emprestados padrões de auto-aprimoramento apenas como heurísticas de decisão: triagem de eventos, desduplicação, recorrência, prioridade, verificações de valor e portas de promoção. Não adote caminhos de armazenamento, suposições de daemon ou estrutura de código de outra skill, a menos que o usuário peça.
• Se essas skills auxiliares não estiverem disponíveis, aplique os procedimentos integrados abaixo. Não bloqueie por falta de skills auxiliares.
• Não deixe que skills auxiliares enfraqueçam o limite de extração: apenas mudanças de capacidade reutilizáveis e evidenciadas pelo usuário devem ser salvas.

Segurança e Consentimento

Skills locais podem influenciar o comportamento futuro do agente e podem incluir scripts executáveis. Trate edições de skill como mudanças de comportamento duráveis.

• Não instale, importe ou habilite skills de terceiros sem o consentimento do usuário.
• Não adicione capacidades surpreendentes, acesso de rede oculto, manipulação de credenciais, exfiltração de dados ou comandos destrutivos.
• Se uma skill adicionar scripts ou integrações de ferramentas, torne seu propósito visível em SKILL.md.
• Ao editar uma skill que pode ser compartilhada com uma equipe, preserve as políticas da organização e pergunte antes de alterar comportamento sensível à segurança.
• Trate cada candidato como pessoal por padrão; marque como equipe ou público apenas quando a evidência suportar esse público mais amplo.
• Não publique, recomende como amplamente reutilizável ou remova o escopo pessoal de uma skill específica do usuário sem aprovação explícita do usuário.
• Antes da primeira nota de aprendizado persistente ou escrita de skill em uma nova convenção local, diga ao usuário qual caminho seria escrito e peça aprovação.
• Não modifique silenciosamente este gerenciador autoskill durante a manutenção de rotina. Melhore-o apenas quando o usuário pedir explicitamente para melhorar esta skill.

Raízes de Skill

Antes de escrever qualquer coisa, identifique onde as skills locais residem.

• Use primeiro um caminho explícito fornecido pelo usuário.
• Caso contrário, verifique raízes comuns como ${CODEX_HOME}/skills, ~/.codex/skills, ./skills, .agents/skills e qualquer diretório de skill do workspace atual contendo */SKILL.md.
• Se exatamente uma raiz plausível existir, use-a.
• Se múltiplas raízes plausíveis existirem e o destino for ambíguo, pergunte ao usuário qual raiz manter.
• Nunca reorganize raízes de skill não relacionadas ou edite skills fora da raiz escolhida.

Política de Gatilho

Use uma política de gatilho de três camadas:

1. Varredura silenciosa: após cada interação substancial do usuário, pergunte brevemente se a interação contém uma preferência pessoal reutilizável, regra, correção, workflow, falha ou problema de qualidade de skill.
2. Verificação de extração: quando um gatilho abaixo disparar, classifique a experiência, atribua evidência e valor, pesquise skills similares e teste contra o limite de extração.
3. Escrita/atualização: edite arquivos de skill local apenas após o candidato passar pelo limite, a raiz de skill alvo estiver clara e o usuário aprovar a mudança exata.

O modelo deve iniciar proativamente varreduras e verificações de extração. Não pergunte ao usuário "devo verificar se há uma skill?" Pergunte apenas quando a raiz alvo for ambígua, a edição sobrescreveria comportamento incerto ou o usuário deve aprovar uma instalação externa ou script sensível.

Ciclo de Vida do Candidato

Mantenha o ciclo de vida separado de qualquer sistema de armazenamento específico: observe um sinal, opcionalmente peça ao usuário para escolher um título/tópico candidato, elabore o candidato, desduplique por padrão, decida descartar/manter_nota/melhorar/mesclar/criar, mostre a skill proposta completa ou diff, então aplique a menor mudança aprovada e valide.

Desduplique por família de tarefa, gatilho, ferramentas, modo de falha, contrato de saída e skill alvo, em vez de redação exata. Não crie um banco de dados privado, daemon, agendador ou armazenamento oculto em segundo plano como parte desta skill.

Porta de Seleção de Título

Antes da extração completa, quando o tópico reutilizável for ambíguo ou houver várias skills plausíveis, mostre 2-5 títulos concisos de capacidade reutilizável com razões de evidência de uma linha, além de nenhum destes e tópico personalizado. Se o usuário escolher um título ou digitar um tópico, trate apenas como direção: reexecute o limite de extração e a pesquisa de skill similar para essa direção, descarte se falhar ou mostre o SKILL.md/diff completo proposto para aprovação final se passar. Se o usuário escolher nenhum destes, descarte ou mantenha uma nota não persistente; não escreva arquivos.

Consistência de Idioma

Para novas skills, escreva títulos candidatos, SKILL.md proposto, agents/openai.yaml e pequenos recursos no idioma dominante da evidência do usuário; entrada em chinês produz skills em chinês, entrada em inglês produz skills em inglês. Para atualizações ou mesclas, mantenha o idioma dominante da skill alvo, a menos que o usuário peça explicitamente para traduzi-la; se evidência mista tornar o idioma ambíguo, pergunte antes de redigir. Não padronize o conteúdo da skill extraída para inglês.

Execução em Segundo Plano

A extração e manutenção de skills não devem bloquear a tarefa principal do usuário.

• Trate verificações de extração, pesquisa de skill similar, elaboração de candidatos e preparação de avaliação de gatilho como trabalho de manutenção em segundo plano sempre que possível.
• O trabalho em segundo plano pode preparar candidatos, encontrar skills similares e elaborar diffs, mas não deve escrever, atualizar, deletar, instalar ou habilitar skills sem confirmação do usuário.
• Continue a solicitação principal do usuário primeiro; não faça o usuário esperar pela extração de skill, a menos que o usuário tenha pedido explicitamente para focar na manutenção de skills.
• Apresente resultados em segundo plano apenas quando houver uma decisão candidata acionável, diff de arquivo proposto ou pergunta de esclarecimento/consentimento.
• Execute no máximo um trabalho de manutenção de skill em segundo plano por conversa ativa, a menos que o usuário peça um lote; faça fila ou coalesça sinais extras.
• Não inicie pesquisas caras, avaliações amplas ou reescritas grandes em primeiro plano. Use verificações leves primeiro e, em seguida, adie a validação mais profunda para uma pausa natural ou passagem de manutenção explícita.
• Se o runtime não puder realmente executar trabalho em segundo plano, emule-o adiando a verificação de manutenção até que a resposta atual esteja completa ou a próxima pausa natural.
• Nunca bloqueie a entrega do trabalho solicitado pelo usuário apenas para finalizar a extração do candidato, a menos que o trabalho solicitado seja a própria manutenção de skill.

Porta de Confirmação

A confirmação do usuário é necessária antes que qualquer arquivo de skill seja criado, atualizado, deletado, importado, instalado, habilitado ou materialmente reescrito. Primeiro elabore, depois pergunte: após qualquer seleção de título/tópico, nunca pergunte "devo adicionar/atualizar uma skill?" até que o conteúdo ou mudança proposto já esteja escrito para revisão.

Para criar, mostre antes de escrever:

• nome da skill proposta e caminho alvo
• público-alvo: pessoal, equipe ou público, além de limites de portabilidade
• por que o candidato passou no limite de skill reutilizável
• nível de evidência, sinal de recorrência, prioridade e sinal de valor
• skills similares verificadas e por que isso não é uma duplicata
• conteúdo completo do SKILL.md proposto
• agents/openai.yaml completo proposto e cada script, referência ou texto de recurso proposto, quando tais arquivos forem pequenos o suficiente para revisão inline; para recursos grandes, mostre a lista exata de arquivos, propósito, proveniência e diff ou manifesto gerado

Para melhorar ou mesclar, mostre antes de escrever:

• caminho exato da skill alvo
• tipo de decisão: melhorar ou mesclar
• por que a mudança pertence àquela skill existente
• nível de evidência, sinal de recorrência, prioridade e sinal de valor
• um diff unificado completo, ou texto antes/depois completo para cada seção alterada quando um diff unificado não estiver disponível
• cada arquivo que seria adicionado, modificado, deletado ou deixado intacto
• plano de validação ou comando para executar após a aprovação

Peça aprovação clara sim/não apenas após mostrar o artefato ou diff completo proposto. Se o usuário não aprovar, não edite a skill; relate o candidato como adiado ou descartado.

Gatilhos Imediatos

Execute uma verificação de extração imediatamente, ou na próxima pausa natural se o usuário estiver esperando pela tarefa principal, quando qualquer um destes acontecer:

• O usuário corrige, rejeita ou refina a abordagem do modelo de uma forma que deve afetar tarefas similares futuras.
• O usuário dá uma preferência durável, contrato de saída, workflow, regra de nomeação, regra de ferramenta ou porta de qualidade.
• Um comando, script, integração ou workflow falha e a sessão descobre uma correção reutilizável.
• O agente repete trabalho não trivial de configuração, script, transformação ou validação que deve se tornar um recurso reutilizável.
• Uma skill local similar sub-gatilhou, sobre-gatilhou ou produziu orientação incompleta.
• A sessão revela uma referência, template, script ou checklist ausente que evitaria esforço repetido futuro.
• O usuário usa linguagem orientada ao futuro como "lembre disso como uma skill", "salve este workflow", "atualize a skill local", "da próxima vez, faça assim", "este é meu processo padrão" ou "crie uma skill a partir desta conversa".

Ainda trate a extração como uma verificação, não um requisito: nenhuma mudança de skill é frequentemente o resultado correto.

Não extraia quando o usuário diz que a regra é temporária, pede para não lembrá-la ou quer apenas uma resposta única.

Verificações Agendadas

Use verificações agendadas para capturar aprendizado gradual que nenhuma única interação torna óbvio:

• Verificação de comprimento de conversa: após aproximadamente 6 mensagens substanciais do usuário, 12 turnos totais ou 2-3 tentativas de tarefa distintas desde a última verificação.
• Verificação de token/volume: após um longo bloco de novo contexto, especialmente quando a conversa pode em breve ser resumida ou compactada.
• Verificação de limite de tarefa: quando uma entrega é concluída, um loop de depuração termina, um plano é aceito ou o usuário muda para uma nova tarefa.
• Verificação de fim de sessão: antes da resposta final de uma sessão substancial, revise se algo deve ser descartado, melhorado, mesclado, criado ou anotado.

Mantenha as verificações agendadas leves. Elas geralmente devem acontecer silenciosamente e só aparecer para o usuário quando houver uma decisão acionável ou um esclarecimento necessário.

Debounce e Lote

Evite extração repetida ruidosa:

• Não re-verifique o mesmo sinal repetidamente em uma sessão.
• Agrupe múltiplos sinais fracos até um limite de tarefa ou verificação agendada.
• Crie ou atualize no máximo uma skill por verificação, a menos que o usuário peça explicitamente um lote.
• Prefira manter_nota ou descartar para sinais limítrofes até que a repetição fortaleça a evidência.
• Se um candidato estiver próximo, mas ainda não reutilizável o suficiente, lembre a justificativa na nota de conclusão em vez de criar uma skill.
• Coalesça gatilhos simultâneos em uma passagem de manutenção em segundo plano.
• Quando múltiplos candidatos competirem, lide primeiro com a falha repetida de maior prioridade ou preferência confirmada pelo usuário.

Triagem de Experiência

Antes de alterar skills, classifique a experiência da sessão. Categorias duráveis são erro, correção, melhor_prática, lacuna_de_conhecimento e preferência. resultado_único significa que a sessão produziu trabalho útil, mas nenhuma mudança de processo durável.

Apenas categorias duráveis podem se tornar mudanças de skill, e apenas após passar no limite de extração. Resultados únicos não devem ser promovidos.

Porta de Valor e Prioridade

• Prioridade P0: previne comportamento inseguro, destrutivo, sensível à privacidade ou com falha repetida.
• Prioridade P1: previne um erro significativo recorrente, gatilho perdido, mesclagem ruim ou workflow repetido caro.
• Prioridade P2: melhora qualidade, velocidade ou clareza para uma família de tarefas recorrente.
• Prioridade P3: melhoria de conveniência ou estilo com evidência limitada.

Promova por valor durável, não novidade. O valor deve ser explicável como confiabilidade, segurança, velocidade, qualidade, consistência ou redução de trabalho repetido. Se nenhuma dimensão de valor for clara, descarte ou mantenha uma nota não persistente.

Altere uma alavanca comportamental de cada vez ao melhorar uma skill existente: redação do gatilho, passo do workflow, porta de validação, colocação de recurso ou restrição de segurança.

Regras de Promoção

Não transforme toda experiência em uma edição de skill. Promova experiências deliberadamente:

• Promova imediatamente quando o usuário disser explicitamente que a regra deve se aplicar na próxima vez.
• Promova imediatamente quando uma correção evitar uma falha grave repetida, ação insegura ou workflow destrutivo.
• Promova após repetição quando o mesmo erro, correção ou melhor prática aparecer em várias tarefas similares.