Format Source : Ajouter une règle

Ajouter une nouvelle règle à la skill format-source, dérivée d'un commit Git. N'importe qui peut l'utiliser pour encoder une convention repérée dans un commit. Les règles peuvent s'appliquer à tout type de fichier que le formateur source gère — Java, .properties, XML, JSP, Markdown, Gradle, .gitignore, YAML, et ainsi de suite. Ne privilégiez pas Java.

Entrées

• Un SHA de commit Git.

• Optionnel : un indice sur l'aspect du commit à encoder. Les commits touchent souvent plusieurs choses ; un indice réduit la portée.

Flux de travail

Inspecter le commit

Inspectez le diff complet du commit. Identifiez un seul motif de formatage apprenable — quelque chose qu'un futur relecteur pourrait appliquer mécaniquement à d'autres codes. Arrêtez-vous et demandez à l'utilisateur de clarifier quand :

• Plusieurs règles distinctes sont présentes. Demandez à l'utilisateur d'en choisir une, ou exécutez la skill une fois par règle.

• Le commit mélange les changements de formatage avec des changements logiques ou de refactorisation qui ne peuvent pas être séparés.

• Le motif n'est pas généralisable au-delà du fichier ou du contexte spécifique.

Vérifier les doublons

Lisez les règles existantes dans .claude/skills/format-source/SKILL.md et comparez-les au motif de l'étape précédente. Si le motif duplique ou chevauche substantiellement une règle existante, signalez-le à l'utilisateur et demandez s'il faut ignorer, affiner la règle existante, ou procéder quand même.

Rédiger la règle

Trouvez le prochain numéro de règle dans .claude/skills/format-source/SKILL.md, puis ajoutez la nouvelle règle à la fin du fichier en utilisant ce modèle markdown exact :

### Rule <next-number>: <Nom en majuscules de titre, par exemple "Method Parameter Ordering">

**Why:** <explication d'une phrase de la cohérence que la règle apporte, pas ce que la règle fait>

**Examples:**

```diff

- <une ou plusieurs lignes avant démontrant la règle, en utilisant des identifiants abstraits — pas le code littéral du commit>
+ <lignes après correspondantes>

```

Utilisez des identifiants abstraits dans le diff plutôt que les noms verbatim du commit — par exemple methodA, fieldB, Foo pour Java ; some.property, myTag, someKey pour properties, XML, YAML, ou Markdown. Les exemples doivent illustrer le motif général ; reproduire le texte exact du commit surapprentissage la règle à un seul cas et fait que les lecteurs futurs se concentrent sur les noms plutôt que sur le motif sous-jacent.

Pour les règles nuancées, utilisez plusieurs blocs diff pour chaque cas supplémentaire. Ajoutez une seule ligne de prose avant le bloc diff quand un diff seul n'est pas clair.

Auto-tester la règle

Validez que la règle ajoutée reproduit le commit d'entrée quand appliquée à l'état parent du commit. Pour cela, créez une nouvelle branche au parent du commit et exécutez /format-source scoped aux seuls fichiers touchés par le commit, en appliquant uniquement les règles manuelles (ignorez le formateur automatique). Comparez le résultat avec le commit. Si la règle ne produit pas un changement équivalent, révisez la règle et répétez jusqu'à ce qu'elle le fasse.

Commiter la règle

Après que l'auto-test réussisse, stagez uniquement .claude/skills/format-source/SKILL.md et committez avec ce format de message de commit :

<ticket> Add rule derived from <sha>