Process Optimizer

Process Optimizer

Descrição

Recebe um problema medido em um processo e devolve o que mudar na configuração para atacá-lo: a mudança escrita como quem vai aplicá-la precisa ler, a evidência que a justifica, o teto do efeito que ela pode produzir, o que ela leva junto e como saber depois se funcionou.

Seis alavancas, e cada proposta usa uma só:

Esta skill não altera nada no Pipefy: nem fase, nem campo, nem prazo, nem automação, nem agente. A entrega é um plano de mudança, e aplicar é decisão e trabalho de quem é dono do processo, com o roteiro em references/handoff.md.

Ela também não mede. O diagnóstico vem da skill process-health, e sem ele não existe proposta: o passo 1 é ancorar, e é um portão, não uma formalidade. Proposta sem número que a sustente é catálogo de consultoria, não otimização deste pipe.

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

• Um diagnóstico apontou gargalo, retrabalho ou prazo decorativo e falta decidir o que mexer.
• O dono do processo quer enxugar formulário ou reduzir número de fases.
• Antes de contratar automação ou agente de IA, para escolher entre eles e para saber o que precisa existir antes.
• Depois de uma mudança, para propor a seguinte a partir do que ela mudou.

Para descobrir onde está o problema, use a process-health primeiro: esta aqui não procura, ela responde o que fazer com o que já foi encontrado. Para escrever como o processo funciona hoje, use a process-documenter. Para decidir o destino de um card, use a smart-router.

Referências

Este arquivo é o fluxo. O detalhe mora em references/, e cada arquivo é lido no passo que precisa dele, não antes.

Fluxo

1. Ancorar no diagnóstico. Leia references/collect.md. Se a process-health rodou nesta conversa, use os números dela e não recalcule nada. Se não rodou, ofereça rodar antes. Se o usuário trouxer o problema por conta própria ("o Comitê está travando"), aquilo é hipótese do usuário, entra rotulada como tal e não vira evidência.

2. Ler a superfície de mudança. Ainda em references/collect.md: fases, campos por fase e do formulário de entrada, prazos, automações com gatilho e estado, condições de campo, etiquetas, agentes e conexões com outros processos. Monte o mapa de dependência, que diz o que aponta para o que. Sem ele não se propõe remoção, porque remover é a única mudança que apaga dado de outra pessoa.

3. Desenhar as mudanças. Leia references/design.md. Uma alavanca por problema, evidência mínima cumprida, classe de reversibilidade declarada, teto de efeito em vez de promessa, e as guardas aplicadas à risca. A guarda que mais trabalha é a da alternativa mais barata: condição de campo resolve mais coisa que fase nova, e automação determinística resolve mais coisa que agente de IA.

4. Responder. Leia references/response.md. O plano em uma tabela, no máximo cinco mudanças, cada linha com evidência, teto de efeito e se dá para voltar atrás. Depois a tabela do que foi descartado, com o motivo. Máximo de 25 linhas: plano que não cabe na tela não é executado, é arquivado.

5. 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.

6. Entregar o roteiro, só se pedirem. Quando o usuário escolher detalhar uma mudança, leia references/handoff.md e escreva o roteiro daquela mudança só. Não escreva roteiro das cinco por iniciativa própria: quatro delas não vão ser aplicadas esta semana.

7. Publicar, só se pedirem. Nunca publique por iniciativa própria. 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 artefato nasce privado, e quem decide abrir é o usuário.

Governança

• Nenhuma alteração sai desta skill. A entrega é texto: plano e roteiro. Se o usuário pedir para aplicar, diga que a aplicação é dele, no Pipefy, com o roteiro na mão. Não chame ferramenta de escrita nem "para adiantar".
• Aposentar campo é a proposta mais perigosa daqui. Campo preenchido três vezes por ano pode ser exigência de auditoria, de contrato ou de LGPD, e a configuração não diz isso em lugar nenhum. A proposta é sempre "confirmar com o dono do processo antes de aposentar", nunca "remover", e a alternativa de esconder em vez de apagar vem escrita junto.
• Mudança de estrutura mexe em card que existe. Juntar, aposentar ou reordenar fase com cards dentro realoca trabalho de gente que está no meio dele. Toda proposta desse tipo declara quantos cards estão na fase agora e o que acontece com eles.
• Proposta não é ordem de serviço. Ela vai para alguém decidir, e por isso carrega a evidência visível: quem lê precisa poder discordar com argumento, e não apenas aprovar ou vetar.
• O histórico ensina o que foi feito, não o que era certo. Uma regra que existe nos dados há um ano pode ser um erro operando com consistência. Regra minerada entra na proposta com amostra e percentual à vista, para o dono poder dizer que aquilo está errado.
• Os valores dos campos passam pelo seu contexto quando você confere uso. Nunca transcreva valor de campo de card: conte presença e cardinalidade, e cite cards por ID. Valor só aparece quando ele é a própria regra proposta, como as opções de uma escolha única que vai condicionar um campo.
• Em pipe com dado sensível (folha de pagamento, saúde, jurídico de pessoa física), avise o usuário antes de conferir uso nos cards. A configuração sozinha não traz dado de pessoa.
• Nomes de pessoas não entram no plano. Fila concentrada em alguém é fato sobre capacidade da fase, e a proposta é sobre a fase.
• Processos que continuam em pipe conectado não são atravessados. Proposta que mexe em campo ou fase que alimenta outro processo declara a fronteira e diz que o efeito do outro lado não foi lido.
• Ao compartilhar o plano, confira se o público pode ver aquele processo. Plano de mudança circula mais que diagnóstico, e ele diz o que está mal configurado.

Critério de qualidade

O plano está pronto quando cada mudança traz a evidência que a sustenta, com número e origem; usa uma alavanca por problema; declara a classe de reversibilidade e, quando irreversível, o que o mapa de dependência encontrou apontando para o que vai sair; expressa efeito como teto e nunca como promessa; diz como verificar depois, com métrica e janela; não propõe nada sobre dimensão que o diagnóstico marcou como não medida; lista o que foi descartado e por quê; cabe em 25 linhas; não contém nenhum identificador interno de API; 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.

Devolver uma mudança só é um bom resultado. Cinco propostas competindo pela mesma semana produzem zero mudança aplicada, e a lista mais longa é a que tem mais chance de conter a proposta que ninguém checou.

O teste final de cada linha é o do pipe trocado: se a mudança faria sentido escrita para qualquer outro processo, ela não veio deste, veio do repertório, e sai do plano.