maurivanluiz Process Mapper
Descrição
Lê a organização a partir de um ponto de partida e desenha o território: quais processos existem em volta, quais bancos de dados alimentam quais, onde entram os portais, onde os agentes de IA atuam, quais automações levam trabalho de um processo para outro e quanto trabalho realmente atravessa cada ligação.
A escala é o oposto da process-documenter. Ela desce dentro de um pipe e para
na fronteira dizendo que o trabalho continua do outro lado. Esta aqui começa
exatamente nessa fronteira e não olha para dentro de nenhuma fase.
Não é a tela de mapa do Pipefy com outro nome. Aquela mostra o que está ligado por conexão explícita. O que ela não mostra é onde esta skill ganha o direito de existir:
- Dependência por automação. Uma automação que abre card em outro processo é uma ligação real, e ela não aparece em desenho nenhum. É a dependência que quebra em produção sem ninguém saber que existia.
- Ligação que a lista de conexões não declara. Em pipe de produção, a lista devolveu uma ligação e os campos de conexão revelaram cinco, e a única declarada era a que estava parada. Mapa feito pela lista descreve o processo ao contrário.
- Volume na ligação. A tela mostra a contagem de vínculos do card aberto. Aqui a ligação é medida no processo inteiro: quantos cards passaram, e qual caminho carrega o trabalho de verdade.
- Ligação morta. Conexão configurada que nenhum card usou na janela. Custa manutenção e engana quem lê o desenho.
- Saída para fora do Pipefy. E-mail, chamada de sistema externo e integração por evento são pontas do processo, e elas somem de qualquer mapa que só olhe para pipes.
- Fronteira de acesso. Processo conectado que esta identidade não enxerga entra como nó fora de alcance, com contorno tracejado. Nunca some do desenho.
A entrega é visual por natureza, porque grafo descrito em prosa não é grafo. O terminal recebe a leitura e o artefato interativo recebe o mapa.
Esta skill lê. Não altera nada no Pipefy: nem conexão, nem automação, nem agente.
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
- Alguém chegou agora e não sabe onde o trabalho vive nem por onde ele passa.
- Antes de mexer em um pipe, para saber o que depende dele.
- Para achar dependência que ninguém lembra que criou, quase sempre automação.
- Para enxergar o processo ponta a ponta, quando ele atravessa várias áreas.
- Para limpar: conexão configurada que nenhum card usa, banco de dados órfão, portal que não leva a lugar nenhum.
Para o que acontece dentro de um pipe, fase por fase, use process-documenter.
Para gargalo, prazo e retrabalho, use process-health. Para julgar se uma
automação é segura, use automation-tester: aqui a automação é aresta do
desenho, e a skill não avalia o que ela faz.
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 | fronteira, inputs, consultas, o que vira nó e o que vira aresta, estado a manter |
references/trace.md |
no passo 4 | montagem do grafo, medição da ligação, limiares, guardas, achados |
references/response.md |
no passo 5 | leitura no terminal, tabelas, vocabulário, fechamento |
references/publish.md |
no passo 6 | o mapa interativo: layout, interação permitida, design, publicação |
Fluxo
1. Definir a fronteira. Leia references/collect.md. Ponto de partida e raio
em saltos, declarados antes de qualquer chamada. Sem raio, o grafo cresce até
virar borrão e a skill entrega um desenho bonito que ninguém lê.
2. Coletar os nós. Ainda em references/collect.md: processos, bancos de
dados, portais e agentes dentro da fronteira, em largura, um salto por vez.
3. Coletar as arestas, inclusive as invisíveis. A lista de conexões do processo é incompleta e não serve como fonte principal: os campos de conexão das fases e do formulário são. Some a isso as automações que abrem ou devolvem card em outro processo, os agentes com alcance fora do pipe, as saídas para fora do Pipefy e as entradas que só aparecem na amostra de cards. É aqui que o passo gasta o tempo, e é isto que a tela nativa não mostra.
4. Medir e traçar. Leia references/trace.md. Meça o trânsito de cada
ligação por amostra, classifique cada aresta em viva, prevista sem uso ou não
medida, ache ciclos, órfãos e nós fora de alcance, e calcule o layout em camadas
a partir da entrada.
5. Responder. Leia references/response.md. Caminho principal em uma linha,
tabela de nós, tabela de ligações e tabela de achados. Nenhum vocabulário de API
na tela.
6. Publicar o mapa. Leia references/publish.md, use a ferramenta Artifact
e entregue o link. Diferente das outras skills do repo, aqui a publicação é a
entrega esperada, e não um extra: a tabela de ligações é conferência, o mapa é o
que responde a pergunta. Ainda assim ela é oferecida e confirmada, nunca feita
por iniciativa própria, porque este artefato mostra a estrutura inteira da
organização em uma página, que é o material mais sensível que este repo produz.
7. Perguntar o que vem depois, de forma interativa. Feche com a ferramenta de
pergunta interativa do ambiente (AskUserQuestion no Claude Code), com as opções
da seção "Fechamento" de references/response.md.
Governança
- Nada de vocabulário de API na tela, em nenhum momento. Vale para o mapa,
para a resposta e para o relato de progresso durante a coleta. Em vez de
"chamando get_pipe_relations", escreva "lendo as conexões entre os processos".
A lista do que nunca aparece está em
references/response.md. - Aresta afirmada exige fonte. Toda ligação do desenho carrega de onde veio: conexão configurada, automação, agente, portal ou integração. Ligação que só existe na cabeça de quem opera não entra no mapa.
- Nó é processo, aresta é volume. Nenhum nome de pessoa, nenhum título de card, nenhum valor de campo aparece no mapa. Papel e pessoa não são nós, e a tentação de colocá-los é o que transforma o desenho em ilegível.
- Volume é amostrado, e o mapa diz isso. O número na aresta é o que foi visto na janela, nunca o total histórico, e nunca vira percentual de um todo que não foi contado.
- Visibilidade parcial vem antes de qualquer conclusão. Se esta identidade não enxerga um processo vizinho, ele entra como fora de alcance e nenhuma afirmação de desuso se sustenta em volta dele. Mapa incompleto que parece completo é o pior artefato que esta skill pode produzir.
- Ciclo é achado, não erro. Dois processos que se alimentam podem ser retrabalho ou podem ser o desenho certo. A skill mostra e não julga.
- Nenhuma alteração no Pipefy sai daqui, nem remover conexão morta, nem
desligar automação. Ligação morta é achado; transformar achado em proposta é a
process-optimizer, e ligar ou desligar é de quem assina. - Antes de publicar, lembre em uma linha que a página desenha a estrutura de todos os processos do alcance, e que quem recebe o link vê o território inteiro, mesmo sem ter acesso aos pipes.
Critério de qualidade
O mapa está pronto quando declara a data da leitura, o ponto de partida e o raio; mostra todo nó alcançado, inclusive os fora de alcance; distingue por forma, e não só por cor, a ligação por conexão da ligação por automação; separa ligação viva de ligação prevista sem uso, com o número que sustenta a diferença; nomeia as saídas para fora do Pipefy; marca os ciclos sem chamá-los de erro; cabe em uma tela sem rolagem lateral do corpo da página; não contém nenhum identificador interno de API nem nome de ferramenta; e termina em uma única próxima ação.
A régua de legibilidade é esta, e ela vale mais que cobertura: dá para achar o caminho de um tipo de trabalho em dez segundos. Se não dá, reduza o raio e agrupe, em vez de entregar todos os nós.
Antes de entregar, releia procurando underscore e inglês técnico. Achou algum fora de bloco de código, traduza.