TongyiDai/giants-shoulders

Ombro dos Gigantes (Giants' Shoulders)

"Se vi mais longe, foi por estar sobre os ombros de gigantes." — Isaac Newton, 1675

Visão geral

Antes de construir algo novo, descubra quem já construiu algo parecido. A maioria das ideias já foi testada: algumas bem resolvidas, outras mal resolvidas, algumas abandonadas por razões instrutivas, poucas genuinamente inexploradas. O objetivo não é copiar — é começar a partir da fronteira atual em vez de uma página em branco: reutilizar abordagens comprovadas, evitar becos sem saída conhecidos e enxergar claramente onde a tarefa realmente diverge do que já existe.

Independente de agente: funciona com qualquer agente que possa pesquisar na web (Claude Code, Codex, Cursor, TRAE ou outros). Use as ferramentas de pesquisa web/fetch que o anfitrião fornecer. Execute isso no início da tarefa, antes de projetar ou codificar, e mantenha a proporcionalidade — uma varredura rápida, não uma revisão bibliográfica.

Quando executar vs. pular

Execute quando a tarefa criar algo novo ou escolher uma abordagem: construir uma ferramenta / script / biblioteca / CLI / skill / plugin / agente / workflow / integração / protótipo / produto, projetar uma arquitetura ou escolher um framework, biblioteca ou algoritmo.

Pule para tarefas triviais (traduzir uma linha, renomear uma variável, verificar a hora) ou tarefas sem artefatos anteriores externos (editar arquivos/dados privados do usuário). Se não tiver certeza se vale a pena, pergunte em uma frase: "Quer que eu gaste um ou dois minutos para ver se já existe uma solução pronta?"

Fluxo de trabalho

1. Reformule o problema em uma linha

Reduza a tarefa ao problema central, em termos simples — não a solução escolhida pelo usuário. Ex.: "criar um script para deduplicar meu CSV" → problema central = "deduplicação de linhas em dados tabulares". Se o enquadramento for tão amplo que corresponda a uma categoria inteira de ferramentas, faça exatamente uma pergunta esclarecedora antes de pesquisar (ofereça até 3 dimensões de exemplo como sugestões, não um questionário).

2. Gere um vocabulário antes de pesquisar

Comunidades diferentes usam palavras diferentes para a mesma coisa. Antes de executar qualquer consulta, escreva 6 a 10 enquadramentos do problema de pontos de vista distintos e mapeie cada consulta de pesquisa para um enquadramento. Isso evita o modo de falha mais comum: cinco consultas todas chegando na mesma vizinhança semântica. Cubra pelo menos:

• Enquadramento do construtor — as próprias palavras do usuário
• Enquadramento do usuário da ferramenta — o que alguém pesquisando por isso digitaria
• Enquadramento acadêmico / de pesquisa — se aplicável
• Enquadramento de infraestrutura / implementação — o nome de baixo nível para isso
• Enquadramento de comunidade adjacente — a disciplina vizinha que provavelmente resolveu isso primeiro

Inclua pelo menos um enquadramento em inglês — a maior parte dos trabalhos anteriores e repositórios são encontrados melhor em inglês.

3. Pesquise onde os construtores realmente publicam

Use as ferramentas web do anfitrião (primeiro pesquise, depois busque os resultados promissores). Execute 3 a 6 consultas direcionadas em diferentes enquadramentos e fontes — não execute uma consulta genérica e pare.

Fonte	O que encontra	Como
Pesquisa web	Produtos, comparações, "melhor X para Y", postagens de blog	ferramenta de pesquisa do anfitrião
Repositórios de código	Implementações reais, bibliotecas, listas "awesome-*"	site:github.com <problema>, GitLab; gh search repos/code "<palavras-chave>" se a CLI gh existir
Registros de pacotes	Bibliotecas existentes	npm, PyPI, crates.io, pkg.go.dev, Hugging Face (ML)
Produto / comunidade	Produtos lançados, histórias de guerra	Product Hunt, Hacker News "Show HN", subreddits relevantes
Perguntas e respostas / fóruns	Armadilhas, por que abordagens falham	Stack Overflow, tópicos do HN
Ambientes de domínio	A forma canônica	documentação oficial, RFCs/padrões, arXiv, fichas de modelo

Prefira fontes primárias (repositórios, tópicos Show HN, páginas iniciais de projetos) em vez de listas de agregadores. Um repositório GitHub com 200 estrelas vale mais do que uma lista do Medium.

4. Rastreie uma camada abaixo em cada correspondência direta

É aqui que a varredura falha com mais frequência — parando uma camada cedo demais. Quando a documentação de um projeto disser "construído sobre X", "encapsula Y", "ferramenta oficial para Z" ou "executa por meio de W", essa coisa nomeada é frequentemente a verdadeira concorrente consolidada e o projeto que você encontrou é um invólucro fino. Trate cada dependência nomeada em uma correspondência direta como uma pista de pesquisa: siga-a com uma consulta dedicada antes de concluir. Não deixe que o primeiro projeto (possivelmente pequeno) que você encontrar ancore a resposta.

5. Agrupe os resultados em quatro categorias

Não despeje resultados brutos. Agrupe-os:

• Correspondências diretas — mesmo problema, mesma abordagem
• Soluções adjacentes — mesmo problema, abordagem diferente
• Soluções parciais — resolve um subconjunto
• Abandonadas / desatualizadas — existiu, agora morta (anote a data do último commit e, se possível, por que morreu — isso costuma ser o trabalho anterior mais instrutivo)

6. Extraia os padrões padrão

Através das correspondências, o que se repete? Arquitetura comum, bibliotecas, decisões de projeto, nomenclatura, modelos de preço. Esse é o manual padrão sobre o qual a tarefa estaria construindo ou com o qual estaria competindo.

7. Avalie o ângulo da tarefa — honestamente

Em um parágrafo, compare o enquadramento específico do usuário com o que existe. Nomeie o verdadeiro diferencial ou admita que não há um. Não invente novidade para ser agradável e não invente concorrentes para parecer completo.

8. Entregue um veredito, depois continue

Escolha um veredito e lidere com ele (veja references/report-template.md para o formato exato da saída):

• Usar existente — já bem resolvido; nomeie a(s) melhor(es) opção(ões)
• Bifurcar / estender — projeto mais próximo + especificamente o que adicionar
• Contribuir — o recurso pertence upstream; sugira onde
• Construir — lacuna genuína; o diferencial é claro e defensável
• Investigar primeiro — alguém tentou e abandonou; entenda o porquê antes de gastar tempo

Em seguida, passe para a tarefa real, informado pelo que você encontrou. Não pare para aprovação, a menos que uma descoberta mude materialmente o escopo (por exemplo, uma ferramenta madura já faz exatamente isso) — nesse caso, traga à tona e pergunte.

Orçamento e salvaguardas

• Limite de tempo. Mire em ≤10 consultas no total; pare antes se o cenário estiver claro após 3–4 e pelo menos uma tiver rastreado uma dependência uma camada abaixo (etapa 4). Isso antecede o trabalho real; não deve dominá-lo.
• Relate honestamente. "Nenhum trabalho anterior direto encontrado" é um resultado válido e valioso — diga onde procurou em vez de incluir correspondências fracas ou concorrentes falsos.
• Não recomende "construir" quando algo bom existir. Construir algo personalizado acarreta custo de manutenção contínua que é rotineiramente subestimado. O padrão é usar/adaptar/contribuir a menos que nada se encaixe.
• Verifique a manutenção, não apenas estrelas. Commits recentes, resposta a problemas, cadência de lançamentos e fator de risco revelam mais do que contagem de estrelas. Uma ferramenta estável com 500 estrelas pode vencer uma tendência com 50 mil.
• Respeite as licenças. Indique a licença de um projeto ao sugerir reutilização.
• Cite as fontes. Cada item nomeado recebe um link para que os resultados sejam verificáveis.
• Sem rede? Diga, observe que a varredura foi pulada, recorra ao que você sabe — sinalize como derivado da memória e possivelmente desatualizado — e prossiga.
• Sintetize, não apenas liste. O valor está na comparação (reutilização vs. lacuna), não em uma pilha de links.

Arquivos de referência

• references/report-template.md — a estrutura exata de saída e um exemplo prático. Leia ao compor o resumo.

Opcional: tornar uma regra padrão

Por padrão, esta skill é acionada apenas quando sua descrição corresponde à tarefa. Para fazê-la ser executada automaticamente antes de toda tarefa de construção do zero, adicione uma regra ao arquivo de instruções do agente anfitrião. Execute uma vez (opt-in, idempotente, seguro para reexecutar):

scripts/install.sh

Ele pergunta se deseja tornar Ombro dos Gigantes uma regra padrão e, se sim, anexa um bloco de regra delimitado por marcadores aos arquivos de instruções do agente que encontrar (AGENTS.md para Codex/TRAE/Cursor, CLAUDE.md para Claude Code). Recusar não escreve nada. Defina GIANTS_SHOULDERS_ASSUME_YES=1 para instalar de forma não interativa.