/search-first — Recherche avant de coder
Systématise le workflow « rechercher des solutions existantes avant d'implémenter ».
Déclencheur
Utilisez ce skill quand :
- Vous commencez une nouvelle fonctionnalité qui a probablement des solutions existantes
- Vous ajoutez une dépendance ou une intégration
- L'utilisateur demande « ajouter la fonctionnalité X » et vous êtes sur le point d'écrire du code
- Avant de créer un nouvel utilitaire, helper ou abstraction
Workflow
┌─────────────────────────────────────────────┐
│ 0. PRÉVOL DISPONIBILITÉ DES OUTILS │
│ Vérifier les canaux de recherche avant │
│ de s'y fier ; signaler honnêtement les │
│ canaux ignorés │
├─────────────────────────────────────────────┤
│ 1. ANALYSE DU BESOIN │
│ Définir la fonctionnalité nécessaire │
│ Identifier les contraintes langage/fw │
├─────────────────────────────────────────────┤
│ 2. RECHERCHE PARALLÈLE (agent chercheur) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ npm / │ │ MCP / │ │ GitHub / │ │
│ │ PyPI │ │ Skills │ │ Web │ │
│ └──────────┘ └──────────┘ └──────────┘ │
├─────────────────────────────────────────────┤
│ 3. ÉVALUER │
│ Noter les candidats (fonctionnalité, │
│ maintenance, communauté, docs, licence, │
│ dépendances) │
├─────────────────────────────────────────────┤
│ 4. DÉCIDER │
│ ┌─────────┐ ┌──────────┐ ┌─────────┐ │
│ │ Adopter│ │ Étendre │ │ Créer │ │
│ │ tel quel│ │ /Encapsuler│ │ sur ││ │
│ └─────────┘ └──────────┘ └─────────┘ │
├─────────────────────────────────────────────┤
│ 5. IMPLÉMENTER │
│ Installer le package / Configurer MCP / │
│ Écrire du code personnalisé minimal │
└─────────────────────────────────────────────┘
Matrice de décision
| Signal | Action |
|---|---|
| Correspondance exacte, bien maintenu, MIT/Apache | Adopter — installer et utiliser directement |
| Correspondance partielle, bonne base | Étendre — installer + écrire une fine surcouche |
| Plusieurs correspondances faibles | Composer — combiner 2-3 petits packages |
| Rien de convenable trouvé | Créer — écrire du code personnalisé, mais éclairé par la recherche |
Comment utiliser
Étape 0 : Prévol disponibilité des outils
Ceci est un guide pour l'agent, pas un script de configuration exécutable. Vérifiez seulement les canaux pertinents pour la tâche et le projet devant vous.
| Canal | Vérification | Si absent |
|---|---|---|
| Recherche dans le dépôt | rg --files et requêtes rg ciblées | Indiquer que seuls les fichiers visibles ont été inspectés |
| Registre de packages | npm --version, python -m pip --version, ou le gestionnaire de paquets du projet | Utiliser la recherche web/docs et éviter de revendiquer une couverture du registre |
| GitHub CLI | gh auth status | Utiliser uniquement le web public ou l'historique git local |
| Outils MCP/docs | Liste d'outils disponible ou config MCP locale | Revenir aux docs officielles/recherche web |
| Répertoire de skills | ls ~/.claude/skills ~/.codex/skills le cas échéant | Dire qu'aucun catalogue de skills local n'était disponible |
Mode rapide (en ligne)
Avant d'écrire un utilitaire ou d'ajouter une fonctionnalité, parcourez mentalement :
- Cela existe-t-il déjà dans le dépôt ? →
rgd'abord dans les modules/tests pertinents - Est-ce un problème courant ? → Chercher sur npm/PyPI
- Existe-t-il un MCP pour cela ? → Vérifier
~/.claude/settings.jsonet chercher - Existe-t-il un skill pour cela ? → Vérifier
~/.claude/skills/ - Existe-t-il une implémentation/modèle GitHub ? → Effectuer une recherche de code GitHub pour de l'OSS maintenu avant d'écrire du code nouveau
Mode complet (agent)
Pour des fonctionnalités non triviales, lancez l'agent chercheur :
Agent(subagent_type="general-purpose", prompt="
Rechercher les outils existants pour : [DESCRIPTION]
Langage/framework : [LANG]
Contraintes : [TOUTE]
Chercher sur : npm/PyPI, serveurs MCP, skills Claude Code, GitHub
Retourner : Comparaison structurée avec recommandation
")
Les anciennes docs de Claude Code peuvent appeler cela Task(...) ; utilisez le nom de l'outil
agent/subagent actuel exposé par le conteneur actif.
Raccourcis de recherche par catégorie
Outils de développement
- Linting →
eslint,ruff,textlint,markdownlint - Formatage →
prettier,black,gofmt - Tests →
jest,pytest,go test - Pre-commit →
husky,lint-staged,pre-commit
Intégration IA/LLM
- SDK Claude → Context7 pour les dernières docs
- Gestion des prompts → Vérifier les serveurs MCP
- Traitement de documents →
unstructured,pdfplumber,mammoth
Données & API
- Clients HTTP →
httpx(Python),ky/undici(Node) - Validation →
zod(TS),pydantic(Python) - Base de données → Vérifier d'abord les serveurs MCP
Contenu & Publication
- Traitement Markdown →
remark,unified,markdown-it - Optimisation d'images →
sharp,imagemin
Points d'intégration
Avec l'agent planificateur
Le planificateur doit invoquer le chercheur avant la Phase 1 (Revue d'architecture) :
- Le chercheur identifie les outils disponibles
- Le planificateur les intègre dans le plan d'implémentation
- Évite de « réinventer la roue » dans le plan
Avec l'agent architecte
L'architecte doit consulter le chercheur pour :
- Les décisions de pile technologique
- La découverte de motifs d'intégration
- Les architectures de référence existantes
Avec le skill iterative-retrieval
Combiner pour une découverte progressive :
- Cycle 1 : Recherche large (npm, PyPI, MCP)
- Cycle 2 : Évaluer les meilleurs candidats en détail
- Cycle 3 : Tester la compatibilité avec les contraintes du projet
Exemples
Exemple 1 : « Ajouter une vérification de liens morts »
Besoin : Vérifier les fichiers markdown pour les liens brisés
Recherche : npm « markdown dead link checker »
Trouvé : textlint-rule-no-dead-link (score : 9/10)
Action : ADOPTER — npm install textlint-rule-no-dead-link
Résultat : Zéro code personnalisé, solution éprouvée
Exemple 2 : « Ajouter un wrapper client HTTP »
Besoin : Client HTTP résilient avec retry et gestion de timeout
Recherche : npm « http client retry », PyPI « httpx retry »
Trouvé : got (Node) avec plugin de retry, httpx (Python) avec retry intégré
Action : ADOPTER — utiliser got/httpx directement avec config de retry
Résultat : Zéro code personnalisé, bibliothèques éprouvées en production
Exemple 3 : « Ajouter un linter de fichiers de config »
Besoin : Valider les fichiers de configuration du projet contre un schéma
Recherche : npm « config linter schema », « json schema validator cli »
Trouvé : ajv-cli (score : 8/10)
Action : ADOPTER + ÉTENDRE — installer ajv-cli, écrire un schéma spécifique au projet
Résultat : 1 package + 1 fichier de schéma, aucune logique de validation personnalisée
Anti-patrons
- Passer directement au code : Écrire un utilitaire sans vérifier s'il en existe un
- Ignorer MCP : Ne pas vérifier si un serveur MCP fournit déjà la capacité
- Signalement silencieux : Rapporter « rien trouvé » alors qu'un canal de recherche était indisponible
- Sur-personnalisation : Encapsuler une bibliothèque si lourdement qu'elle perd ses avantages
- Gonflement des dépendances : Installer un package volumineux pour une petite fonctionnalité