Créer une PR de correction

Vue d'ensemble

Vous enquêtez sur un problème et déposez une pull request qui le résout. Cela s'appuie sur la skill investigate — menez d'abord l'enquête correctement, ne passez pas à une correction sans preuves.

Utilisez le CLI gh pour toutes les opérations GitHub (l'authentification provient de votre connexion gh) et les outils standard Bash / Edit / Read / Grep pour tout le reste.

Workflow

Enquêter. Utilisez la skill investigate pour identifier la cause racine. Citez l'ID de trace exact, la ligne de log, le groupe d'erreur et l'emplacement du code qui identifie le problème.
Confirmer qu'il n'y a pas déjà une PR ouverte. Avant de déposer quoi que ce soit, recherchez sur GitHub une PR ouverte existante traitant le même problème — gh pr list --search "<keywords>" --state open. Si une existe, dirigez l'utilisateur vers elle — ne créez pas de doublon.
Juger si une PR est le bon outil. Si la correction nécessite un changement de config, un basculement de flag ou une modification en dehors du code auquel vous pouvez accéder, décrivez la solution au lieu de déposer une PR.
Récupérer le repo. Clonez-le si vous ne l'avez pas déjà localement — gh repo clone <owner>/<repo>.
Vérifier les conventions du repo. Lisez agents.md ou CLAUDE.md à la racine du repo — ces fichiers décrivent les règles spécifiques au repo que votre correction doit respecter.
Faire la modification. Diff minimal. Ne refactorisez pas le code environnant, n'ajoutez pas de fonctionnalités, ne corrigez pas les bugs non liés que vous remarquez. Une PR, une correction.
Définir l'identité git avant de committer — voir pr-conventions.md.
Committer, pousser et déposer la PR. Voir pr-conventions.md pour les règles de nommage de branche et de corps de PR.

Qu'est-ce qu'une bonne correction

Change le plus petit nombre possible de lignes
Préserve le comportement de production actuel à moins que le bug NE SOIT le comportement actuel
Ne dépend pas d'hypothèses que vous ne pouvez pas vérifier à partir des preuves
Passerait le contrôle d'une skill code-review si elle existait

Ce qui ne l'est pas

Des refactors massifs non liés au problème signalé
Des vérifications null spéculatives ou de la gestion d'erreur ajoutées « puisque vous y êtes »
Des modifications de tests qui masquent le bug sous-jacent
Un bump de versions de dépendance pour corriger un symptôme

Outils restreints

Si gh n'est pas installé ou si gh auth status indique qu'il n'y a pas d'authentification, surfacez l'erreur à l'utilisateur et arrêtez-vous — ne tentez pas d'autres schémas d'authentification.

Ne jamais inclure dans une PR

Des tokens d'accès GitHub ou toute autre confidentialité ou identifiant.
Des logs de debug ou des déclarations print que vous avez ajoutées lors de l'enquête.

Suivez les conventions de commit et PR du repo pour tout le reste.

create-fix-pr