Auditoria de Superfície de Workspace

Habilidade de auditoria somente leitura para responder à pergunta "o que este workspace e máquina realmente podem fazer agora, e o que devemos adicionar ou habilitar em seguida?"

Esta é a resposta nativa do ECC para plugins de auditoria de configuração. Ela não modifica arquivos, a menos que o usuário solicite explicitamente a implementação de acompanhamento.

Quando Usar

• O usuário diz "configurar Claude Code", "recomendar automações", "quais plugins ou MCPs devo usar?" ou "o que está faltando?"
• Auditoria de uma máquina ou repositório antes de instalar mais habilidades, hooks ou conectores
• Comparação de plugins do marketplace oficial com a cobertura nativa do ECC
• Revisão de .env, .mcp.json, configurações de plugins ou superfícies de aplicativos conectados para encontrar camadas de fluxo de trabalho ausentes
• Decidir se uma capacidade deve ser uma habilidade, hook, agente, MCP ou conector externo

Regras Inegociáveis

• Nunca imprima valores secretos. Exponha apenas nomes de provedores, nomes de capacidades, caminhos de arquivos e se uma chave ou configuração existe.
• Prefira fluxos de trabalho nativos do ECC em vez de conselhos genéricos de "instalar outro plugin" quando o ECC puder gerenciar razoavelmente a superfície.
• Trate plugins externos como benchmarks e inspiração, não como limites autoritativos de produto.
• Separe claramente três coisas:
  • já disponível agora
  • disponível, mas não bem encapsulado no ECC
  • não disponível e exigiria uma nova integração

Entradas da Auditoria

Inspecione apenas os arquivos e configurações necessários para responder bem à pergunta:

1. Superfície do repositório
   • package.json, lockfiles, marcadores de linguagem, configuração de framework, README.md
   • .mcp.json, .lsp.json, .claude/settings*.json, .codex/*
   • AGENTS.md, CLAUDE.md, manifestos de instalação, configurações de hook
2. Superfície do ambiente
   • arquivos .env* no repositório ativo e workspaces adjacentes óbvios do ECC
   • Exponha apenas nomes de chaves como STRIPE_API_KEY, TWILIO_AUTH_TOKEN, FAL_KEY
3. Superfície da ferramenta conectada
   • Plugins instalados, conectores habilitados, servidores MCP, LSPs e integrações de aplicativos
4. Superfície do ECC
   • Habilidades, comandos, hooks, agentes e módulos de instalação existentes que já cobrem a necessidade

Processo de Auditoria

Fase 1: Inventário do que Existe

Produza um inventário compacto:

• alvos ativos do harness
• plugins instalados e aplicativos conectados
• servidores MCP configurados
• servidores LSP configurados
• serviços baseados em ambiente implícitos por nomes de chaves
• habilidades ECC existentes já relevantes para o workspace

Se uma superfície existir apenas como um primitivo, chame a atenção para isso. Exemplo:

• "Stripe está disponível via aplicativo conectado, mas o ECC carece de uma habilidade de operador de faturamento"
• "Google Drive está conectado, mas não há um fluxo de trabalho de operador nativo do ECC para o Google Workspace"

Fase 2: Benchmark Contra Superfícies Oficiais e Instaladas

Compare o workspace com:

• plugins oficiais do Claude que se sobrepõem à configuração, revisão, documentação, design ou qualidade do fluxo de trabalho
• plugins instalados localmente no Claude ou Codex
• as superfícies de aplicativos conectadas atualmente do usuário

Não liste apenas nomes. Para cada comparação, responda:

1. o que eles realmente fazem
2. se o ECC já tem paridade
3. se o ECC tem apenas primitivos
4. se o ECC está faltando o fluxo de trabalho inteiramente

Fase 3: Transforme Lacunas em Decisões do ECC

Para cada lacuna real, recomende a forma nativa correta do ECC:

Prefira habilidades voltadas para o usuário que orquestram ferramentas existentes quando a necessidade é operacional em vez de infraestrutural.

Formato de Saída

Retorne cinco seções nesta ordem:

1. Superfície atual
   • o que já é utilizável agora
2. Paridade
   • onde o ECC já corresponde ou excede o benchmark
3. Lacunas apenas de primitivos
   • ferramentas existem, mas o ECC carece de uma habilidade de operador limpa
4. Integrações ausentes
   • capacidade ainda não disponível
5. 3-5 principais próximos passos
   • adições concretas nativas do ECC, ordenadas por impacto

Regras de Recomendação

• Recomende no máximo 1-2 ideias de maior valor por categoria.
• Prefira habilidades com intenção de usuário óbvia e valor de negócio:
  • auditoria de configuração
  • operações de faturamento/cliente
  • operações de issues/programas
  • operações do Google Workspace
  • controle de implantação/operações
• Se um conector for específico da empresa, recomende-o apenas quando estiver genuinamente disponível ou for claramente útil para o fluxo de trabalho do usuário.
• Se o ECC já tiver um primitivo forte, proponha uma habilidade wrapper em vez de inventar um subsistema totalmente novo.

…