Prendre en charge

Trouver un problème dans tldraw/tldraw, l'implémenter et ouvrir une pull request.

Workflow

1. Trouver le problème

L'utilisateur peut référencer un problème par numéro, URL ou description.

• Pour un numéro ou une URL, récupérer le problème directement :

gh issue view 123 --repo tldraw/tldraw

• Pour une description, chercher d'abord parmi les problèmes ouverts :

gh issue list --repo tldraw/tldraw --search "dark mode" --state open --limit 10

• Si aucun problème ouvert ne correspond, chercher dans tous les problèmes :

gh issue list --repo tldraw/tldraw --search "dark mode" --state all --limit 10

S'il y a une correspondance claire, procéder. S'il y a plusieurs correspondances, demander à l'utilisateur de choisir parmi les numéros et titres des problèmes. S'il n'y a aucune correspondance, demander si créer un nouveau problème en utilisant la skill issue.

2. Comprendre le problème

Lire le problème complet et les commentaires. Identifier :

• Type de problème : bug, feature, enhancement, cleanup, docs ou task.
• Comportement demandé et critères d'acceptation.
• Notes techniques et fichiers affectés.
• Discussion pertinente ou clarifications.

Si le problème manque de détails, explorer le codebase avant de décider si l'implémentation est sûre.

3. Assigner le problème

Assigner le problème à l'utilisateur GitHub actuel. Si quelqu'un d'autre est déjà assigné, demander à l'utilisateur s'il faut procéder.

4. Planifier l'implémentation

Créer une checklist d'implémentation concise basée sur :

• La description du problème.
• Les critères d'acceptation.
• L'exploration du codebase.
• Les patterns existants du repository.

5. Implémenter

Créer une nouvelle branche à partir de main.

Parcourir la checklist :

• Lire les fichiers avant de les éditer.
• Suivre les patterns existants.
• Garder les changements focalisés sur le problème.
• Éviter les améliorations spéculatives.
• Mettre à jour la documentation, les exemples, les tests ou les rapports d'API quand le problème l'exige.

6. Vérifier

Exécuter d'abord les vérifications les plus réduites pertinentes. Utiliser des vérifications plus larges quand le changement touche un comportement partagé.

Vérifications finales typiques :

yarn typecheck
yarn lint

Pour les changements focalisés sur un package, préférer les tests du workspace pertinent avant les vérifications au niveau du repository.

7. Créer la PR

Utiliser la skill pr.

• Lier le problème avec Closes #<issue-number>.
• Inclure le contexte pertinent de la discussion du problème.
• Inclure un plan de test clair.

8. Résumer

Terminer avec :

• Problème implémenté.
• Changements clés et fichiers modifiés.
• Vérification effectuée.
• Lien vers la PR.
• Étapes de test manuel, si pertinent.
• Tout critère d'acceptation qui n'a pas pu être satisfait et pourquoi.

Règles

• Demander à l'utilisateur quand les exigences sont floues.
• Ne pas deviner le comportement du produit non spécifié.
• Garder l'implémentation limitée au problème.
• Ne jamais inclure d'attribution d'IA dans les commits, les problèmes ou les PRs.