Pular para o conteúdo
Skillpedia
Deploy e nuvem (DevOps)48 mil · #3894

production-audit

Faz seu agente verificar se um programa pronto para ser lançado está realmente bom. Ele checa vários pontos importantes para garantir a qualidade.

O que ela faz

Esta ferramenta verifica se o seu projeto está pronto para ser lançado em produção. Ela procura por problemas comuns que podem causar falhas, como falhas de segurança, erros em pagamentos ou problemas de experiência do usuário.

Quando usar

  • ✓Quando você quer saber se seu projeto está pronto para ir ao ar.
  • ✓Antes de lançar um novo recurso ou aplicativo.
  • ✓Após fazer muitas alterações no código e querer uma verificação geral.

Exemplo do que pedir para a IA

“Verifique se meu projeto está pronto para produção.”

Quer saber mais? Abra as seções abaixo.

Como usar

O jeito mais fácil: copie a mensagem abaixo e cole no Claude, ChatGPT, Cursor ou outra IA. Ela lê a skill e segue as instruções.

Link da skill

https://github.com/sickn33/agentic-awesome-skills/blob/main/plugins/agentic-awesome-skills-claude/skills/production-audit/SKILL.md

Mensagem pronta para colar

Use esta skill para me ajudar: https://github.com/sickn33/agentic-awesome-skills/blob/main/plugins/agentic-awesome-skills-claude/skills/production-audit/SKILL.md Leia o arquivo SKILL.md desse link e siga as instruções dele na minha tarefa.
Como funciona

A ferramenta roda um programa externo que analisa seu código e o ambiente onde ele está rodando. Ele gera um relatório com uma pontuação e lista os principais problemas encontrados.

Instalação

Jeito mais fácil: copie o link da skill e cole no Claude, ChatGPT ou Cursor pedindo para seguir as instruções.

No terminal (Claude Code, Codex, Cursor), na pasta do projeto:

npx skills add sickn33/agentic-awesome-skills --skill production-audit

Ou baixe só o arquivo:

curl -L https://raw.githubusercontent.com/sickn33/agentic-awesome-skills/main/plugins/agentic-awesome-skills-claude/skills/production-audit/SKILL.md -o SKILL.md
Conteúdo técnico (SKILL.md)

Tradução do texto original do autor no GitHub. Os comandos e códigos estão como no original.

Auditoria de Produção

Visão Geral

Uma habilidade que executa uma auditoria externa do estado implantado de um repositório publicado — URL ativa, sinais do GitHub, exposição de segredos, lacunas de RLS, idempotência de webhook, índices, observabilidade, injeção de prompt e outros dez modos de falha que projetos assistidos por IA rotineiramente perdem.

Isso é complementar às habilidades de segurança em sessão (security-review, estilo OWASP, VibeSec, Trail of Bits). Essas analisam o buffer do editor no momento da escrita. Esta analisa o produto implantado após o commit. Momento diferente, entradas diferentes, descobertas diferentes. Execute ambos para lançamentos sérios.

A habilidade envolve o motor de auditoria commit.show através da CLI pública (npx commitshow@0.3.23 audit . --json). Envelope JSON estável (schema_version: "1", apenas aditivo). Escreve um sidecar .commitshow/audit.{md,json} para que futuras sessões do agente possam ler o estado anterior sem reexecutar o motor.

Quando Usar Esta Habilidade

  • Use quando o usuário perguntar "isso está pronto para produção", "o que quebraria em produção", "pontue meu projeto", "o que eu perdi", "audite meu repositório", "pronto para enviar".
  • Use logo após mesclar um branch de funcionalidade para main (útil como um portão pré-implantação).
  • Use antes de um lançamento público / postagem no Show HN / demonstração para investidores.
  • Use quando git log mostrar >20 commits desde o último .commitshow/audit.md escrito.

Pular quando

  • Durante a codificação ativa em sessão — use security-review / estilo OWASP para padrões de nível de linha. Esta habilidade é para revisão pós-merge / pré-envio.
  • Para repositórios de bibliotecas / scaffolds — o motor lida melhor com formulários de aplicativos; bibliotecas recebem uma pontuação substituta parcial.
  • Se .commitshow/audit.json já existir e tiver menos de 1 hora, leia-o em vez de reexecutar. A auditoria tem limite de taxa (anônimo: 20/IP/dia · 5/repo/dia · 2000/dia global).
  • Dentro de um repositório privado / não-GitHub — a auditoria puxa sinais públicos do GitHub, portanto, repositórios privados retornam um erro not_found.

Como Funciona

Etapa 1: Executar a auditoria

Da raiz do repositório. A CLI é fixada em uma versão exata revisada para que futuras versões npm não sejam selecionadas silenciosamente. Como npx baixa e executa o código do pacote npm localmente com as permissões do usuário atual, execute-o apenas após o usuário aprovar explicitamente esta execução externa e apenas em um repositório onde os arquivos locais e as variáveis de ambiente sejam seguros para esse processo acessar. O diretório sidecar é criado antecipadamente, e o stderr é separado para que avisos de instalação/depreciação não corrompam o envelope JSON:

mkdir -p .commitshow
npx commitshow@0.3.23 audit . --json \
  > .commitshow/audit.json \
  2> .commitshow/audit.stderr.log

Isso também escreve um .commitshow/audit.md legível ao lado dele. Invocações subsequentes devem comparar com o audit.json anterior, se existir, para que você possa começar com "+5 desde a auditoria de ontem" em vez de apenas um número absoluto.

Se o usuário apontou para um URL remoto em vez de ., troque . pelo URL — mantenha o mesmo mkdir -p + pin de versão + divisão de stderr:

mkdir -p .commitshow
npx commitshow@0.3.23 audit github.com/owner/repo --json \
  > .commitshow/audit.json \
  2> .commitshow/audit.stderr.log

Etapa 2: Analisar o envelope

O envelope JSON é estável (schema_version: "1", apenas aditivo). Leia estes campos:

Campo Significado
score.total pontuação de prontidão de produção de 0 a 100
score.delta_since_last mudança em relação ao snapshot pai · positivo = melhorando
score.band strong (80+) · mid (60-79) · early (<60)
concerns[] principais problemas, ordenados por impacto · cada um tem axis + bullet
strengths[] 3 principais coisas que funcionam · apenas para contexto
standing opcional · apenas quando o projeto está sendo auditado no commit.show
snapshot.created_at / trigger_type quando a auditoria foi executada

As preocupações são ordenadas por impacto na decisão, não por gravidade. A posição 1 é o item a ser destacado.

Etapa 3: Apresentar ao usuário

Comece com a pontuação + trajetória em uma frase, depois as principais preocupações. Não despeje o JSON completo. Formato:

Score: 82/100 (+5 since yesterday) · band: strong

Top concerns:
  ↓ [Security] No API rate limiting on /auth — IP cap missing
  ↓ [Infrastructure] webhook handler at api/stripe.ts — signature verified, but no
    idempotency-key check (replay attack window open)

Want me to fix the webhook idempotency gap first?

Regras:

  • Use o item exato de concerns[].bullet — o motor de auditoria já escreveu texto orientado para ação.

…

Perguntas frequentes

O que é 'RLS'?

RLS significa 'Row Level Security' (Segurança em Nível de Linha), um recurso de banco de dados que controla quem pode ver ou modificar quais dados.

O que são 'webhooks'?

Webhooks são notificações automáticas enviadas por um aplicativo para outro quando algo acontece. A ferramenta verifica se eles funcionam corretamente e de forma segura.

O que é 'idempotência'?

Idempotência significa que uma ação pode ser repetida várias vezes sem alterar o resultado após a primeira vez. É importante para evitar problemas como cobranças duplicadas em pagamentos.

Detalhes

Descrição original do autor

Audit a shipped repo for production-readiness gaps across RLS, webhooks, secrets, grants, Stripe idempotency, mobile UX, and deployment health.

repo: sickn33/agentic-awesome-skills

Popularidade

Estrelas no GitHub
48 mil
Posição no ranking
#3894
Licença
MIT
Atualizada em
15/10/2026

Essa skill é útil?

0

Entre para votar.

Comentários

  • …

Mais skills deste repositório

Skills parecidas