gener8v/gener8v.claude-skills.engineering

Commandes de développement

1. Trouver les commandes

Utilisez la première source qui répond. Indiquez la commande avant de l'exécuter.

1. Instructions du dépôt : CLAUDE.md, CONTRIBUTING.md, README.md. Dans un dépôt de pipeline gener8v, .gener8v/context.md liste les commandes de vérification pour chaque dépôt.
2. Runner de tâches : Makefile, justfile, Taskfile.yml, scripts package.json, sections d'outils pyproject.toml, tox.ini, noxfile.py.
3. Workflow CI : .github/workflows/*.yml. Ce que la CI exécute définit "les tests passent".
4. Valeur par défaut de l'écosystème : resources/ecosystems.md.

Si le projet s'exécute dans des conteneurs (compose.yaml, docker-compose.yml, un dev container), exécutez les commandes à l'intérieur du conteneur comme le documente le projet. Voir resources/ecosystems.md.

2. Exécuter

• Commencez par un périmètre restreint : un fichier de test ou un package. Ensuite, exécutez la suite complète avant de faire un rapport.
• Ne démarrez pas le mode watch. De nombreux runners de test surveillent par défaut. Utilisez la forme "exécuter une fois" (resources/ecosystems.md).
• Conservez le code de sortie lorsque vous raccourcissez la sortie :

  set -o pipefail
  <commande> 2>&1 | tail -n 60
  echo "exit=$?"
  

• Démarrez un serveur de développement en arrière-plan. Attendez que son URL réponde. Arrêtez-le lorsque vous avez terminé.

3. Lire le résultat

• C'est le code de sortie qui décide. Un texte comme "terminé" ne signifie pas succès.
• Comptez. Rapportez les tests réussis, échoués et ignorés. Les tests ignorés, les tests attendus en échec et "aucun test collecté" ne sont pas des succès.
• Tests flaky. Exécutez un test échoué une fois de plus, seul. S'il réussit, signalez-le comme flaky. Ne le cachez pas.
• Échecs qui étaient déjà là. Vérifiez la branche de base : le dernier passage CI (gh run list --branch <base> --limit 3) ou un passage dans un worktree séparé. Signalez ces échecs comme "déjà en échec sur <base>". Ne les utilisez pas pour excuser vos propres échecs.
• N'affaiblissez pas un test pour qu'il réussisse. Si le test est erroné, dites pourquoi et modifiez-le dans un commit séparé et visible.

4. Données pour le travail d'interface utilisateur

Quand l'interface utilisateur a besoin de données réalistes, suivez resources/throwaway-data.md. La règle courte : ensemencez uniquement une base de données que vous avez créée dans ce but. N'ensemencez jamais la base de données réelle, par défaut ou partagée du projet.

5. Rapport

Donnez la commande, le code de sortie, les compteurs et la première erreur réelle pour chaque échec. Si vous n'avez pas exécuté quelque chose (par exemple, des tests de bout en bout nécessitant des identifiants), dites-le.

Compétences associées

• engineering:github-pr-merge et engineering:github-issue-workflow appellent cette compétence avant une PR.
• engineering:documentation-bootstrap l'utilise pour trouver les commandes que la documentation doit lister.