Auditoria de org para tarefas
A versão artesanal disso levava meio dia: ler uma auditoria longa, decidir o que pertence junto, escrever cada tarefa com prioridade e definição de pronto, e então digitar no rastreador. Esta skill faz a leitura e a digitação. A decisão continua com a pessoa.
Etapa 1: pergunte antes de agir
Pergunte em uma mensagem e aguarde:
- Qual org (alias da CLI)? Confirme que não é um org de produção do cliente, a menos que o engajamento permita varreduras somente leitura lá.
- Para onde vão as tarefas? ClickUp (qual lista) ou GitHub (qual repositório). Verifique se o servidor MCP correspondente está conectado; caso contrário, pare e diga como conectá-lo.
- Quem é o responsável pelas tarefas? Nomes dos responsáveis ou deixe sem atribuição.
- Algo para deixar de fora? Algumas descobertas são conhecidas e aceitas. Dizer isso agora evita ruído depois.
Etapa 2: auditar
node audit.js --org <alias> --out ./out
Escreve out/findings.md e out/findings.json. Somente leitura: toda chamada é uma consulta ou uma listagem.
Etapa 3: modelar as tarefas
node to-tasks.js out/findings.json
Escreve out/tasks.json: uma tarefa por tipo e severidade de descoberta, cada componente afetado como um item de lista de verificação, grupos grandes divididos em lotes de 25, com prioridade, esforço, rótulos e critérios de aceitação.
Etapa 4: revisar com a pessoa
Mostre a lista de tarefas como uma tabela: chave, título, prioridade, esforço, contagem de itens da lista de verificação. Em seguida, aplique o julgamento que o script não pode:
- Mesclar ou dividir onde o agrupamento não corresponde a como a equipe trabalha.
- Remover as descobertas que a pessoa disse para deixar de fora na Etapa 1.
- Destacar algo que parece pequeno, mas não é (um usuário de integração com Modificar Todos os Dados é uma descoberta de segurança e uma descoberta de controle de mudanças).
- Reescrever critérios de aceitação onde a equipe tem sua própria definição de pronto.
Não crie nada até que a pessoa diga que a lista está correta.
Etapa 5: criar
Crie cada tarefa aprovada através do servidor MCP conectado, ou para GitHub com node create-issues.js --repo owner/name (visualize primeiro com --dry-run), com título, descrição, prioridade, rótulos, lista de verificação (lista de verificação do ClickUp ou uma lista de tarefas do GitHub no corpo) e critérios de aceitação. Registre a URL de cada tarefa criada de volta em out/tasks.json sob url.
Em seguida, relate: quantas tarefas foram criadas, onde e o tempo desde a Etapa 2 até a última tarefa criada.
Regras
- A auditoria nunca escreve no org.
- Nenhuma tarefa é criada sem aprovação da lista.
- Nenhum nome de cliente em nada que saia da pasta do engajamento.
- Se uma chamada do sistema de tarefas falhar, pare, relate o que foi criado e o que não foi, e não tente novamente cegamente.