Skulto Release Cert

• Antes de criar uma tag de novo release do skulto ou atualizar o tap do Homebrew, para confirmar que todos os quality gates estão verdes.
• Quando você precisa de um processo determinístico, passo a passo e executável por agente para verificar o comportamento da CLI em cenários de estado aquecido, slate limpo, migração e reconciliação.
• Quando você deseja varredura de segurança automatizada (segredos hardcoded, injeção de SQL, injeção de comandos, arquivos de credenciais) combinada com um checklist de revisão manual antes de fazer o ship.
• Quando estiver integrando um novo certificador (humano ou agente) que precisa de uma referência canônica e autocontida sobre o que "pronto para release" significa para o skulto.

• Se você não está trabalhando no projeto skulto — esta skill está fortemente acoplada à base de código, comandos CLI e esquema de banco de dados do skulto.
• Se você precisa apenas de um teste rápido de fumaça; esta é uma execução completa de certificação e é intencionalmente minuciosa e demorada.
• Se o binário do skulto ainda não foi compilado — o Pass 1 deve ser concluído com sucesso antes que os passes posteriores sejam significativos.

A certificação é dividida em três passos sequenciais: testes unitários, lint e compilação cruzada (Passo 1); um walkthrough abrangente da CLI (Passo 2); e uma auditoria de segurança (Passo 3). Os três devem estar aprovados antes que o veredicto CERTIFIED FOR RELEASE seja emitido.

O Passo 1 realiza a compilação cruzada do binário skulto para quatro alvos — linux/amd64, linux/arm64, darwin/amd64 e darwin/arm64 — com CGO_ENABLED=0. Todos os quatro devem ser concluídos com sucesso antes de prosseguir.

O Passo 2 cobre estado aquecido, ciclo de vida com ambiente limpo, migração, reconciliação, limpeza de habilidades obsoletas, fluxos de varredura de segurança, metadados MCP, saída sem emojis e a lógica de "lembrar locais de instalação". Uma captura de estado é realizada antes de qualquer teste e verificada em relação a um diff após todos os testes, garantindo que o processo do Skulto Release Cert seja não destrutivo.

Várias subseções do Pass 2 testam se o scanner de segurança integrado do Skulto se comporta corretamente: skills limpas são instaladas silenciosamente, skills em quarentena são bloqueadas ou geram avisos, e os resultados da varredura aparecem nos fluxos add, pull, ingest, instalação por URL, sync e save.

Aprovação em 3 execuções de varreduras baseadas em grep para segredos hardcoded, interpolação de strings SQL, padrões de injeção de comandos e arquivos de credenciais commitados, complementadas por um checklist de revisão manual cobrindo consultas parametrizadas, uso de exec.Command, escopo de os.RemoveAll e injeção de chave do PostHog via ldflags.

Após as três passagens, a skill produz uma tabela de certificação formatada listando cada verificação com o status PASS/FAIL/SKIPPED/CLEAN/FOUND, a versão, a data e o certificador, culminando em um veredicto claro de CERTIFIED FOR RELEASE ou BLOCKED.

Um agente de IA executa todas as três etapas contra um binário skulto compilado, percorrendo cada passo numerado e linha de tabela, e produz o resumo final de certificação sem intervenção humana (exceto pelas etapas interativas de terminal marcadas explicitamente como MANUAL-only).

Antes de atualizar a fórmula do Homebrew tap para apontar para uma nova versão, um desenvolvedor ou agente executa esta skill a partir da raiz do repositório skulto para confirmar que o build está limpo, todos os caminhos da CLI se comportam conforme o esperado e nenhuma regressão de segurança existe.

Após mudanças significativas na lógica de instalação, varredura ou reconciliação do skulto, o fluxo de verificação da CLI (2a–2t) expõe regressões em toda a superfície de comandos, incluindo casos extremos como registros de banco de dados desatualizados, bloqueio de habilidades em quarentena e comportamento de localização de instalação memorizada.

Um novo membro da equipe ou agente não familiarizado com os critérios de lançamento da Skulto usa esta habilidade como referência única e autoritativa sobre o que constitui uma build pronta para envio, incluindo problemas conhecidos pré-existentes que são monitorados, mas não bloqueantes.