Communitygithub.com

haxzie/prequel

Effectuer des recherches pour un article de blog avant qu'il ne soit rédigé. Utilisez cette compétence lorsqu'on vous demande de rechercher un sujet pour le blog Prequel, de trouver ce que les gens disent d'un outil d'enregistrement d'écran ou d'un problème, de rassembler des sources, de trouver des angles, de vérifier les prix d'un concurrent, ou de dire « recherche et rédige » (exécutez d'abord celle-ci, puis passez à guide-posts ou comparison-posts). Couvre la cartographie du sujet, les flux de recherche Firecrawl, l'origine des propres faits de Prequel, ce qu'est une citation utilisable, et la structure du brief attendu par les compétences de rédaction.

Qu'est-ce que prequel ?

Cette compétence génère un brief de recherche pour un article de blog, garantissant que chaque affirmation sur les prix, les plaintes et les fonctionnalités des concurrents est vérifiable. Elle se connecte à un dépôt local pour les faits propres à Prequel (résolution, prix, fonctionnalités), utilise Firecrawl pour les sources web (tarifs des fournisseurs, plaintes Reddit, faits macOS) et applique des règles strictes de vérification des sources. Le brief est écrit dans un fichier `.context/research/<slug>.md`, puis transmis à la compétence de rédaction appropriée (`comparison-posts` ou `guide-posts`). La compétence prend en charge Claude Code et d'autres agents utilisant le protocole d'outils. Elle organise la recherche en phases : carte du sujet, faits locaux, cinq flux de recherche ciblés, puis rédige le brief structuré avec des sections pour les prix, les plaintes, les liens existants et les contradictions.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/haxzie/prequel/tree/HEAD/.claude/skills/blog-research

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Recherche pour un article de blog

Un brief est ce qui fait la différence entre un article qui affirme des choses et un article qui affirme des choses vérifiables. Chaque prix, chaque plainte citée et chaque « la plupart des outils s'arrêtent à 60 ips » dans le blog est une affirmation sur le produit de quelqu'un d'autre, et une affirmation erronée discrédite toutes les affirmations correctes de la page. Cette compétence produit la liste vérifiée à partir de laquelle le rédacteur travaille, et rien d'autre : elle ne rédige pas l'article.

Les faits de Prequel ne viennent pas du web. Ils proviennent du dépôt, et la première section ci-dessous indique où. Rechercher « Prequel screen recorder » donne un avis obsolète ou un produit différent portant le même nom.

Où vont les choses

CheminCe que c'est
.context/research/<slug>.mdLe brief. Gitignoré ; échafaudage, non livré.
apps/web/src/content/competitors.tsPrix et fonctionnalités vérifiés pour les six concurrents ayant des pages
.claude/skills/comparison-posts/assets/quotes.jsonChaque citation Reddit déjà capturée
apps/web/src/content/posts.tsCe que le blog couvre déjà

Le brief n'est pas commité car l'article porte ses propres preuves : prix dans le tableau avec une date de vérification, fils Reddit liés dans la citation, et tout ce qui doit survivre à l'article est déplacé dans competitors.ts ou quotes.json. Un brief commité devient obsolète dès qu'un prix change et que personne ne le met à jour, et il devient alors une seconde source de vérité en désaccord avec la page.

Phase 1 : la carte du sujet

Avant toute recherche, écrivez ce qu'est l'article et confirmez-le. Trois lignes, dans la réponse :

  • La requête à laquelle il répond. « enregistreur d'écran mac sans filigrane », « comment enregistrer l'audio système sur mac ». L'article est construit pour cette requête, et elle détermine le slug, la question définitionnelle et la FAQ.

  • Le genre. Un comparatif va vers [[comparison-posts]] ; un article « meilleures alternatives à » vers [[alternatives-posts]] ; un tutoriel, un explicatif ou un pilier vers [[guide-posts]]. Chacun nécessite une recherche différente : un comparatif a besoin des prix pour dix outils, un guide a besoin des faits macOS et des plaintes.

  • La question définitionnelle. Chaque article ouvre une section ## Qu'est-ce que <chose> ? et la question doit être unique sur le blog. Recherchez dans les articles existants avant d'en proposer une :

    grep -h "^## Qu'est-ce que\|^## Comment" apps/web/src/content/blog/*.mdx
    

Ensuite, le pilier sous lequel il se trouve, depuis posts.ts. Aujourd'hui, il y en a trois : screen-recording-on-mac, product-demo-videos, screen-recording-for-youtube. Un article sans pilier est un pilier, et c'est une décision pour l'utilisateur, pas pour le brief.

Présentez cela et attendez. Faire des recherches sur le mauvais genre, c'est une heure perdue.

Phase 2 : les propres faits de Prequel, depuis le dépôt

Lisez-les avant le web, afin que le brief oppose les concurrents à ce que Prequel livre réellement plutôt qu'à ce qu'un moteur de recherche retient :

FaitSource
Résolution, ips, codecs, sortieSPECS dans apps/web/src/components/landing/LandingBody.tsx
Ce que fait le premier passage automatiqueALREADY_DONE dans le même fichier. Rien d'autre n'est automatique.
Prix, durée d'essaiapps/web/src/lib/pricing.ts, jamais un nombre de mémoire
Réponses produitapps/web/src/lib/faq.ts
Lignes de fonctionnalités et ce que nous affirmonsFEATURE_ROWS dans competitors.ts
ExigencesApple Silicon, macOS 14 ou ultérieur, autorisation d'enregistrement d'écran

Deux règles de [[no-dead-air-claim]] et [[site-copy]] s'appliquent au brief autant qu'à l'article. Prequel ne coupe pas, ne rogne pas et ne supprime pas les silences ; la coupe est un passage manuel sur la timeline. Et rien n'est inscrit dans le brief comme un défaut de Prequel : là où un rival gagne vraiment sur quelque chose, le brief l'enregistre pour que le rédacteur sache ne pas aborder le sujet, marqué ne pas écrire.

Phase 3 : les flux de recherche

Firecrawl est l'outil de recherche. firecrawl_search renvoie les titres, extraits et URL ; firecrawl_scrape récupère une page en markdown ; firecrawl_map liste les pages d'un site lorsqu'un vendeur cache ses prix à trois clics de profondeur. Exécutez les flux dont le genre a besoin, en parallèle en tant que sous-agents lorsqu'il y a plus de trois outils à couvrir, en ligne sinon.

Flux 1, les faits sur les fournisseurs. Pour chaque outil que l'article nomme : la page de tarification du fournisseur lui-même, récupérée et lue. Enregistrez chaque niveau avec sa période de facturation, car un chiffre mensuel cité sans le chiffre annuel est l'erreur la plus dommageable qu'un comparatif puisse commettre, et elle est vérifiable en un clic. Enregistrez la date. Si la page est rendue en JS et que firecrawl_scrape renvoie une coquille vide, dites-le et récupérez-la avec Chrome sans tête ([[headless-chrome-screenshots]] en mémoire). Pour les six dans competitors.ts, comparez avec ce qui s'y trouve et signalez toute dérive ; la correction est une modification de ce fichier, pas un nombre dans le brief.

Les faits qui comptent pour ce blog, par outil, parce que ce sont ceux sur lesquels Prequel gagne : résolution et fréquence d'images maximales sur chaque forfait, filigrane sur le niveau gratuit ou l'essai, limite de durée d'enregistrement, rendu local ou téléchargé, licence unique ou abonnement, si la caméra est une piste séparée pouvant être recadrée après la prise.

Flux 2, ce dont les gens se plaignent. Reddit via firecrawl_search avec includeDomains: ["reddit.com"], plus Hacker News, G2 (les avis deux et trois étoiles, où se trouvent les plaintes spécifiques) et X. Pour un article d'alternatives, enregistrez suffisamment de chaque plainte pour créer une carte : titre textuel, sous-reddit ou pseudo, auteur, date, score, nombre de commentaires, premier paragraphe. [[alternatives-posts]] les affiche. firecrawl_scrape refuse catégoriquement reddit.com, donc le titre d'un fil, l'extrait et l'URL sont tout ce qui revient, et cela suffit pour une citation. Requêtes qui fonctionnent : "<outil> prix" reddit, "<outil> alternatives", "<outil> filigrane", "<outil> lent", enregistrer audio système mac reddit.

Préférez un grief authentique à un article de lancement. Plusieurs fils Loom dans les résultats sont des fondateurs annonçant leur propre alternative avec un titre qui ressemble à une plainte. Vérifiez d'abord quotes.json : un fil déjà capturé y a une capture d'écran dans public/blog/quotes/ et ne nécessite aucun nouveau travail.

Flux 3, ce que le blog dit déjà. Lisez posts.ts et le MDX existant pour tout ce qui concerne le sujet. Le brief liste les articles vers lesquels le nouvel article doit créer un lien (cinq ou plus, avec le texte d'ancrage), le pilier, et toute phrase d'un article existant que le nouvel article contredirait. Deux articles en désaccord sur le niveau gratuit de Loom est pire que l'un d'eux soit erroné seul.

Flux 4, les faits macOS. Pour un guide, ce que QuickTime et Cmd+Maj+5 peuvent et ne peuvent pas faire sur le macOS actuel, à partir des pages d'assistance d'Apple elles-mêmes, avec l'URL. Ces faits changent par version et le blog les énonce comme des faits.

Flux 5, les chiffres. Toute statistique sur laquelle l'article pourrait s'appuyer (temps de visionnage avec le son coupé, taux de complétion des vidéos de démonstration) tracée jusqu'à sa source primaire, datée, et écartée si elle a plus de trois ans ou si la piste se termine sur un autre blog. Un chiffre que le rédacteur ne peut pas lier est un chiffre que le rédacteur ne peut pas utiliser.

Ce qu'une source doit satisfaire

  • En ligne, et chargeant le contenu que le brief indique. Récupérez-la avec firecrawl_scrape ; un 200 qui sert « L'accès est temporairement restreint » n'est pas une source. G2, Capterra et Trustpilot répondent tous de cette façon à une récupération sans tête et ne sont pas utilisables ici.
  • Page du fournisseur plutôt que site d'avis. Page de détail plutôt que résumé. Ils sont en désaccord plus souvent qu'on ne le pense.
  • Datée. Les prix, les statistiques et le comportement de macOS portent tous la date de vérification.
  • Une citation Reddit ou HN est l'URL du fil plus le sous-reddit ou le pseudo. Une paraphrase sans lien n'est pas une citation, et une capture d'écran non plus.
  • Rien que l'article ne va pas lier. Le blog ne lie que les hôtes de citation : reddit.com, news.ycombinator.com, x.com, g2.com, et github.com ou producthunt.com pour un chiffre d'échelle. Les URL des fournisseurs vont dans le brief pour vérification et nulle part ailleurs.

Phase 4 : le brief

# Brief de recherche : <titre provisoire>

Requête de recherche : <la requête>
Genre : guide | comparatif | bilans | pilier
Question définitionnelle : ## Qu'est-ce que <chose> ?     (confirmé unique)
Pilier : <slug> | aucun (c'est un pilier)

## Faits Prequel utilisés
<puces, chacune nommant le fichier dont elle provient>

## Ne pas écrire
<tout point où un rival bat Prequel, afin que le rédacteur évite le sujet>

## Outils
### <outil>
Prix : <chaque niveau et période de facturation>. Vérifié <date>. <URL du fournisseur>
Faits : <résolution, ips, filigrane, limite de durée, local ou téléchargement, licence>
Prequel gagne sur : <le contraste que cette section doit porter>
Plaintes : <titre du fil> (r/<sous>) <URL>    <- dans quotes.json ? oui/non

## Faits macOS
<puces, chacune avec l'URL d'Apple et la date>

## Chiffres
<statistique> <URL de la source primaire> <date de publication>

## Articles existants à lier
/blog/<slug>  "<texte d'ancrage>"  (pourquoi cela correspond)

## Contradictions
<tout ce qu'un article existant dit et que celui-ci contredirait>

## Candidats FAQ
<question telle que quelqu'un la tape dans une boîte de recherche> (de : URL du fil ou PAA)

## Angles
<trois à cinq, à partir des écarts entre ce que les gens demandent et ce qui existe>

Écrivez-le dans .context/research/<slug>.md et terminez par la seule question à laquelle le rédacteur a besoin de réponse : quelle compétence prend le relais, [[guide-posts]] ou [[comparison-posts]], et si la liste des angles doit d'abord être réduite.

Skills associés