Is There A?

Já Existe Algo Assim?

Por que isso existe

Para quase qualquer ideia, alguém já construiu uma versão dela. Isso não é uma má notícia — é a informação mais barata disponível. Mostra o que já está resolvido, o que é difícil, do que as pessoas reclamam e onde está a oportunidade real.

O erro caro não é construir algo que já existe. É gastar três semanas reconstruindo

• sem saber *, e descobrir quando você mostra a um amigo.

Duas coisas tornam isso digno de ser executado automaticamente, em vez de deixar para o usuário. Primeiro, a pessoa que mais precisa da verificação é aquela que nem pensa em perguntar — e muitas vezes não saberia como formular a busca se perguntasse. Segundo, os agentes são ajustados para executar: dado "quero construir X", o padrão é começar a construir X. Esta skill existe para inserir uma etapa barata antes desse reflexo.

Postura: conselheiro, não porteiro

• Ofereça a varredura, não a imponha. Uma linha, depois aja com base na resposta.
• "Isso existe" nunca é, por si só, um motivo para parar. A maioria dos bons produtos é o quinto concorrente.
• Nunca julgue se a ideia é original. Relate o que está por aí; deixe o usuário decidir.
• Se o usuário disser "pule", "apenas construa" ou mostrar impaciência — abandone imediatamente, observe que você pode verificar mais tarde e comece a construir. Não ofereça novamente na mesma sessão.
• Não encaminhe o usuário para produtos de pesquisa pagos ou serviços "para uma análise mais aprofundada, experimente X". Se eles quiserem mais do que uma varredura Padrão, diga a eles o que pesquisar por conta própria.

Quando acionar

Acione com base na intenção de construir — o usuário está descrevendo algo que pretende fazer. Isso não se limita a software:

• "Quero construir uma CLI que resuma meu histórico do git em um changelog semanal"
• "me ajude a especificar um aplicativo onde donos de cães encontrem babás nas proximidades"
• "pensando em uma extensão do Chrome que remova parâmetros de rastreamento de URLs"
• "Quero começar uma marca de café mastigável para pessoas que não têm tempo de preparar"
• "Quero projetar um painel de estacionamento que mostre aos motoristas onde há vagas livres"
• "Estou montando um serviço que ajuda idosos a digitalizar álbuns de fotos antigos"

Não acione para:

• Trabalho dentro de um projeto existente — correções de bugs, refatorações, novos recursos em algo já construído
• Exercícios de aprendizado onde construir você mesmo é o objetivo ("construa um roteador de brinquedo para eu entender")
• Scripts internos descartáveis sem superfície de produto
• Perguntas puramente criativas ou de execução: nomes, logotipos, esboços, maquetes, redação, conceitos de campanha, moodboards. "Projete um logotipo para minha marca de café" não é intenção de construir — é uma tarefa de design para algo já decidido. "Quero começar uma marca de café" é.
• Uma varredura já foi executada nesta sessão, ou o usuário recusou

A distinção importante: eles estão decidindo o que fazer, ou executando algo já decidido? Apenas o primeiro precisa disso.

Se o usuário está claramente no fluxo e só quer resultados, dê a ele os resultados e ofereça a varredura depois. Interromper o momento tem um custo real.

A abertura

Pergunte uma vez, de forma breve, com o custo visível para que o usuário possa escolher conscientemente:

Antes de construirmos — quer verificar o que já existe? Rápida (~2 min, ~50k tokens) ou Padrão (~10–15 min, ~200k tokens, relatório escrito). Rápida geralmente é o suficiente. Diga pular e eu vou direto para a construção — e me diga se há algo específico que você quer que eu procure.

Rápida é o padrão. Se o usuário disser sim sem escolher, execute Rápida. A varredura é naturalmente iterativa: uma varredura Rápida é barata e informa se uma análise aprofundada é justificada, e seus resultados dizem a uma varredura Padrão o que procurar. Ir direto ao fundo primeiro gasta tokens elaborando um cenário cuja forma já era óbvia.

Se o usuário mencionar algo específico que deseja ("verifique se alguém está fazendo isso na Europa", "eu me importo se é open source"), inclua como uma ênfase extra — mas mantenha a estrutura padrão e não deixe que uma solicitação estreite toda a varredura.

Modo	Orçamento	Saída
Rápida (padrão)	4–6 consultas, 2–3 verificações, ~2 min	Resumo no chat, nenhum arquivo
Padrão	8–12 consultas, 6–8 verificações, uma passagem de mineração de reclamações, ~10–15 min	Relatório escrito + breve resumo no chat

Etapa 1 — Escreva a especificação da varredura antes de pesquisar

Varreduras ruins vêm de pesquisar o nome do produto do usuário em vez de seu problema. Comprima a ideia em cinco linhas primeiro e mostre ao usuário, para que ele possa corrigi-lo:

IDÉIA:      uma frase, linguagem simples
TRABALHO:   o trabalho que o usuário do usuário está contratando isso para fazer
QUEM:       quem especificamente tem esse problema
MECANISMO:  o como — a abordagem técnica, física ou de serviço
VANTAGEM:   a restrição ou insight que o usuário acredita ser sua vantagem

A VANTAGEM é a mais importante — é o que você verifica com mais afinco. "Aplicativo de tarefas" é disputado; "aplicativo de tarefas que lê sua agenda e se recusa a deixar você se comprometer demais" pode não ser. Se o usuário não articulou uma vantagem, diga isso. Uma vantagem ausente é por si só uma descoberta digna de ser relatada antes que qualquer coisa seja construída.

Etapa 2 — Pesquise através da lacuna de nomenclatura

O maior modo de falha é pesquisar uma única formulação, não encontrar nada e declarar o campo vazio. Produtos que fazem a mesma coisa raramente usam as mesmas palavras. Gere consultas em quatro registros antes de pesquisar:

1. As palavras do usuário — como ele descreveu
2. As palavras do setor — o que um fornecedor neste espaço colocaria em uma página de preços ou pacote
3. As palavras do usuário do usuário — como uma pessoa frustrada pesquisaria o problema às 23h
4. A categoria adjacente — a categoria estabelecida na qual isso seria um recurso ou variante

Em seguida, pesquise as superfícies que correspondem ao tipo de coisa que está sendo construída — software, produto físico, marca ou serviço, todos vivem em lugares diferentes. references/search-playbook.md tem o mapa completo por tipo de produto, os padrões de consulta e como minerar reclamações e sinais de distribuição.

Duas regras que mantêm os resultados honestos:

• Resultados vazios significam consultas ruins até prova em contrário. Antes de escrever "nenhum concorrente direto", execute pelo menos mais dois registros e uma superfície diferente. Categorias verdadeiramente vazias existem, mas são raras, e alegar uma falsamente é a pior coisa que esta skill pode fazer.
• Verifique antes de listar. Abra a página, listagem ou repositório. Nunca liste algo apenas a partir de um trecho de pesquisa — projetos abandonados, produtos renomeados e listas geradas por IA parecem reais em trechos. Observe o último commit, último lançamento ou "última atualização" onde visível.

Sem acesso à web? Siga references/no-search-fallback.md — uma varredura útil ainda é possível a partir do conhecimento do modelo, mas deve ser rotulada como não verificada e terminar com as consultas que o usuário deve executar.

Etapa 3 — Classifique em quatro grupos nomeados

Use estes nomes, não números — níveis numerados deixam um buraco visível quando um está ausente, e um buraco parece dados perdidos.

• Acertos diretos — mesmo trabalho, mesmo usuário, mecanismo comparável
• Adjacentes — mesmo trabalho/usuário diferente, ou mesmo mecanismo/trabalho diferente. De onde vêm a maioria das ideias de diferenciação
• Componentes — bibliotecas, APIs, serviços, fornecedores, fabricantes que resolvem parte disso. Muitas vezes a maior parte da construção já está disponível
• Cemitério — repositórios abandonados, empresas fechadas, produtos descontinuados, recursos obsoletos. O grupo mais subestimado: um cemitério lhe diz o modo de falha e, às vezes, lhe diz que as condições facilitadoras mudaram desde então

Todo grupo recebe uma linha de status, sempre. Uma de:

• 3 encontrados (então as entradas)
• Nenhum encontrado — pesquisado, genuinamente vazio
• Não pesquisado nesta profundidade — pulado por orçamento

Um relatório que omite silenciosamente o que não verificou prejudica a única coisa que esta skill vende: que sua saída pode ser mais confiável do que a de um chat não estruturado. Nunca deixe o leitor adivinhar que tipo de ausência ele está vendo.

Etapa 4 — Mapeie a sobreposição honestamente

Para cada capacidade na ideia, marque já resolvido (nomeie quem), parcial (nomeie a limitação) ou em aberto. Seja específico — "Notion AI resume páginas, mas não pode agir em ferramentas externas" é útil; "Notion é parecido" não é.

Etapa 5 — Encontre lacunas a partir de evidências, não da imaginação

As lacunas devem ser atribuídas a algo que você realmente leu:

• Avaliações de 1–3 estrelas e tópicos de suporte nos acertos diretos — com o que as pessoas se frustram
• Problemas abertos ou solicitações de recursos com muitas reações, especialmente aquelas não respondidas há muito tempo
• Tópicos de fórum e comunidade onde alguém pergunta exatamente por isso e recebe respostas insatisfatórias
• Preços — quem está excluído, o que está atrás do nível mais alto
• Lacunas de cobertura — uma plataforma, uma região, um idioma, um segmento, um regime de conformidade

Cite de onde veio cada lacuna. Qualquer coisa que você está inferindo vai para uma lista separada de Hipóteses, claramente rotulada. Uma lacuna imaginada é pior do que nenhuma lacuna, porque parece validação.

O verdadeiro concorrente geralmente não é um produto. Antes de concluir que um espaço está vazio, pergunte o que as pessoas fazem hoje sem nenhuma ferramenta — um chat em grupo, uma planilha, uma conta no Instagram, uma transmissão no WhatsApp, um quadro de avisos perto da porta. Essa solução alternativa é o que deve ser superado, e geralmente o melhor movimento é conectar-se a ela em vez de substituí-la. Pedir que as pessoas adotem um novo destino é a maneira mais comum de essas ideias falharem silenciosamente.

Etapa 6 — Direções de diferenciação, depois um veredito

Ofereça 3–5 direções formuladas como posições, não recursos — "o que prioriza o local para dados que não podem sair do prédio", "o que posta no chat em grupo que as pessoas já usam", "gratuito para 90% dos casos, pago para equipes". Para cada uma, nomeie a evidência por trás dela e aproximadamente o que custa.

Observe onde está a distribuição. Para a maioria das ideias nessa escala, ser encontrado é mais difícil do que ser construído — então, se você notou como os players existentes conseguiram seus usuários (um diretório, um mercado, uma comunidade, uma parceria, ser um recurso dentro de algo maior), diga isso. Essa observação geralmente vale mais do que a análise de recursos.

Em seguida, chegue a um veredito, com raciocínio (rubrica em references/verdict-rubric.md):

• Construa — lacuna real, ou os incumbentes são fracos, adormecidos ou com preços incorretos
• Construa de forma mais restrita — a versão geral está ocupada; uma fatia específica não está
• Empacote — algo existente faz a parte difícil; o valor é a camada em cima
• Bifurque ou estenda — um projeto aberto está quase lá e permite isso
• Use o que existe — honestamente, o que eles querem já existe e funciona; diga uma vez, claramente, depois respeite a resposta deles se ainda quiserem construir
• Reformule — o cemitério sugere que essa formulação não funciona; aqui está a adjacente

Sempre anexe "o que mudaria minha opinião" — a coisa que o usuário sabe que você não sabe e que inverteria o veredito. O contexto deles geralmente supera a varredura.

Etapa 7 — Entregue, depois devolva a conversa

Rápida: resuma no chat. Nenhum arquivo, a menos que seja solicitado.

Padrão: escreva o relatório seguindo assets/LANDSCAPE-template.md, datado, listando quais superfícies foram pesquisadas e quais não foram. Salve como LANDSCAPE.md no diretório do projeto (ou docs/ se existir). Em seguida, dê um breve resumo no chat — a coisa existente mais próxima, a lacuna mais nítida, o veredito — e não repita o relatório.

Em seguida, ofereça os próximos passos como perguntas e aguarde. Não gere especificações, briefs ou painéis sem serem solicitados — o objetivo é devolver o controle ao usuário com melhores informações, não produzir mais documentos. Escolha dois ou três que se encaixem no que realmente aconteceu na varredura:

• "Pulei [superfícies] nesta execução — quer que eu as verifique?"
• "Quer pensar em brainstorming sobre o que construir, dado o que apareceu?"
• "Quer mergulhar em algum desses concorrentes a fundo?"
• "Quer que eu escreva o que encontramos como uma nota de transferência, para que você possa começar um novo chat com ela?"
• "Você precisa mostrar isso para alguém? Posso preparar para isso."
• "Pronto para construir? Sugiro começar com [a menor coisa que testa a vantagem]."

Se o usuário só quer construir, construa. A varredura serve a construção; não é a entrega.

Quanto isso custa e como carrega

Usuários novos em skills muitas vezes se preocupam que instalar isso torne cada conversa mais cara. Vale a pena explicar claramente se isso surgir:

• Apenas o nome e a descrição ficam no contexto permanentemente — aproximadamente 200 tokens, cerca de um parágrafo. Esse é o custo total de ter isso instalado em uma sessão onde nunca é acionado.
• Estas instruções (~2.500 tokens) carregam apenas quando a skill é acionada.
• Os arquivos de referência carregam apenas se a varredura realmente precisar deles.
• A varredura em si é o custo real: ~50k tokens para Rápida, ~150–300k para Padrão. É por isso que o modo é oferecido com números anexados, em vez de escolhido silenciosamente.

Arquivos de referência

• references/search-playbook.md — superfícies por tipo de produto (software, físico, marca, serviço), padrões de consulta, mineração de reclamações e distribuição
• references/verdict-rubric.md — escolha entre construir / mais restrito / empacotar / bifurcar / usar / reformular
• references/no-search-fallback.md — executando uma varredura honesta sem acesso à web
• assets/LANDSCAPE-template.md — a estrutura do relatório

Modos de falha a evitar

• Listagem lavada. Páginas "Top 10 ferramentas para X" são conteúdo SEO de afiliados, geralmente listando produtos mortos ou irrelevantes. Use-as para nomes candidatos, nunca como evidência.
• Inflação de grandes nomes. Listar Google, Amazon ou Notion como concorrentes de uma ideia de nicho é ruído. Inclua um incumbente apenas se uma coisa específica que eles fazem realmente se sobrepõe.
• Omissão silenciosa. Nunca apresente um grupo como ausente quando ele foi meramente não pesquisado. Veja a Etapa 3.
• Propagação da varredura. Esta é uma verificação pré-construção. Vinte minutos em uma varredura Padrão, pare e entregue.
• Desânimo por volume. Uma longa lista de concorrentes parece "não se preocupe" mesmo quando não é. Lidere com a lacuna e o veredito, não com a contagem.
• Desatualizado como ativo. Algo intocado por três anos é cemitério, não concorrência. Rotule-o.
• Desvio de referência. Não aponte os usuários para ferramentas de pesquisa pagas. Dê a eles as consultas.