巨人之肩 / Giants' Shoulders

巨人之肩 (Giants' Shoulders)

« Si j'ai vu plus loin, c'est en montant sur les épaules de géants. » — Isaac Newton, 1675

Vue d'ensemble

Avant de construire quelque chose de nouveau, découvrez qui a déjà construit quelque chose de similaire. La plupart des idées ont déjà été essayées : certaines bien résolues, certaines mal résolues, certaines abandonnées pour des raisons instructives, et quelques-unes véritablement ouvertes. L'objectif n'est pas de copier — c'est de partir de la frontière actuelle plutôt que d'une page blanche : réutiliser les approches éprouvées, éviter les impasses connues, et voir clairement où la tâche diverge réellement de ce qui existe.

Indépendant de l'agent : fonctionne avec tout agent capable de chercher sur le web (Claude Code, Codex, Cursor, TRAE ou autres). Utilisez les outils de recherche web / récupération fournis par l'hôte. Exécutez cette compétence au début de la tâche, avant de concevoir ou de coder, et gardez-la proportionnée — un court scan, pas une revue de littérature.

Quand l'exécuter vs. l'ignorer

Exécutez-la quand la tâche crée quelque chose de nouveau ou choisit une approche : construire un outil / script / bibliothèque / CLI / compétence / plugin / agent / workflow / intégration / prototype / produit, concevoir une architecture, ou choisir un framework, une bibliothèque ou un algorithme.

Ignorez-la pour les tâches triviales (traduire une ligne, renommer une variable, vérifier l'heure) ou les tâches sans antériorité externe (modifier les fichiers/données privés de l'utilisateur). Si vous n'êtes pas sûr que cela en vaille la peine, demandez en une phrase : « Dois-je d'abord consacrer une ou deux minutes pour voir s'il existe une solution existante ? »

Workflow

1. Reformulez le problème en une ligne

Réduisez la tâche au problème central, en termes simples — pas la solution choisie par l'utilisateur. Par exemple, « construire un script pour dédupliquer mon CSV » → problème central = « déduplication de lignes dans des données tabulaires ». Si le cadrage est si large qu'il correspond à une catégorie entière d'outils, posez exactement une question de clarification avant de chercher (proposez jusqu'à 3 dimensions d'exemple comme suggestions, pas un questionnaire).

2. Générez un vocabulaire avant de chercher

Différentes communautés utilisent des mots différents pour la même chose. Avant d'exécuter une requête, écrivez 6 à 10 cadrages du problème depuis des points de vue distincts, et associez chaque requête de recherche à un cadrage. Cela évite le mode d'échec le plus courant : cinq requêtes atterrissant toutes dans le même voisinage sémantique. Couvrez au moins :

• Cadrage du constructeur — les propres mots de l'utilisateur
• Cadrage de l'utilisateur de l'outil — ce que quelqu'un cherchant cela taperait
• Cadrage académique / recherche — si applicable
• Cadrage infrastructure / implémentation — le nom de bas niveau pour cela
• Cadrage d'une communauté adjacente — la discipline voisine qui l'a probablement résolu en premier

Incluez au moins un cadrage en anglais — la plupart des antériorités et des dépôts se révèlent mieux en anglais.

3. Cherchez là où les constructeurs publient réellement

Utilisez les outils web de l'hôte (cherchez d'abord, puis récupérez les résultats prometteurs). Exécutez 3 à 6 requêtes ciblées sur différents cadrages et sources — n'exécutez pas une seule requête générique et arrêtez-vous.

Source	Ce qu'elle trouve	Comment
Recherche web	Produits, comparatifs, « meilleur X pour Y », articles de blog	outil de recherche de l'hôte
Hébergeurs de code	Implémentations réelles, bibliothèques, listes « awesome-* »	site:github.com <problème>, GitLab ; gh search repos/code "<mots-clés>" si l'interface gh existe
Registres de paquets	Bibliothèques existantes	npm, PyPI, crates.io, pkg.go.dev, Hugging Face (ML)
Produit / communauté	Produits lancés, retours d'expérience	Product Hunt, Hacker News « Show HN », subreddits pertinents
Q&A / forums	Pièges, raisons d'échec des approches	Stack Overflow, fils HN
Sites de référence	La manière canonique	docs officielles, RFCs/normes, arXiv, fiches de modèles

Privilégiez les sources primaires (dépôts, fils Show HN, pages d'accueil de projets) aux articles de listes agrégatrices. Un dépôt GitHub avec 200 étoiles bat un article de liste Medium.

4. Descendez d'un niveau sur chaque correspondance directe

C'est là que l'analyse échoue le plus souvent — en s'arrêtant un niveau trop tôt. Quand la documentation d'un projet dit « construit sur X », « enveloppe Y », « harnais officiel pour Z » ou « fonctionne via W », cette chose nommée est souvent le véritable prédécesseur et le projet que vous avez trouvé n'est qu'une fine couche. Traitez chaque dépendance nommée dans une correspondance directe comme une piste de recherche : suivez-la avec une requête dédiée avant de conclure. Ne laissez pas le premier projet (peut-être minuscule) que vous trouvez ancrer la réponse.

5. Regroupez les résultats en quatre catégories

Ne déversez pas les résultats bruts. Regroupez-les :

• Correspondances directes — même problème, même approche
• Solutions adjacentes — même problème, approche différente
• Solutions partielles — résout un sous-ensemble
• Abandonnées / obsolètes — existaient, maintenant mortes (notez la date du dernier commit et, si trouvable, pourquoi c'est mort — c'est souvent l'antériorité la plus instructive)

6. Extrayez les modèles standards

À travers les correspondances, qu'est-ce qui revient ? Architecture commune, bibliothèques, décisions de conception, nommage, modèles de tarification. C'est le playbook par défaut sur lequel la tâche serait construite ou en concurrence.

7. Évaluez l'angle de la tâche — honnêtement

En un paragraphe, comparez le cadrage spécifique de l'utilisateur avec ce qui existe. Nommez le véritable différenciateur, ou admettez qu'il n'y en a pas. N'inventez pas de nouveauté pour être gentil, et n'inventez pas de concurrents pour paraître exhaustif.

8. Rendez un verdict, puis continuez

Choisissez un verdict et commencez par lui (voir references/report-template.md pour la structure exacte de sortie) :

• Utiliser l'existant — déjà bien résolu ; nommez la/les meilleure(s) option(s)
• Forker / étendre — projet le plus proche + spécifiquement ce qu'il faut ajouter
• Contribuer — la fonctionnalité appartient en amont ; suggérez où
• Construire — véritable lacune ; le différenciateur est clair et défendable
• Investiguer d'abord — quelqu'un a essayé et abandonné ; comprenez pourquoi avant d'y passer du temps

Transmettez ensuite à la tâche réelle, informé par ce que vous avez trouvé. Ne vous arrêtez pas pour approbation à moins qu'une découverte ne modifie matériellement le périmètre (par exemple, un outil mature fait déjà exactement cela) — dans ce cas, signalez-le et demandez.

Budget & garde-fous

• Limitez dans le temps. Visez ≤10 requêtes au total ; arrêtez plus tôt si le paysage est clair après 3–4 et qu'au moins une a tracé une dépendance d'un niveau plus bas (étape 4). Cela précède le vrai travail ; cela ne doit pas le dominer.
• Rapportez honnêtement. « Aucune antériorité directe trouvée » est un résultat valide et précieux — dites où vous avez cherché plutôt que de gonfler avec des correspondances faibles ou de faux concurrents.
• Ne recommandez pas de « construire » quand quelque chose de bien existe. Construire sur mesure entraîne un coût de maintenance continu qui est régulièrement sous-estimé. Par défaut, privilégiez utiliser/adapter/contribuer à moins que rien ne convienne.
• Vérifiez la maintenance, pas seulement les étoiles. Les commits récents, la réponse aux problèmes, le rythme des versions et le bus factor en disent plus que le nombre d'étoiles. Un outil stable avec 500 étoiles peut battre un outil tendance avec 50 000.
• Respectez les licences. Notez la licence d'un projet lorsque vous suggérez une réutilisation.
• Citez les sources. Chaque élément nommé reçoit un lien pour que les résultats soient vérifiables.
• Pas de réseau ? Dites-le, notez que l'analyse a été ignorée, revenez à ce que vous savez — signalez-le comme dérivé de la mémoire et potentiellement obsolète — puis continuez.
• Synthétisez, ne listez pas seulement. La valeur est la comparaison (réutilisation vs. lacune), pas un tas de liens.

Fichiers de référence

• references/report-template.md — la structure exacte de sortie et un exemple complet. Lisez-le lors de la rédaction du briefing.

Optionnel : en faire une règle par défaut

Par défaut, cette compétence se déclenche uniquement lorsque sa description correspond à la tâche. Pour l'exécuter automatiquement avant chaque tâche de construction à partir de zéro, ajoutez une règle au fichier d'instructions de l'agent hôte. Exécutez une fois (opt-in, idempotent, sûr à ré-exécuter) :

scripts/install.sh

Il demande si vous souhaitez faire de Giants' Shoulders une règle par défaut, et si oui, ajoute un bloc de règles délimité par un marqueur aux fichiers d'instructions de l'agent qu'il trouve (AGENTS.md pour Codex/TRAE/Cursor, CLAUDE.md pour Claude Code). Refuser n'écrit rien. Définissez GIANTS_SHOULDERS_ASSUME_YES=1 pour installer de manière non interactive.