TongyiDai/giants-shoulders: Hombros de Gigantes

Hombros de Gigantes (Giants' Shoulders)

"Si he visto más lejos es porque me paro sobre los hombros de gigantes." — Isaac Newton, 1675

Resumen

Antes de construir algo nuevo, averigua quién ya construyó algo similar. La mayoría de las ideas ya se han intentado: algunas resueltas bien, otras mal, algunas abandonadas por razones instructivas, unas pocas genuinamente abiertas. El objetivo no es copiar — es comenzar desde la frontera actual en lugar de una página en blanco: reutilizar enfoques comprobados, evitar callejones sin salida conocidos y ver claramente dónde la tarea realmente difiere de lo que ya existe.

Independiente del agente: funciona con cualquier agente que pueda buscar en la web (Claude Code, Codex, Cursor, TRAE u otros). Utiliza las herramientas de búsqueda web/fetch que proporcione el anfitrión. Ejecuta esto al inicio de la tarea, antes de diseñar o codificar, y mantenlo proporcionado — un escaneo breve, no una revisión bibliográfica.

Cuándo ejecutar vs. omitir

Ejecútalo cuando la tarea crea algo nuevo o elige un enfoque: construir una herramienta / script / biblioteca / CLI / habilidad / plugin / agente / flujo de trabajo / integración / prototipo / producto, diseñar una arquitectura, o elegir un framework, framework, biblioteca o algoritmo.

Omitelo para tareas triviales (traducir una línea, renombrar una variable, consultar la hora) o tareas sin trabajo previo externo (editar los propios archivos/datos privados del usuario). Si no estás seguro de si vale la pena, pregunta una frase: "¿Quieres que primero dedique un par de minutos a ver si ya existe una solución?"

Flujo de trabajo

1. Reformula el problema en una línea

Reduce la tarea al problema central, en términos simples — no la solución elegida por el usuario. Por ejemplo, "crea un script para deduplicar mi CSV" → problema central = "deduplicación de filas en datos tabulares". Si el planteamiento es tan amplio que coincide con una categoría completa de herramientas, haz exactamente una pregunta aclaratoria antes de buscar (ofrece hasta 3 dimensiones de ejemplo como indicaciones, no un cuestionario).

2. Genera un vocabulario antes de buscar

Diferentes comunidades usan diferentes palabras para lo mismo. Antes de ejecutar cualquier consulta, escribe 6–10 planteamientos del problema desde puntos de vista distintos, y asigna cada consulta de búsqueda a un planteamiento. Esto evita el modo de fallo más común: cinco consultas que todas aterrizan en el mismo vecindario semántico. Cubre al menos:

• Planteamiento del constructor — las propias palabras del usuario
• Planteamiento del usuario de la herramienta — lo que alguien que busca esto escribiría
• Planteamiento académico / de investigación — si aplica
• Planteamiento de infraestructura / implementación — el nombre técnico de bajo nivel
• Planteamiento de comunidad adyacente — la disciplina vecina que probablemente lo resolvió primero

Incluye al menos un planteamiento en inglés — la mayoría del trabajo previo y los repositorios se encuentran mejor en inglés.

3. Busca donde los constructores realmente publican

Utiliza las herramientas web del anfitrión (busca primero, luego recupera los resultados prometedores). Ejecuta 3–6 consultas dirigidas a través de distintos planteamientos y fuentes — no ejecutes una sola consulta genérica y te detengas.

Fuente	Qué encuentra	Cómo
Búsqueda web	Productos, comparativas, "mejor X para Y", publicaciones de blog	herramienta de búsqueda del anfitrión
Alojamientos de código	Implementaciones reales, bibliotecas, listas "awesome-*"	site:github.com <problema>, GitLab; gh search repos/code "<palabras clave>" si existe gh CLI
Registros de paquetes	Bibliotecas existentes	npm, PyPI, crates.io, pkg.go.dev, Hugging Face (ML)
Producto / comunidad	Productos lanzados, historias de fracasos	Product Hunt, Hacker News "Show HN", subreddits relevantes
Preguntas y respuestas / foros	Problemas, por qué fallan los enfoques	Stack Overflow, hilos de HN
Sitios de dominio	La forma canónica	documentación oficial, RFCs/estándares, arXiv, fichas de modelo

Prefiere fuentes primarias (repositorios, hilos de Show HN, páginas de inicio de proyectos) sobre listas de agregadores. Un repositorio de GitHub con 200 estrellas supera a una lista de Medium.

4. Rastrea una capa más abajo en cada coincidencia directa

Aquí es donde el escaneo falla más a menudo — al detenerse una capa demasiado pronto. Cuando la documentación de un proyecto dice "construido sobre X", "envuelve Y", "herramienta oficial para Z" o "se ejecuta a través de W", esa cosa nombrada suele ser el verdadero titular y el proyecto que encontraste es un envoltorio fino. Trata cada dependencia nombrada en una coincidencia directa como una pista de búsqueda: síguela con una consulta dedicada antes de concluir. No dejes que el primer proyecto (posiblemente pequeño) que encuentres ancle la respuesta.

5. Agrupa los hallazgos en cuatro categorías

No arrojes resultados en bruto. Agrúpalos:

• Coincidencias directas — mismo problema, mismo enfoque
• Soluciones adyacentes — mismo problema, enfoque diferente
• Soluciones parciales — resuelve un subconjunto
• Abandonados / desactualizados — existieron, ahora muertos (anota la fecha del último commit y, si es posible, por qué murió — eso suele ser el trabajo previo más instructivo)

6. Extrae los patrones estándar

A través de las coincidencias, ¿qué se repite? Arquitectura común, bibliotecas, decisiones de diseño, nombres, modelos de precios. Ese es el manual predeterminado sobre el que la tarea se basaría o competiría.

7. Compara el ángulo de la tarea — honestamente

En un párrafo, compara el planteamiento específico del usuario contra lo que existe. Nombra el verdadero diferenciador, o admite que no lo hay. No fabriques novedad para ser amable, y no inventes competidores para parecer minucioso.

8. Entrega un veredicto, luego continúa

Elige un veredicto y encabeza con él (consulta references/report-template.md para la estructura exacta de salida):

• Usar existente — ya resuelto bien; nombra la(s) mejor(es) opción(es)
• Bifurcar / extender — proyecto más cercano + específicamente qué añadir
• Contribuir — la funcionalidad pertenece aguas arriba; sugiere dónde
• Construirlo — brecha genuina; el diferenciador es claro y defendible
• Investigar primero — alguien lo intentó y lo abandonó; entender por qué antes de invertir tiempo

Luego pasa a la tarea real, informado por lo que encontraste. No te detengas para obtener aprobación a menos que un hallazgo cambie materialmente el alcance (por ejemplo, una herramienta madura ya hace exactamente esto) — en ese caso, menciona y pregunta.

Presupuesto y salvaguardas

• Limita el tiempo. Apunta a ≤10 consultas en total; detente antes si el panorama está claro después de 3–4 y al menos una rastreó una dependencia una capa más abajo (paso 4). Esto precede al trabajo real; no debe dominarlo.
• Informa con honestidad. "No se encontró trabajo previo directo" es un resultado válido y valioso — di dónde buscaste en lugar de rellenar con coincidencias débiles o competidores falsos.
• No recomiendes "construir" cuando exista algo bueno. Construir algo personalizado conlleva un costo de mantenimiento continuo que se subestima rutinariamente. Por defecto, usar/adaptar/contribuir a menos que nada encaje.
• Verifica el mantenimiento, no solo las estrellas. Commits recientes, respuesta a problemas, cadencia de lanzamientos y factor de riesgo revelan más que el conteo de estrellas. Una herramienta estable con 500 estrellas puede superar a una viral de 50k.
• Respeta las licencias. Anota la licencia de un proyecto al sugerir su reutilización.
• Cita fuentes. Cada elemento nombrado recibe un enlace para que los hallazgos sean verificables.
• ¿Sin red? Dilu, anota que el escaneo se omitió, recurre a lo que sepas — márcalo como derivado de memoria y posiblemente desactualizado — luego continúa.
• Sintetiza, no solo enumeres. El valor es la comparación (reutilización vs. brecha), no un montón de enlaces.

Archivos de referencia

• references/report-template.md — la estructura exacta de salida y un ejemplo trabajado. Léelo al redactar el informe.

Opcional: conviértelo en una regla predeterminada

Por defecto, esta habilidad se activa solo cuando su descripción coincide con la tarea. Para hacer que se ejecute automáticamente antes de cada tarea de construcción desde cero, añade una regla en el archivo de instrucciones del agente anfitrión. Ejecuta una vez (opt-in, idempotente, seguro de re-ejecutar):

scripts/install.sh

Pregunta si se quiere convertir Hombros de Gigantes en una regla predeterminada, y si es así, añade un bloque de reglas envuelto en marcadores al archivo de instrucciones del agente que encuentre (AGENTS.md para Codex/TRAE/Cursor, CLAUDE.md para Claude Code). Rechazar no escribe nada. Establece GIANTS_SHOULDERS_ASSUME_YES=1 para instalar de forma no interactiva.