Java Enterprise Workflow
Checklists Java d'entreprise qui forcent une correction de curseur/transaction/mapper pour réellement appliquer l'invariant, pas seulement le mentionner.
Testé · Fonctionne
Ce que fait
Un flux de travail générique d'investigation-planification-édition-vérification pour les changements backend Java/Spring/Maven/Gradle, avec 15 références de scénarios (transactions, consommateurs MQ, nouvelles tentatives RPC, pagination par curseur, réparation de données, revue de code) et des portes d'échec strictes qui rejettent les correctifs qui semblent complets mais ne soutiennent pas l'affirmation avec un vrai test. Déclenchez-la pour le travail de fonctionnalité Java, les corrections de bugs, les changements de schéma/champ, la revue de PR, ou les tâches de test/vérification backend.
Rapport de test
A construit un bug de pagination par curseur de type MyBatis jetable (les lignes avec le même createdAt sont silencieusement ignorées) et a exécuté un véritable A/B : la correction de base libre n'a ajouté que id à ORDER BY et a laissé le prédicat de recherche WHERE et le DTO de curseur inchangés — le bug de l'ignorance survit intact — tandis que les références/transactions.md de la compétence ont réécrit le prédicat de recherche en (created_at, id), ont rendu le curseur typé, et ont ajouté un test de frontière qui, selon une trace manuelle, attrape réellement l'égalité.
Testé le: 2026-07-16 · Claude Code 2.x (agent harness)
Installation
git clone https://github.com/kyle641320/Scout4j.git mkdir -p ~/.claude/skills cp -r Scout4j ~/.claude/skills/java-enterprise-workflow
Commandes et exemples de prompts
/java-enterprise-workflowChecklists Java d'entreprise qui forcent une correction de curseur/transaction/mapper pour réellement appliquer l'invariant, pas seulement le mentionner.
Les skills se déclenchent sur des demandes en langage courant — aucune commande à retenir. Après installation, des prompts comme ceux-ci l'activent (en anglais) :
Fix this MyBatis cursor pagination bug that skips duplicate rowsReview this Spring PR and verify the transaction boundaries are safeAdd a retry policy to this RPC call and prove it with a real test