Rédaction de skills de révision PostHog

PostHog Review est le relecteur PR automatisé de PostHog. Une révision divise la PR en chunks, puis pour chaque chunk exécute en parallèle chaque perspective activée (des lentilles spécialisées indépendantes), un seul blind-spot check ensuite (un dernier passage conditionné par ce que les perspectives ont trouvé), et finalement juge chaque trouvaille candidate contre un seul skill de validation criteria — seules les trouvailles qui passent sont publiées dans la pull request. Après une révision publiée, la resolution stage revient sur les threads de révision non résolus de la PR et juge chacun contre un seul skill de resolution criteria — les demandes valables et sûres sont implémentées sur la branche PR, chaque thread reçoit une réponse.

Ces quatre types sont des lignes LLMSkill d'équipe que les agents de révision tirent sur MCP au moment de l'exécution. PostHog fournit les canoniques ; ce skill est le guide pour rédiger les custom. Le skill lui-même est au niveau équipe ; que ce soit qu'il s'exécute est un paramètre par utilisateur dans Inbox → Code review.

Flux de rédaction

1. Posez les bases. Avec les outils de skill MCP PostHog, skill-list les skills review-hog-* de l'équipe et skill-get le canonique du type que vous rédigez (voir le tableau ci-dessus) — c'est la référence pour la structure et le ton. Pour une perspective, parcourez les descriptions de chaque review-hog-perspective-* existant pour que la nouvelle lentille ne recouvre pas un terrain qu'une lentille activée possède déjà (le chevauchement est dédupliqué plus tard, mais cela gaspille des passages de révision).
2. Interrogez l'utilisateur. Demandez sur quoi le skill doit se concentrer, et proposez quelques directions concrètes que l'ensemble actuel ne couvre pas — fondées sur ce que vous avez vu à l'étape 1 et, quand c'est utile, sur le projet lui-même. Ne commencez à rédiger que lorsque la direction est choisie.
3. Rédigez le corps en suivant les orientations spécifiques au type ci-dessous. Gardez un ensemble d'instructions focalisé que l'agent de révision peut appliquer à un chunk en un seul passage — pas un essai.
4. Créez le skill vous-même avec posthog:skill-create — créez réellement la ligne LLMSkill d'équipe ; ne donnez jamais à l'utilisateur un corps à copier-coller. Passez le nom exact selon le contrat ci-dessus (slug minuscule), une description d'un paragraphe de ce que la lentille/le passage/le critère est, et le corps. Le préfixe du nom est toute l'identité — c'est ainsi que l'onglet Code review et les exécutions de révision découvrent le skill. Il n'y a pas de paramètre category sur les outils de skill et vous n'en avez pas besoin : le backend estampille lui-même la catégorie de groupage review_hog (cela affecte seulement le groupage sur la page Skills) — ne dépensez pas de tours à essayer de la définir ou de la vérifier. Itérez avec posthog:skill-update si l'utilisateur veut des modifications. Rédigez en partant de zéro — ne faites pas de skill-duplicate d'un canonique à éditer : les métadonnées amorcées se transportent avec la copie, et la synchronisation canonique peut la remplacer ou la supprimer.
5. Dites à l'utilisateur comment l'activer. Un skill custom démarre inactif pour eux :
   • Perspective — activez-le sous Inbox → Code review → Perspectives (il apparaît désactivé jusqu'à ce que vous l'activiez ; au moins une perspective doit rester active).
   • Blind-spot check / validation criteria / resolution criteria — sélectionnez-le sous la section correspondante ; exactement un s'exécute à la fois, donc le sélectionner échange l'actuel pour leurs révisions uniquement. Les révisions épinglent les versions de skill quand une exécution démarre, donc une modification en cours de révision s'applique à partir de la prochaine exécution.

Rédaction d'une perspective de révision

Le corps instruit un passage de révision spécialisé sur un chunk PR. Respectez la forme du skill canonique logic-correctness :

• La lane — une phrase sur ce dont cette lentille est responsable ; rapportez tout dans la lane et laissez le reste aux autres perspectives.
• Hunting grounds — une poignée numérotée de lieux concrets à regarder, chacun un contrôle spécifique que l'agent peut appliquer au chunk (« les limites de transaction qui divisent les écritures qui doivent se terminer ensemble »), pas une vertu abstraite (« assurer la correction »).
• Lane boundary — quelle perspective possède chaque préoccupation adjacente que cette lentille doit laisser seule.
• La barre de trouvaille — une trouvaille publiable nomme le déclencheur concret et la conséquence concrète ; terminez avec un critère d'achèvement (« fait quand chaque fichier modifié est signalé ou effacé contre chaque hunting ground »).

Le harnais de révision dit déjà à l'agent la mécanique du pipeline — perspectives parallèles, déduplication ultérieure, niveaux de sévérité, la règle des fichiers hors-tests — donc le skill ne porte que la lentille ; réaffirmer les règles du harnais le dilue.

Rédaction d'un blind-spot check

Le corps instruit le passage final qui s'exécute après que chaque perspective activée a terminé un chunk. Il est conditionné par les trouvailles couvertes (le prompt liste quelles perspectives ont s'exécuté et ce qu'elles ont trouvé), donc le corps doit dire comment les utiliser : les trouvailles couvertes cartographient où l'attention s'est déjà portée, et la valeur du passage est l'espace négatif — les chemins d'erreur, les entrées non gérées, les interactions cross-file, les hypothèses. Il n'est pas limité à une spécialité, et un résultat vide est préférable au remplissage. Un sweep custom restreint ou réajuste cette chasse (par ex. vers un domaine où l'équipe se brûle constamment).

Rédaction de validation criteria

Le corps définit la barre de conservation/suppression contre laquelle chaque trouvaille candidate est jugée avant la publication. La précision plutôt que le rappel est la valeur par défaut de la maison — un relecteur qui soulève du bruit se fait mettre en sourdine — donc définissez : ce qui rend une trouvaille réelle et digne de l'attention d'un auteur (correction affectant l'utilisateur, sécurité, perte de données, ruptures de contrat, performance), ce qui est supprimé (surengénierie, spéculation, paranoïa défensive, bords inaccessibles, style), et comment traiter l'incertitude authentique (défaut : supprimer). Une barre custom décale la rigueur ou réajuste les préoccupations ; elle doit toujours exiger des preuves du codebase actif, pas des vibes.

Rédaction de resolution criteria

Le corps définit la barre que la resolution stage applique à chaque thread de révision non résolu sur une PR : vaut la peine d'être implémenté (une vraie amélioration que la PR doit porter, dans la portée de ce qu'elle change) et sûr à implémenter sans surveillance (petit rayon de blast, aucun contrat ou changement API, aucune réécriture cross-cutting, vérifiable localement). Définissez ce qui est implémenté, ce qui reçoit un déclin raisonné (demandes de surengénierie, scope creep, churn de style uniquement, demandes mieux servies par un suivi), et ce qui escalade à un humain. Le harnais possède les limites strictes — les threads rédigés par humain ne sont jamais résolus par le bot, les escalades ne résolvent jamais un thread, les réponses expliquent toujours la décision — donc un skill custom peut resserrer la barre ou réajuster ce qui compte comme valable, jamais assouplir ces limites.