YuShenLiu06/yushen-skills

Du besoin à la recette

1. Reformulation et confirmation

Reformuler l'objectif de l'utilisateur, les non-objectifs, les critères de recette observables, les risques et les contraintes budgétaires. Passer à l'implémentation après confirmation ; si une confirmation explicite existe déjà, la réutiliser sans redemander d'autorisation. Ne poser que les questions qui impactent réellement l'implémentation. Ce processus n'élargit pas les permissions d'outils, de coûts, de push, de merge ou de déploiement.

2. Découpage direct par le coordinateur

• Le coordinateur définit directement les limites fonctionnelles, dépendances, interfaces, responsables et éléments de recette, sans ajouter une couche supplémentaire d'agent de découpage. Les tâches indépendantes sont parallélisées, les tâches dépendantes avancent selon les interfaces et l'ordre.
• Une fonctionnalité pouvant être testée et annulée indépendamment correspond à un worktree indépendant, une branche et une PR réelle. Fixer la branche cible et les SHA de base/head ; les différents implémenteurs n'écrivent pas dans le même répertoire de travail et n'empruntent pas de branche d'une autre tâche.
• Le total des additions + suppressions d'une PR mono-fonctionnalité ne doit pas dépasser 1000 lignes (tests, documentation et fichiers générés inclus). Au-delà, diviser de manière raisonnable ; si impossible, expliquer la raison et l'ampleur, sans cacher les fichiers générés ni découper arbitrairement une demi-fonctionnalité.
• Un lot multi-fonctionnalités enregistre les URLs des sous-PR, dépendances et éléments de recette indépendants. L'organisation peut suivre les PR empilées ou les branches d'intégration déjà supportées par le projet, en vérifiant les capacités réelles ; les numéros de tâche dans la documentation ne peuvent pas usurper de véritables PR.

3. Exécution réelle et auto-validation par l'implémenteur

• L'implémenteur termine l'implémentation, s'auto-vérifie et exécute les parcours utilisateur clés avant de soumettre à la revue indépendante. Il ne transfère pas au relecteur le travail principal d'exécution, de validation et de capture d'écran.
• Enregistrer le SHA exact, la commande, l'environnement, le résultat réel, les éléments non testés et les risques. Pour un bug, fournir la reproduction avant correction et le résultat après correction sur le même chemin. Rapporter séparément la validation construction, mock et service réel.
• Pour les modifications d'UI, fournir des captures d'écran réelles des étapes clés et du résultat. Placer les captures dans le commentaire de la PR ou en pièce jointe, ne pas les committer dans la branche. Vérifier d'abord les paramètres supportés par l'outil d'upload ; si l'upload échoue, signaler le blocage sans inventer d'URL de pièce jointe.
• Pour les changements de permissions backend, données ou comportements financiers, fournir les preuves API/données correspondantes. Utiliser des environnements isolés et des données synthétiques pour les tests, ne pas divulguer d'identifiants ou de données personnelles.
• Pour les modifications de règles ou de documentation sans UI, ne pas falsifier de captures d'écran ; vérifier la portée, les liens, la cohérence des règles et le diff. La validation conteneur utilise un environnement isolé autorisé, sans revenir inconsidérément à la machine personnelle de l'utilisateur.
• Les PR utilisent le modèle à quatre sections, chaque preuve étant liée à un commit réel.

4. Revue de code et de sécurité séparées

• Privilégier la réutilisation des revues automatiques de code et de sécurité déjà configurées dans le dépôt, vérifier séparément leur état d'achèvement, le SHA couvert et les découvertes non résolues. Ne pas ajouter de revues redondantes ni déclencher manuellement des revues en double.
• Si non configuré, non déclenché ou ne couvrant pas le SHA cible, signaler le manque. Traiter selon le plan de secours autorisé ; en l'absence d'autorisation de secours, prendre une décision. L'absence de commentaire ne signifie pas que la revue est terminée.
• Pour la qualité du code, lire yushen-code-quality-review si installé ; pour la sécurité, lire yushen-security-review si nécessaire. Le chemin dépend de l'emplacement réel d'installation ; si absent ou non lu, l'expliquer.
• La revue ne soulève que des problèmes étayés par des preuves ; les implémentations externes peuvent être comparées et suggérées, mais sans modification de la solution, migration ou ajout de dépendance sans l'accord de l'utilisateur.

5. Maximum de trois itérations de convergence

Une itération comprend : retour de revue → correction ou traitement étayé → validation. Les revues de code et de sécurité sont comptées ensemble pour former un total de trois itérations maximum ; un changement d'agent, de modèle, une nouvelle tentative, un restack ou une réouverture de la même PR de travail ne réinitialise pas le compteur.

La première itération examine le diff complet par rapport aux besoins ; les deuxième et troisième itérations vérifient le nouveau diff, la clôture des problèmes existants et la régression affectée. Utiliser un identifiant de problème stable pour regrouper les découvertes de même cause racine, en enregistrant l'emplacement, la preuve, le numéro d'itération, l'état, le SHA de correction et la validation. Les faux positifs sont justifiés par des preuves ; ne pas faire de modifications inutiles pour supprimer un commentaire. Ne pas marquer comme résolu sans revalidation.

Un problème non résolu après deux itérations valides de correction peut être escaladé prématurément. Si à la troisième itération il reste des problèmes non résolus, arrêter la convergence automatique, laisser le coordinateur rassembler les preuves, reconsidérer la solution et demander une décision ; ne pas abaisser le seuil, approuver automatiquement ou merger.

6. Vérification de la version combinée

Le coordinateur vérifie les CI finales nécessaires, la résolution des conflits, l'état partagé et les parcours utilisateur combinés, et enregistre le SHA de chaque sous-PR ainsi que le SHA candidat de la combinaison. Le succès de chaque couche ne garantit pas le succès de la combinaison. Après un rebase, une résolution de conflit ou une modification d'implémentation, mettre à jour la correspondance des SHA et ajouter la régression affectée ; les anciennes preuves ne peuvent pas se faire passer pour le résultat de la version actuelle.

7. Recette humaine

Fournir le SHA candidat, le livrable exécutable, les étapes de test minimales, le résultat attendu et les risques résiduels. L'utilisateur teste lui-même et confirme explicitement la version correspondante avant de merger selon les autorisations réelles. Après une modification de code, reconfirmer la partie affectée ; les tests automatiques et l'approbation par un robot ne remplacent pas la recette personnelle. La publication et le déploiement sont traités selon leurs autorisations respectives.

Lors de la livraison d'un installateur, d'une application de bureau ou d'un autre produit publié, lire yushen-release-acceptance si installé, vérifier le chemin complet du téléchargement du fichier final jusqu'à son utilisation, et distinguer les conclusions par plateforme des limitations de prévisualisation. Les modifications purement rédactionnelles ou internes mineures ne nécessitent pas l'application complète de la recette de publication.

Stratégie de modèle et de coût

Sélectionner le modèle en fonction de la difficulté configurable de la tâche, du risque, du budget et des capacités disponibles : privilégier les scripts pour les vérifications déterministes ; privilégier les modèles bas coût pour les implémentations locales claires ; choisir un modèle adapté aux capacités pour les diagnostics complexes, la conception et les jugements à haut risque ; utiliser un modèle bas coût pour la synthèse de preuves. Expliquer au début le rôle choisi, la limite de coût et les conditions de passage à un modèle supérieur, sans considérer un modèle spécifique comme disponible par défaut dans l'environnement public.

Exclure d'abord les erreurs d'environnement et le manque de contexte avant de décider de monter en gamme. En cas de dépassement du budget, d'augmentation des appels payants ou de dépassement des capacités autorisées, obtenir d'abord la décision correspondante ; ne pas réessayer indéfiniment. En fin de lot, utiliser éventuellement le résumé de reprise ; les mises à jour de règles suivent le processus normal de recette.

Intégration des règles du projet

Dans le fichier AGENTS.md du projet, exiger explicitement que les compétences pertinentes et REVIEW.md soient lues par la tâche ; ne pas supposer que les liens se déroulent automatiquement. REVIEW.md ne doit contenir que des règles de projet durables et vérifiables ; les découvertes et preuves de chaque itération restent dans la PR. Signaler l'absence de fichier ou un conflit de contraintes, sans inventer de mécanisme.

Lors de la création de règles de projet, se référer si nécessaire à l'exemple de REVIEW générique, en ne conservant que les clauses réellement applicables et vérifiables.