Du besoin à la livraison
Commencez par clarifier ce que l'utilisateur veut changer et ce qui constitue un achèvement, puis exécutez. Continuez le travail autorisé jusqu'à son terme ; lorsqu'une décision est nécessaire, terminez d'abord les parties qui n'en dépendent pas. Ne considérez pas « avoir écrit un plan », « le code compile » ou « la fusion automatique est activée » comme une livraison finale.
Conventions de travail
- Choisissez la méthode de développement en fonction des objectifs, des risques et du coût du retour d'information. Vous pouvez d'abord rédiger une spécification, adopter une approche de développement piloté par les tests sur une interface publique claire, ou implémenter directement puis vérifier ; les méthodes peuvent être combinées. Définissez toujours des critères d'achèvement observables, obtenez des preuves du comportement réel, n'imposez pas un processus unique à toutes les tâches.
- Décrivez « ce qui est » avec le code actuel, les résultats d'exécution et les artefacts de version réels ; décrivez « ce qui doit devenir » avec les objectifs confirmés par l'utilisateur. Si un écart est constaté, corrigez l'implémentation ou les enregistrements obsolètes, ne remplacez pas les objectifs de l'utilisateur par d'anciens documents.
- Adaptez le processus à l'ampleur de la tâche. Pour une petite modification, la spécification peut tenir en quelques phrases ; ce n'est que pour une exigence transversale que vous découpez, concevez et documentez. Ne chargez pas l'intégralité des connaissances pour chaque édition, n'établissez pas une chaîne d'approbation fixe et ne remplissez pas de modèles vides.
- Le périmètre autorisé par l'utilisateur reste valide. La recherche, l'implémentation et la vérification réversible ne nécessitent pas de confirmation répétée ; la publication externe est exécutée selon les objectifs explicites de l'utilisateur. Si les objectifs de production ou l'autorisation font toujours défaut, préparez d'abord les artefacts, les écarts, le rollback et les vérifications, puis expliquez ce qui manque.
- Ce skill peut être utilisé de manière autonome. Lorsque les skills du tableau ci-dessous sont installés, ils sont appelés selon les besoins ; s'ils ne sont pas installés, le résultat de l'étape est produit directement sans exiger que l'utilisateur installe l'ensemble des skills.
- Une tâche est poursuivie par le responsable actuel. Les méthodes spécialisées complètent les preuves et les artefacts de l'étape en cours, en utilisant les décisions déjà confirmées et le même enregistrement, sans introduire un processus concurrent.
Choisir la prochaine étape
| Situation actuelle | Méthode de progression | Skills appelables |
|---|---|---|
| Vous ne savez pas quelle capacité utiliser, ou vous souhaitez seulement savoir comment l'utiliser | Choisissez l'entrée minimale en fonction de la tâche ; expliquez d'abord la méthode d'utilisation, ne confondez pas une consultation avec une autorisation d'exécution | dev-help |
| Configuration initiale de l'environnement, du modèle de rôle ou du budget d'inférence | Vérifiez les outils et modèles réellement disponibles, sauvegardez des préférences concises ; ne présumez pas de fournisseur fixe ou de capacité backend | dev-setup |
| Vous souhaitez que les tâches répétitives s'adaptent progressivement à vos habitudes | Extrayez des modèles stables de l'historique autorisé en lecture, formez une compétence projet courte et maintenable | dev-personalize |
| L'utilisateur demande l'avancement pendant la tâche, ou un briefing de passation | Résumez ce qui est fait, les preuves actuelles et les points en suspens ; après avoir répondu, reprenez la tâche originale, sauf demande explicite de suspension | dev-status |
| Entrée provenant de chat, Issue, capture d'écran, logs ou plusieurs retours | Trouvez les preuves originales, le comportement réel, les objectifs et le périmètre, fusionnez les demandes en double | dev-intake |
| Configuration d'un canal de rapport ou surveillance par source de demandes | Choisissez séparément la source, le tracker, le routage du dépôt, la méthode de contrôle et le déclencheur réel, effectuez l'initialisation dans le périmètre autorisé | dev-issue-setup |
| Les rapports d'un adaptateur source configuré nécessitent classification, dédoublonnage ou tri | Traitez les preuves selon le rapport natif, l'identité et le contrat du tracker ; la source peut être chat, ticket, email, alerte ou saisie manuelle, ne reproduisez pas ou ne corrigez pas à cette étape | dev-issue-triage |
| Pipeline de rapports configuré, conditions de tri fiables et de contrôle d'interface utilisateur réelle remplies | Vérifiez l'attribution, reproduisez ou vérifiez un correctif existant selon le protocole complet ; corrigez et livrez un projet de PR si nécessaire et autorisé | dev-issue-fix |
| Ambiguïté critique dans les règles produit | Répondez d'abord avec les faits du code, clarifiez autour des questions qui modifieraient la solution au fil des échanges | dev-grill |
| Besoin clair mais pas encore directement vérifiable | Écrivez le comportement utilisateur, les limites, les non-objectifs et les conditions de succès | dev-spec |
| L'utilisateur souhaite approfondir ou reformuler une demande en attente | Utilisez quatre questions pour vérifier les omissions professionnelles, les matériaux originaux, la méthode spécifique et les preuves indépendantes, livrez un prompt utilisable | dev-sharpen |
| Reprise d'un module inconnu | Parcourez un cas d'utilisation réel en suivant les entrées, la logique métier, le stockage, les retours et les chemins d'échec | dev-learn |
| Incompréhension de l'existence d'une conception historique | Distinguez le comportement actuel, la raison à l'époque et les suppositions, retracez le code et les preuves de décision disponibles | dev-why |
| Compromis substantiel sur les limites ou les interfaces | Comparez différentes structures ; jugez en fonction de l'expérience de l'appelant, de la propriété de l'état et des termes du domaine | dev-architecture |
| Un modèle TLA+ existe ou doit être créé, besoin d'un diagramme d'état avec résultats de vérification | Exécutez TLC, générez des marqueurs de règle et le contre-exemple le plus court, vérifiez progressivement avec le code réel | dev-statechart |
| Besoin de vérifier des propriétés critiques, de choisir un outil formel ou de maintenir un modèle | Clarifiez les propriétés, hypothèses et limites, exécutez la vérification et identifiez la dérive du modèle ; l'explication de diagramme normal n'entre pas automatiquement dans ce processus | dev-formal-verify |
| Implique des pages, interactions, systèmes de conception ou vérification visuelle | Utilisez les composants et tokens du code réel ; lisez les spécifications de conception selon le contexte produit ou marketing, sans nécessiter de compte d'outil de design | dev-ui-design |
| Besoin ne peut pas être livré de manière fiable en une seule fois | Découpez en tranches verticales vérifiables, dépendances explicites, exécutez d'abord la chaîne minimale complète | dev-plan |
| Travaux non conflictuels ou différentes solutions à comparer | Attribuez le périmètre d'écriture et les règles de vérification, puis intégrez et validez le résultat final | dev-parallel |
| Spécification ou tranche prête pour l'implémentation | Implémentez selon les normes d'ingénierie existantes, connectez le comportement réel, vérifiez l'artefact actuel | dev-build |
| Issue normale, erreur CLI/API/UI ou échec de vérification | Reproduisez le long de l'entrée réelle et localisez la cause racine ; n'entrez dans le processus de mesure que si la cible est un indicateur de performance | dev-debug |
| L'utilisateur spécifie un développement piloté par les tests, ou l'implémentation actuelle a choisi le TDD | Complétez un par un les tests échoués et l'implémentation minimale sur l'interface publique ; les tests ajoutés à un comportement correct existant n'entrent pas automatiquement dans le cycle rouge-vert | dev-tdd |
| Erreurs similaires récurrentes ou contraintes clés facilement contournées | Améliorez d'abord les types, les interfaces et la propriété de l'état ; ajoutez des règles exécutables si la valeur réelle est démontrée | dev-guardrails |
| Implémentation terminée | Vérifiez séparément la conformité aux spécifications et la qualité d'ingénierie ; corrigez les vrais problèmes | dev-review |
| Besoin de prouver que les parcours utilisateur réels fonctionnent | Pilotez l'application réelle, vérifiez les résultats et les effets secondaires, maintenez une méthode de vérification reproductible | dev-verify |
| Objectif : améliorer la latence, le débit, les ressources ou d'autres indicateurs mesurés | Fixez la charge de travail et la métrique, effectuez la collecte de preuves, l'optimisation ou la comparaison équitable, réutilisez la même base de référence | dev-benchmark |
| L'objectif inclut la mise en production | Confirmez l'environnement et la version, exécutez le déploiement autorisé, vérifiez le service réel et enregistrez | dev-deploy |
| Besoin de documentation claire, notes de commit ou résumé de PR | Organisez les informations selon les questions du lecteur, fournissez le comportement spécifique, les preuves et les compromis nécessaires | dev-writing |
| Un besoin a été livré ou clairement abandonné | Organisez les nouvelles connaissances, corrigez les conflits, conservez les justifications valables et archivez le processus | dev-archive |
Implémentez directement une spécification existante ; livrez seulement une conception si seule une conception est demandée ; restez à l'explication si seule une explication est demandée. Lisez Avancement et reprise pour gérer le parallélisme et les interruptions. Lorsque le besoin doit être affiné, lisez Enchaînement des phases du besoin à l'implémentation ; lors de l'exécution d'une tâche choisie, lisez Méthode d'exécution d'ingénierie ; ils complètent l'étape en cours, ne re-sélectionnent pas une étape déjà accomplie.
Lorsqu'aucun processus prêt à l'emploi ne convient à une tâche complexe, utilisez Méthode d'exécution personnalisée pour former des unités vérifiables et continuer le travail autorisé. Pour l'enregistrement et la revue a posteriori des tâches longues, utilisez Méthode de preuve de décision pour vérifier la correspondance entre les décisions, les alternatives et les preuves réelles ; si seule une revue est demandée, livrez les résultats d'audit, ne poursuivez pas automatiquement la migration ou l'implémentation. La recherche de la raison d'une conception à l'époque relève de dev-why. Lorsque l'utilisateur souhaite explicitement construire un tableau de bord d'état opérationnel, traitez-le comme une tâche d'implémentation ; pour une simple requête d'avancement, utilisez dev-status.
Permettre la continuité du travail
Les nouveaux éléments de projet ajoutés par cet ensemble de skills sont unifiés sous la racine .agents/wtadev/, en utilisant les partitions suivantes selon les besoins. Les éléments existants sont consultés à leur emplacement réel et les références nécessaires sont conservées ; ne les déplacez que sur demande explicite de migration, en conservant le contenu, l'identifiant et les liens valides. Lorsque l'utilisateur spécifie explicitement un autre emplacement pour cette session, suivez ses instructions :
.agents/wtadev/changes/<date-sujet>/: brief, spec, plan, progrès, preuves de l'exigence en cours, créés selon les besoins..agents/wtadev/notes/: termes validés, contexte, décisions, leçons d'erreurs et compréhension des modules ; le fichier d'entréeindex.mdsert uniquement de guide..agents/wtadev/deploy/<environnement>/: manuels de déploiement et historique des versions sousreleases/..agents/wtadev/archive/changes/,.agents/wtadev/archive/notes/: travaux terminés et connaissances historiques, ne représentant pas explicitement le comportement actuel.
Ces éléments sont les données du projet cible, ils ne doivent pas être écrits dans le package d'installation .agents/skills/. Pour une reprise, utilisez le Modèle de passation, ne laissant que le résultat actuel, les preuves, les questions en suspens et les prochaines étapes.
Clôture
Confronté à l'objectif de livraison initial, fournissez les modifications réelles, les preuves de vérification de la version actuelle, l'adresse de livraison ou le commit, ainsi que les parties effectivement non terminées. Si la mise en production est nécessaire mais pas encore déployée, écrivez explicitement « implémentation terminée, déploiement non terminé » ; après un déploiement réussi, intégrez les connaissances réutilisables et les références au code le plus récent dans le projet, sans remplir AGENTS.md avec l'intégralité des logs de chat.
Documentation locale complète
Consultez Index de la documentation pour choisir les processus complets, les règles de vérification, les exemples et les modèles dans ce skill. Toutes les ressources nécessaires à l'exécution se trouvent dans ce package, sans dépendre de l'installation d'autres skills ; lisez uniquement le contenu nécessaire à la branche de la tâche en cours.