# Process Health > Diagnostica a saúde de um processo do Pipefy com dados reais: gargalo, retrabalho, SLA, qualidade de dados, automação ligada e desligada, e oportunidades de automação ou IA. Use quando pedirem para analisar um pipe, entender por que um processo está lento, revisar SLA, encontrar campos sem uso ou decidir onde cabe agente de IA. Gatilhos - 'analisa esse pipe', 'onde está o gargalo', 'por que esse processo demora', 'meu processo está saudável', 'o que dá para automatizar aqui', 'onde eu usaria IA nesse processo', 'esse pipe está bem configurado'. - Skill: `maurivanluiz/process-health` (Agent Skill, multi-file: 6 files) - Install (CLI): `npx skillmds@latest add maurivanluiz/process-health` - Raw SKILL.md: https://api.skillmd.com/api/skills/maurivanluiz/process-health/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: maurivanluiz (https://skillmd.com/u/maurivanluiz) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/maurivanluiz/process-health --- # Process Health ## Descrição Analisa um pipe do Pipefy e produz um diagnóstico com evidência: onde o tempo está, o que volta atrás, o que não tem SLA, quais campos não recebem dado, o que já está automatizado e quais decisões são previsíveis o suficiente para virar automação em vez de agente de IA. Esta skill observa, diagnostica e recomenda. Não altera nada no Pipefy: nem campo, nem SLA, nem automação, nem agente. Quando um dado não existir, escreva "não medido" e diga qual conclusão fica bloqueada, em vez de estimar. Usa apenas as ferramentas do MCP do Pipefy. Não há script nem dependência a instalar: só este arquivo e os arquivos de referência ao lado dele. ## Quando usar - O dono de um processo quer saber onde ele está travando. - Alguém pergunta o que dá para automatizar em um pipe. - Antes de propor um agente de IA, para checar se uma automação resolveria. - Revisão de configuração: SLA ausente, campos sem uso, automação desligada. - Comparar o mesmo processo antes e depois de uma mudança. ## Referências Este arquivo é o fluxo. O detalhe mora em `references/`, e cada arquivo é lido no passo que precisa dele, não antes. Ler tudo de uma vez desperdiça contexto que a coleta de cards vai consumir. | Arquivo | Quando ler | O que tem | |---|---|---| | `references/collect.md` | antes do passo 1 | inputs, queries GraphQL, paginação, agregação por página, casos de borda | | `references/metrics.md` | no passo 4 | definição de cada métrica, limiares, guardas, dimensões e o que cada achado permite afirmar | | `references/response.md` | no passo 5 | glossário de identificador para língua do processo, formato das três tabelas, fechamento, exemplo | | `references/publish.md` | só se o usuário pedir para publicar | conteúdo da página, design system, composição, publicação | ## Fluxo **1. Coletar.** Leia `references/collect.md` e siga: estrutura do pipe, automações, cards paginados de trás para frente. **2. Agregar por página.** Ainda em `references/collect.md`. Atualize o estado depois de cada página e descarte o detalhe dos cards. A tabela de estado daquele arquivo é um contrato: o que não estiver nela não pode ser calculado no passo 4, porque os cards já foram descartados. **3. Checar os portões da coleta.** Visibilidade parcial, concluídos insuficientes, nenhuma fase com prazo, coleta truncada no limite: os casos de borda em `references/collect.md` trazem os limiares e dizem o que fica bloqueado. As guardas de cálculo são outras, e entram no passo 4. A resposta continua saindo, com a limitação declarada junto do número. Não confunda recorte com viés. A janela e o limite de cards cortam de propósito, e ver uma fração pequena de um pipe grande é normal. Viés é ver menos do que a janela pede, e a seção de cobertura daquele arquivo diz como distinguir os dois. **4. Calcular.** Leia `references/metrics.md` e siga as regras à risca, incluindo as guardas. Elas existem porque cada uma corrigiu um falso positivo observado em dados reais. **5. Responder.** Leia `references/response.md`. Ressalva de visibilidade primeiro, depois a tabela de dimensões, que fecha com o potencial de IA em escala própria, depois os achados de severidade alta com evidência. As oportunidades entram como achados, com a ação dizendo se é automação determinística ou IA. Uma única próxima ação. Máximo de 30 linhas: diagnóstico longo não é lido. **6. Perguntar o que vem depois, de forma interativa.** Feche com a ferramenta de pergunta interativa do ambiente (`AskUserQuestion` no Claude Code), não com uma frase solta. Uma pergunta, escolha única, com as opções da seção "Fechamento" de `references/response.md`. Sem ferramenta interativa, use uma linha de texto com as mesmas opções. **7. Publicar, só se pedirem.** Nunca publique o relatório por iniciativa própria: na maioria das vezes a resposta em texto resolve, e uma página que ninguém pediu é trabalho jogado fora. Quando o usuário escolher publicar, leia `references/publish.md`, use a ferramenta `Artifact` e entregue o link. Não gere arquivo HTML local: o relatório existe para circular, e arquivo em disco não circula. O artefato nasce privado, e quem decide abrir é o usuário. ## Governança - **Nada de vocabulário de API na tela, em nenhum momento.** A proibição não vale só para a resposta final: vale para o que você escreve enquanto coleta. Não narre nome de ferramenta, de consulta ou de campo da API, nem em relato de progresso, nem em aviso de erro, nem para justificar uma dimensão não medida. Em vez de "chamando get_automations", escreva "lendo as automações do processo"; em vez de "get_automations falhou", escreva "não consegui ler as automações, então essa dimensão fica não medida". Os identificadores existem dentro da chamada de ferramenta, e é lá que eles ficam. A lista do que nunca aparece está em `references/response.md`. - Os valores dos campos passam pelo seu contexto, porque a API não permite pedir apenas o preenchimento. Nunca transcreva valor de campo na resposta nem no relatório: conte presença, cardinalidade e repetição, e cite cards por ID. Em pipe com dado sensível (folha de pagamento, saúde, jurídico de pessoa física), avise o usuário antes de coletar. - Ao compartilhar um relatório, confira se o público pode ver aquele processo. - Campo com pouco uso é a recomendação mais perigosa daqui. Um campo preenchido três vezes por ano pode ser exigência de auditoria, contrato ou LGPD. Sempre "confirmar com o dono do processo", nunca "remover". - Nenhuma alteração no Pipefy sai desta skill. Se o usuário quiser executar uma recomendação, isso exige confirmação explícita dele sobre o que exatamente será alterado. - Processos que continuam em pipe conectado não são atravessados. Se `childrenRelations` ou `parentsRelations` existirem, diga que a análise para na fronteira do pipe e que o gargalo pode estar do outro lado. ## Critério de qualidade A resposta está pronta quando declara janela, número de cards e visibilidade; traz evidência junto de cada afirmação; separa observação de hipótese, usando "pode estar" onde a confiança é média; marca como não medida toda dimensão sem dado; aplica as três guardas de contribuição por fase; distingue automação determinística de trabalho que exige IA; não contém nenhum identificador interno de API nem nome de ferramenta, nem na resposta nem no que você escreveu antes dela; e termina em uma única próxima ação com responsável. Antes de entregar, releia procurando underscore e inglês técnico. Achou algum fora de bloco de código, traduza. Uma recomendação sem evidência é hipótese, e deve ser apresentada como tal. Como os números são calculados por você e não por script, duas execuções podem divergir. Se o usuário for usar o resultado para decidir algo que precise ser auditado, diga isso e registre os números em um arquivo, para que a próxima rodada possa ser comparada com esta.