Seu usuário aponta na tela.Seu time resolve.
Cole uma linha no seu produto e um botão de feedback aparece. Bug, sugestão, interface ou dado errado: quem reporta clica no elemento, escreve o que aconteceu e envia. Você recebe o screenshot marcado, o seletor CSS, os erros de console e as requisições que falharam, e decide o que fazer com isso: triar no painel, mandar para o seu tracker, ou entregar ao seu agente pelo MCP.
Sem cartão de crédito. 20 vagas no beta; depois, lista de espera com desconto no lançamento.
O relato que chega hoje
Todo time que recebe feedback de usuário conhece essas frases. Elas custam uma ida e volta inteira só para descobrir onde olhar.
O que você recebe
- “não funciona”
- “deu erro na hora de finalizar”
- “seria bom ter um filtro aqui”
- “esse valor está errado”
O que o Clixy entrega
- Categoria
- Bug
- Elemento
- [data-clixy-id="finalizar-compra"]
- Página
- /carrinho
- Console
- TypeError: cannot read property total of undefined
- Rede
- POST /api/checkout devolveu 500 em 412ms
- Navegador
- Safari 18 no macOS, viewport 1440x900
Três passos
Do snippet ao commit, sem sair do que você já usa.
- 01
Cole uma linha
Funciona em qualquer site: React, Vue, Angular, Rails, WordPress. O widget não assume nada sobre o seu código e o estilo dele fica isolado em Shadow DOM, sem herdar nem vazar CSS.
<script src="https://app.clixy.app/w.js" data-key="pk_live_..." async></script> - 02
Seu usuário aponta e descreve
O botão abre um painel na língua de quem reporta. Ela escolhe a categoria, clica no elemento com problema e escreve o que aconteceu. O resto o widget coleta sozinho.
- 03
O relato vai para onde seu time trabalha
Chega no painel com tudo anexado, e dali segue por onde você preferir: triagem com situação, prioridade e responsável; issue no GitLab ou no GitHub, pela categoria e pela página; ou o seu agente lendo tudo pelo MCP. Os três caminhos convivem, e nenhum deles é obrigatório.
claude mcp add --transport http clixy https://app.clixy.app/mcp/ \ --header "Authorization: Bearer sk_live_..."
O que vem junto de cada relato
Nada disso é digitado por quem reporta. O widget coleta enquanto a pessoa usa o produto, e manda no mesmo pacote.
Screenshot com o ponto marcado
A captura sai recortada em volta do elemento apontado, com destaque nele. Campos de senha e o que você marcar com data-clixy-mask saem borrados.
Seletor CSS do elemento
Prioriza os atributos que você já usa: data-clixy-id, data-testid, id. É o que permite achar no código o componente reclamado.
Erros de console
Os ganchos entram no carregamento da página, não na hora do relato. O erro que explica o bug quase sempre acontece minutos antes de a pessoa decidir reclamar.
Requisições que falharam
Método, URL, status e duração de tudo que voltou 4xx, 5xx ou nem chegou a responder. Token na query string é removido antes de sair do navegador.
E o time trabalha nele ali mesmo
Situação, prioridade, responsável e comentários internos. Lista com filtros ou quadro para arrastar entre as situações, com papéis para quem entra por convite. Nada disso exige agente de IA: é o painel que o time usa no dia a dia.
O teste do seu time não vira reclamação de cliente
Todo feedback nasce sabendo de onde veio. O que o time reporta de localhost ou de homologação cai num contexto separado, com métricas próprias. O painel abre na produção: o relato de quem usa o produto de verdade.
Nada para configurar em localhost
Ligou as origens locais, o feedback de desenvolvimento já nasce classificado. Homologação você marca na origem cadastrada, e produção é o padrão de todo o resto.
Métricas que não mentem
Um bug testado dez vezes pelo QA não aparece como dez clientes insatisfeitos. Cada contexto conta só os seus, na lista, no quadro e nos números do topo.
O agente também separa
As tools do MCP filtram por ambiente e abrem em produção por padrão, porque é o relato que o seu agente deve priorizar. O do time fica a um parâmetro de distância.
O feedback vira issue onde o time já trabalha
Conecte o GitLab ou o GitHub e o relato abre uma issue com o contexto inteiro em markdown legível, não em bloco de JSON. Quem for corrigir lê o elemento apontado, o console e as requisições que falharam sem sair do repositório.
- GitLab
- GitHub
Mão dupla, de verdade
Fechou a issue no tracker, o feedback fecha aqui. Reabriu, ele reabre. O reflexo age pela transição e não pela situação atual, para o Clixy não reabrir a issue que o seu time fechou à mão.
Cada relato no repositório certo
A regra de destino decide pela categoria do relato, pelo caminho da página onde o problema apareceu, ou pelos dois. O bug do checkout vai para o repositório do checkout, a sugestão vai para o de ideias.
Sem apagar o trabalho do seu time
A escrita de labels parte do que a issue já tem: as que alguém aplicou à mão continuam lá. Toda issue criada leva um marcador do Clixy, para você achar depois tudo que saiu daqui.
Seu agente lê os feedbacks
O Clixy expõe um servidor MCP. Conecte Claude Code, Claude Desktop ou Cursor à sua conta e o agente passa a enxergar os relatos com todo o contexto técnico, sem você copiar e colar nada.
Lista os bugs de interface abertos dessa semana.
Três abertos. O mais citado é o botão de finalizar compra: quatro relatos, todos com TypeError no console apontando para total indefinido em /carrinho.
Corrige o primeiro.
O seletor é [data-clixy-id="finalizar-compra"]. Encontrei o componente em Checkout.tsx: o total é lido antes de o carrinho carregar. Ajustei e marquei o feedback como resolvido.
list_projectsOs projetos da conta, com a contagem de cada umlist_feedbackBusca por situação, ambiente, categoria, prioridade ou textoget_feedbackTraz elemento, console, rede e screenshotupdate_feedbackMuda situação e prioridadecomment_feedbackRegistra um comentário interno no relatofeedback_statsVolume por situação, categoria e página
Detalhes que importam
O widget roda dentro do seu produto. A gente trata isso com o cuidado que exige.
13,9 kB
no carregamento
É o que entra em toda visita, já comprimido. A biblioteca de captura de tela pesa mais que isso e só é buscada se alguém pedir uma captura.
Shadow DOM
isolamento total
Nem o CSS do seu site alcança o widget, nem o dele vaza para a sua página. Testado contra folha de estilo que reescreve todo botão do documento.
Sem IP
nada de dado pessoal
Quem reporta um bug não é usuário do Clixy e não consentiu com nada. Guardamos o hash do endereço para limitar abuso, nunca o endereço.
Origem fixa
a chave sozinha não basta
A chave pública fica visível no seu HTML, e isso é esperado. Quem autoriza o envio é a lista de origens que você cadastra, não o segredo dela.
Preço
Durante o beta, tudo liberado.
Beta
Grátis
enquanto durar o beta, para as 20 primeiras contas
- Projetos e feedbacks sem limite
- Screenshot, console e rede em todos os relatos
- Servidor MCP incluso
- Time com papéis e convites
- Painel em português e inglês
Vai existir plano pago quando o beta terminar. Quem entrar agora é avisado com antecedência e nada passa a ser cobrado sem você concordar antes. Depois das 20 vagas, quem se cadastra entra na lista de espera e ganha desconto no lançamento.
Perguntas
O widget deixa meu site mais lento?
Ele carrega de forma assíncrona e ocupa 13,9 kB comprimidos. A biblioteca de captura de tela, que é a parte pesada, só é baixada quando alguém aciona uma captura, então a maioria das visitas nunca paga esse custo.
E se alguém copiar minha chave pública do HTML?
A chave identifica o projeto, não autoriza o envio. Só as origens que você cadastra conseguem mandar feedback com ela, e requisição sem cabeçalho de origem é recusada. Há ainda limite de taxa por endereço e por projeto.
O screenshot captura dados sensíveis?
Campos de senha saem borrados automaticamente. Qualquer outro elemento sai borrado se você marcá-lo com data-clixy-mask, o que serve para dado que só você sabe que é sensível. A captura também pode ser desligada por projeto.
O Clixy serve só para bug?
Não. O projeto nasce com quatro categorias, bug, interface, dado errado e sugestão, e você troca as que quiser. Todas chegam com o mesmo contexto técnico e passam pela mesma triagem, e a categoria é um dos critérios que decidem para qual repositório a issue vai.
Preciso usar o MCP?
Não. O painel funciona sozinho: lista, quadro, triagem, prioridade, responsável e comentários. Dá também para mandar o relato ao GitLab ou ao GitHub sem agente nenhum no meio. O MCP é para quem já trabalha com agente e quer pular o copiar e colar.
Funciona com o meu framework?
O widget é uma tag script comum e não depende de framework algum. Se a sua página roda no navegador, ele roda nela.
Em que língua o widget aparece para quem reporta?
Na língua de quem está na tela, detectada pelo navegador, ou numa fixa que você escolhe por projeto. Ele não segue o idioma da sua conta, porque quem reporta pode estar em qualquer lugar.
Comece pelo primeiro projeto
Criar a conta, pegar a chave e colar o snippet leva menos tempo que ler esta página.
Criar conta grátis