CommunityPesquisa e Análise de Dadosgithub.com

sakzgupzzz/idea-check

Valide uma ideia de produto ou startup de ponta a ponta e retorne um relatório de panorama baseado em pesquisa, abrangendo arte anterior, concorrentes adjacentes, o cemitério de tentativas fracassadas, a economia do comprador e o piso de commodity.

O que é idea-check?

O skill idea-check automatiza a validação rigorosa de ideias de produtos ou startups, gerando um relatório de panorama baseado em evidências. Ele é acionado sempre que um usuário pergunta se uma ideia já existe, se alguém já construiu algo semelhante, ou solicita uma análise de concorrência, arte anterior ou mercado. Em vez de dar um veredito simples de 'funciona ou não', o skill fornece evidências estruturadas e as condições sob as quais a ideia sobrevive, ajudando a evitar vieses de confirmação. O skill é compatível com plataformas de agentes de IA como Claude Code, Cursor e Codex, e executa quatro pesquisas paralelas em tópicos específicos: arte anterior (produtos, repositórios, patentes), concorrentes adjacentes (categorias que já resolvem o problema como recurso), cemitério e economia (fracassos anteriores, disposição a pagar) e piso de commodity (o que já é gratuito). Após a coleta, o skill realiza três leituras independentes do panorama para classificar o espaço como Aberto, Concorrido ou Saturado, e gera um relatório final em markdown com seções detalhadas, incluindo fontes e fontes descartadas.

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/sakzgupzzz/idea-check/tree/HEAD

Installed? Explore more Pesquisa e Análise de Dados skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

O que idea-check faz?

Pesquise uma ideia de ponta a ponta e retorne um relatório de panorama. Não retorne um veredito sobre se a ideia vai funcionar. Retorne evidências e as condições sob as quais a ideia sobrevive.

Antes de iniciar

Reafirme a ideia em um parágrafo conforme você a entendeu e informe ao usuário que você está iniciando a pesquisa. Não aguarde confirmação; a reafirmação também vai para o relatório, para que o usuário possa perceber um erro de interpretação de qualquer forma. Faça uma pergunta primeiro apenas se a ambiguidade mudar qual mercado você pesquisaria (por exemplo, "IA para advogados" pode significar revisão de contratos ou descoberta de litígios, e esses têm concorrentes e cemitérios diferentes).

Escolha o tipo de entidade: produto de software, produto de hardware, serviço, direção de pesquisa ou conteúdo. Isso muda quais fontes são importantes. Software depende de registros de pacotes e GitHub; hardware depende de patentes; serviços dependem de dados de mercado local e trabalho; pesquisa depende de artigos e pré-prints.

Em seguida, verifique execuções anteriores. Liste checks/ no diretório do skill e leia o front matter de qualquer arquivo cujo assunto pareça relacionado. Se uma verificação anterior cobrir terreno sobreposto, diga isso antecipadamente e nomeie o arquivo, então decida com o usuário se deve realizar uma nova pesquisa ou estender o relatório anterior. Repetir uma verificação que você já executou é o desperdício mais comum neste fluxo de trabalho.

Crie um diretório de notas no scratchpad para esta execução. Cada thread escreve suas descobertas lá, para que a síntese funcione a partir de arquivos, não da memória de quatro longas respostas de subagentes.

As quatro threads

Lance todas as quatro como subagentes paralelos em uma única mensagem, usando a ferramenta Agente com o tipo de propósito geral. Cada thread precisa de pesquisa na web e fetch. A decomposição é fixa. Não substitua pela sua própria, mescle threads ou adicione uma quinta. O prompt completo para cada thread está em references/thread-prompts.md; leia esse arquivo e use os modelos conforme escritos, substituindo a ideia, o tipo de entidade e o caminho das notas.

1. Arte anterior

Quem já entrega isso. Produtos comerciais com preços publicados, repositórios GitHub com estrelas, licença e data do último commit, trabalhos acadêmicos, patentes. Para cada ocupante, indique o quão próximo está da ideia e o que não cobre. As lacunas são mais úteis do que a lista.

2. Concorrentes adjacentes

Quais categorias estabelecidas já resolvem isso como um recurso, e quem absorveria se funcionasse. Isso é mais importante do que concorrentes diretos. Produtos neste espaço morrem com mais frequência para um incumbente agrupando o recurso de cima do que para uma startup competindo de frente. Nomeie o absorbedor mais provável.

3. Cemitério e economia

O que já foi tentado aqui e falhou: encerramentos, aquisições de baixo valor, pivôs, demissões, declínio em empresas públicas adjacentes. Em seguida, quem é o comprador, o que eles realmente pagam e se esse segmento pode pagar. Seja adversarial em relação ao caso de negócio. Uma thread instruída a encontrar concorrentes nunca encontrará o cemitério, e é por isso que isso é separado.

4. Piso de commodity

Quanto disso já é gratuito ou agrupado: capacidades de modelos de fronteira, código aberto, recursos dentro de assinaturas que o usuário já possui. Se um modelo competente com pesquisa na web fizer 80% disso de graça, diga isso e nomeie o delta restante, porque o delta é a única coisa vendável.

Instruções obrigatórias para subagentes

Todo prompt de thread deve incluir este bloco literalmente. Já está nos modelos; não o corte ao substituir.

  • "Assuma que arte anterior existe e caçe por ela. Seu trabalho é encontrar quem ocupa este espaço, não confirmar que está vazio. Relate quem ocupa este espaço, de forma direta."
  • "Onde você não encontrar nada, escreva 'nada encontrado, o que não é o mesmo que ausente' e liste o que você não verificou."
  • "Toda afirmação factual precisa de uma URL de fonte."
  • "Exclua listículos gerados por IA, páginas de resumo 'melhores ferramentas 2026', sites de preços programáticos e vendedores de dimensionamento de mercado sindicados de todas as afirmações factuais. Nomeie as fontes que você descartou. Aproximadamente um terço dos resultados de pesquisa neste domínio são fornecedores escrevendo SEO uns sobre os outros; relate esse volume como uma descoberta, mas não o cite."
  • "Distinga reivindicações de fornecedores de evidências independentes em cada descoberta."

A primeira linha é a linha de maior valor neste skill. Enquadrar uma tarefa de pesquisa em direção à confirmação em vez da falsificação desloca as conclusões em 34 a 66 pontos percentuais em medições publicadas. Isso torna o enquadramento um requisito de correção, não uma preferência de tom. Uma thread instruída a verificar se um espaço está vazio relatará que está vazio.

A frase "nada encontrado" existe porque a ausência de evidência é fraca aqui. Tanto pequenos concorrentes quanto empresas falidas são mal indexados. Listar o que não foi verificado permite que o leitor julgue o quanto o silêncio significa.

Síntese

Quando todas as quatro threads retornarem, leia seus arquivos de notas. Em seguida, faça duas coisas.

Três leituras independentes do panorama

Rotule o panorama como Aberto, Concorrido ou Saturado. Produza esse rótulo três vezes de forma independente e mantenha as leituras realmente independentes: lance três subagentes paralelos, cada um recebendo apenas os quatro arquivos de notas e as definições de rótulo abaixo, cada um solicitado a dar um rótulo e no máximo três frases de raciocínio. Não dê a eles a saída um do outro ou seu próprio rascunho. Não produza o rótulo você mesmo em seu próprio contexto e depois o "re-derive", porque uma segunda leitura no mesmo contexto está ancorada na primeira.

Definições a passar para cada leitor:

  • Aberto: nenhum ocupante cobre o núcleo da ideia; o piso de commodity deixa um delta real; o cemitério está vazio ou falhou por razões que não se aplicam mais.
  • Concorrido: vários ocupantes cobrem a maior parte; existe uma brecha, mas os incumbentes estão próximos; a economia é plausível para um segmento restrito.
  • Saturado: ocupantes diretos com preços publicados, um incumbente já agrupando ou um cemitério mostrando que o segmento não pode pagar.

Relate todos os três rótulos e mostre qualquer discordância. Não faça média e não escolha um vencedor por maioria na prosa; deixe o leitor ver a divisão. Verdictos de novidade avaliados oscilam de 93,5 a 40,9 por cento de precisão apenas com a reformulação do prompt, e uma votação de três chamadas superou ferramentas de passagem única construídas para esse fim que custam doze vezes mais. A discordância entre as leituras é a linha mais informativa do relatório.

Sem camada de crítico

Não adicione um agente crítico, de red team ou de debate sobre a síntese. Resultados publicados mostram que o debate multiagente tem desempenho inferior a uma única passagem forte e degrada a precisão na maioria das configurações testadas. Uma síntese cuidadosa a partir dos arquivos de notas supera um comitê.

Saída

Três destinos, nesta ordem. O arquivo é a entrega; a conversa recebe um resumo apenas.

1. O arquivo de relatório, sempre

Escreva o relatório completo em checks/YYYY-MM-DD-<slug>.md no diretório do skill, onde <slug> é um nome curto em kebab-case para a ideia. Crie checks/ se não existir. Comece o arquivo com front matter YAML para que execuções posteriores possam corresponder a ele sem ler o relatório inteiro:

---
idea: declaração da ideia em uma linha
slug: nome-em-kebab-case
date: YYYY-MM-DD
label: Aberto | Concorrido | Saturado
label_reads: [leitura1, leitura2, leitura3]
top_occupants: [nome1, nome2, nome3]
---

Quando as três leituras discordarem, defina label como aquele que aparece com mais frequência, ou como Dividido se todos os três forem diferentes. O front matter é uma chave de consulta; o corpo é onde a discordância é mostrada.

Corpo: markdown, com menos de 1.200 palavras. Prosa por padrão, tabelas apenas onde a comparação for genuinamente necessária (por exemplo, vários ocupantes com preços). Sem travessões. Seções nesta ordem, com estes cabeçalhos:

  1. A ideia, como entendida. Um parágrafo. O usuário verifica isso primeiro.
  2. Quem já está lá. Nomeados, com URLs, preços onde publicados e o quão próximos cada um está da ideia. Marque reivindicações de fornecedores como tal.
  3. O cemitério. O que falhou e por quê.
  4. A economia. Quem paga, quanto e se o segmento pode pagar.
  5. O piso de commodity. O que já é gratuito ou agrupado.
  6. Rótulo do panorama. Todas as três leituras, com qualquer discordância mostrada.
  7. O que teria que ser verdade. As condições específicas sob as quais a ideia sobrevive e, para cada uma, qual evidência a resolveria. Marque qualquer condição que a pesquisa já tenha falsificado.
  8. Fontes e fontes descartadas. Cada URL citada, em seguida, as fontes descartadas de todas as quatro threads com uma razão de uma frase cada.

2. O resumo da conversa, sempre

Imprima no máximo 150 palavras: o rótulo do panorama e se as três leituras concordaram, os dois ou três ocupantes mais próximos, a descoberta mais decisiva e o caminho para o arquivo de relatório. Ninguém lê 1.200 palavras em um terminal.

3. Uma página compartilhável, apenas se disponível

Se uma ferramenta para publicar um artefato ou página existir na sessão, publique também o relatório como uma página e dê ao usuário o link. Trate isso como opcional. Nunca falhe a execução e nunca retenha o arquivo ou o resumo, porque esta ferramenta está ausente. Está ausente em muitas sessões do Claude Code, que é onde este skill é geralmente instalado.

Limitações conhecidas

Declare-as no relatório quando se aplicarem.

  • Ausência de evidência é evidência fraca aqui. Pequenos concorrentes e empresas falidas são ambos mal indexados.
  • Preços para ferramentas empresariais geralmente são fechados em vendas e indisponíveis.
  • Volume de resultados de pesquisa não é evidência de tamanho de mercado; grande parte são fornecedores escrevendo uns sobre os outros.
  • O relatório diz se um espaço está ocupado. Não diz se este usuário pode vencer, o que depende de informações que a pesquisa não pode ver.

Habilidades Relacionadas