Quand l'utiliser : Vous avez trouvé un article sans paywall, une page de docs ou un billet de blog et vous voulez un TL;DR plus un avis sans le lire vous-même.
Déroulement
-
Récupérez avec sortie Markdown
Récupérez https://example.com/blog/post et donnez-moi les premiers ~3000 caractères en Markdown propre.✓ Copié
→ Le contenu arrive avec des titres fonctionnels et sans chrome de navigation
-
Résumez et extrayez les affirmations
Résumez en 5 points. Listez tous les nombres ou affirmations spécifiques que l'auteur fait, avec la phrase où ils apparaissent.✓ Copié
→ Résumé à puces plus citations, pas de paraphrase
-
Critique
Quel est le contre-argument le plus solide à la thèse principale de l'auteur ? Soyez spécifique.✓ Copié
→ Une vraie critique, pas du « en revanche... » mou
Résultat : Une lecture utile de l'article en 30 secondes, avec des citations que vous pouvez vérifier.
Pièges
- La page est rendue en JS et la récupération retourne une coque presque vide — Vérifiez la première sortie de récupération — si elle est suspecte courte ou dit « Loading... », basculez vers Firecrawl ou le MCP Chrome DevTools
- Longue page tronquée par max_length — Utilisez
start_index pour paginer : le deuxième appel avec start_index: 5000 reprend là où le premier s'est arrêté
Quand l'utiliser : Une bibliothèque dont vous dépendez publie des notes de version sur une page statique et vous n'avez pas vérifié depuis un mois.
Déroulement
-
Récupérez la page du changelog
Récupérez https://vendor.com/changelog et listez chaque version depuis 2026-03-01 avec sa date et un résumé d'une ligne de ce qui a changé.✓ Copié
→ Liste chronologique avec dates
-
Classifiez par impact
Catégorisez chacun en : breaking change, nouvelle fonctionnalité, correction de bug, interne. Signalez tout ce qui est marqué breaking ou déprécié.✓ Copié
→ Balise par version avec items breaking mis en évidence
-
Signalez ce qui nous affecte
Nous utilisons cette bibliothèque principalement pour <feature X>. Laquelle de ces modifications nous affecte, et quelle action (le cas échéant) devrions-nous prendre ?✓ Copié
→ Liste exploitable, pas le générique « examiner les notes »
Résultat : Sachez en 2 minutes si vous devez mettre à jour la version et tester, ou ignorer la version entièrement.
Pièges
- Les changelogs paginatent — la première page n'a que les 2 derniers mois — Faites défiler avec
start_index ou récupérez explicitement l'URL d'archives - Les pages de version GitHub sont maintenant rendues via JS — Utilisez plutôt l'API brute :
https://api.github.com/repos/owner/repo/releases retourne JSON sans avoir besoin de JS
Quand l'utiliser : Vous codez contre une spec publique (OAuth, RFC 9457 problem details, les docs de référence d'une API REST) et vous voulez que Claude ait la source canonique.
Déroulement
-
Récupérez la/les page(s) de spec
Récupérez https://datatracker.ietf.org/doc/html/rfc9457 en Markdown. Retournez uniquement les sections 1-4.✓ Copié
→ Markdown propre des sections normatives
-
Implémentez contre elle
En utilisant cette RFC comme source de vérité, écrivez-moi un type TypeScript plus un validateur pour l'objet problem details. Citez les numéros de section spécifiques dans les commentaires.✓ Copié
→ Code avec références en ligne // per RFC 9457 §3.1
-
Vérification des cas limites
À partir de la même RFC, quels cas limites ou champs optionnels mon implémentation ne gère pas ? Décidez de les gérer ou de documenter le choix.✓ Copié
→ Analyse honnête des lacunes par rapport à la spec
Résultat : Une implémentation fidèle à la spec avec des citations traçables que vous pouvez défendre dans l'examen du code.
Pièges
- Les pages IETF sont énormes — une RFC entière peut dépasser le budget de contexte — Récupérez uniquement les sections dont vous avez besoin en utilisant des liens d'ancrage ou start_index, pas le doc complet