# Process Optimizer

> Propõe alterações concretas na configuração de um processo do Pipefy: juntar ou dividir fase, mexer em campo, calibrar prazo, ligar ou criar automação, condicionar campo e criar agente de IA. Cada proposta sai com a evidência que a sustenta, o teto do efeito que ela pode ter, o que ela quebra e como verificar depois. Não altera nada. Use quando pedirem para melhorar, otimizar, enxugar ou redesenhar um pipe, ou quando um diagnóstico já apontou o problema e falta decidir o que mudar. Gatilhos - 'como melhoro esse processo', 'o que eu mudo nesse pipe', 'esse processo tem fase demais', 'como enxugo esse formulário', 'o que automatizar aqui primeiro', 'já sei onde está o gargalo, e agora'.

- Skill: `maurivanluiz/process-optimizer` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add maurivanluiz/process-optimizer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/maurivanluiz/process-optimizer/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-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ó:

| Alavanca | O que muda |
|---|---|
| Fase | juntar, dividir, criar, reordenar ou aposentar fase |
| Campo | tornar obrigatório, tornar opcional, mudar de fase, aposentar |
| Prazo | configurar, calibrar pelo observado, remover prazo decorativo |
| Automação | ligar o que está desligado, criar, ajustar gatilho, desligar |
| Condição de campo | mostrar ou exigir campo conforme uma regra |
| Agente de IA | criar comportamento onde há texto humano recorrente |

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.

| Arquivo | Quando ler | O que tem |
|---|---|---|
| `references/collect.md` | antes do passo 1 | como ancorar no diagnóstico, o que ler da configuração, o mapa de dependência, o estado a manter, os portões |
| `references/design.md` | no passo 3 | as seis alavancas com a evidência mínima de cada uma, classes de reversibilidade, teto de efeito, as guardas e o que nunca propor |
| `references/response.md` | no passo 4 | formato das duas tabelas, linguagem, fechamento |
| `references/handoff.md` | só se o usuário pedir o roteiro | ordem de aplicação, o que checar antes, como voltar atrás, janela de verificação |
| `references/publish.md` | só se o usuário pedir para publicar | conteúdo da página, design system, composição, publicação |

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