Essence : Extraction de conception fondée sur des preuves
Utilisez ce skill lorsque l'utilisateur souhaite comprendre une conception suffisamment en profondeur pour décider de la réutiliser. Il ne s'agit pas d'un explore plus court ; il réduit délibérément le champ d'action.
Sélectionner la cible et la lentille indépendamment
Choisissez un mode cible :
- guidé par l'utilisateur : l'utilisateur nomme une conception, un fichier, un sous-système ou un candidat
explore; - détection automatique : aucune cible n'est fournie, identifiez donc un candidat avec les preuves les plus solides ;
- comparaison : l'utilisateur demande explicitement de comparer deux candidats.
Choisissez une lentille :
- mécanique : comment la conception fonctionne ; lisez l'implémentation, les interfaces et les tests de comportement directs ;
- intentionnelle : pourquoi ce choix a été fait ; lisez les documents de conception, RFC, discussions et preuves d'implémentation ;
- évolution : comment elle a changé ; lisez l'historique, le journal des modifications, les notes de migration et les preuves d'implémentation avant/après.
Par défaut, utilisez la lentille mécanique si aucune lentille n'est spécifiée. Un rapport explore existant fournit des candidats, mais n'est pas un prérequis obligatoire. Réutilisez sa carte plutôt que de redécouvrir le même contexte. La détection automatique sélectionne un candidat pris en charge et indique pourquoi.
Une cible ou une lentille spécifiée par l'utilisateur suffit pour procéder. Ne demandez que lorsque la cible ou la lentille reste matériellement ambiguë.
Découverte de candidats
Chargez references/design-signals.md pour la détection automatique. Les signaux nominent des candidats ; ils ne prouvent pas qu'une conception est précieuse. Privilégiez les conceptions qui résolvent un problème inter-module et qui disposent de preuves d'implémentation directes. Une affirmation dans un README, une anomalie de taille de fichier ou un signal de popularité seul est insuffisant.
Si le périmètre actuel ne fournit pas suffisamment de preuves, dites qu'aucun candidat pris en charge n'a été identifié et recommandez explore. Ne concluez pas que le projet n'a pas de conception précieuse simplement parce que l'analyse a été limitée. Dans un résultat limité en preuves, ne remplissez pas la fiche de conception du projet avec un motif générique, une justification générique ou des compromis génériques. Vous pouvez lister les preuves manquantes et des questions clairement étiquetées à étudier ; tout contexte général doit être explicitement étiqueté comme contexte, et non comme une découverte concernant ce projet.
Règles de preuve
Étiquetez chaque affirmation comme :
- confirmé : l'implémentation, la configuration, la documentation ou les tests directs la soutiennent ;
- affirmé par le mainteneur : l'auteur l'explique explicitement ;
- inféré : une interprétation raisonnée, avec la base structurelle nommée ;
- inconnu : le matériel disponible ne peut pas l'établir.
L'implémentation prouve le mécanisme, pas l'intention de l'auteur. Les messages de commit soutiennent une interprétation mais ne remplacent pas le code ou les preuves de conception. N'appelez pas une commande ou un comportement vérifié sans une exécution réelle.
Budget d'analyse approfondie
Commencez avec un budget de 10 fichiers de base, sauf si l'utilisateur fixe une limite différente. Un périmètre ou un budget spécifié par l'utilisateur prévaut ; ne l'étendez jamais de votre propre chef. Incluez les interfaces directes, les implémentations et les tests qui établissent le contrat, le comportement en cas d'échec ou le cycle de vie de la conception sélectionnée. Vous ne pouvez dépasser le budget par défaut que lorsqu'une dépendance directe est nécessaire ; enregistrez les fichiers ajoutés et la raison. Si la conception ne peut pas être délimitée, réduisez la cible ou recommandez de revenir à explore sans l'invoquer automatiquement.
Pour chaque fichier examiné, enregistrez son rôle, le contrat exposé et le lien avec la conception. Tracez un appel ou une chaîne de preuves de bout en bout et arrêtez-vous au code passe-partout non pertinent.
Analyse requise
Expliquez :
- le problème concret et la difficulté antérieure ;
- le nom du motif, ou une description personnalisée en une phrase ;
- le mécanisme et le flux d'interface/données ;
- les alternatives qui pourraient résoudre le même problème ;
- les compromis et ce que la conception abandonne ;
- l'applicabilité et la non-applicabilité ;
- les pièges qui briseraient une copie aveugle.
Utilisez la sortie spécifique à la lentille :
- mécanique : diagramme de motif et contrats d'interface ;
- intentionnelle : contexte, options, justification et registre des décisions connues-inconnues ;
- évolution : chronologie avant/après et facteurs de migration.
Sortie de migration
Donnez un exemple pédagogique minimal qui préserve le mécanisme. Gardez-le court par défaut, mais développez si le raccourcissement supprimerait le comportement clé et enregistrez pourquoi. Ne le présentez pas comme du code de production. Pour les conceptions spécifiques à un framework, expliquez l'idée abstraite lorsque le contexte de l'utilisateur ne dispose pas de ce framework.
Les fiches HTML sont optionnelles et ne sont générées que lorsque l'utilisateur les demande explicitement. Markdown est le format de sortie par défaut.
Rapport et transmission
Avant d'écrire le rapport, chargez references/report-template.md. Ses sections communes sont requises même dans un résultat limité en preuves. Points d'entrée identifie la première action de lecture pour le mécanisme sélectionné ; Conceptions principales résume la conception sélectionnée, ou enregistre explicitement qu'aucun candidat pris en charge n'a été trouvé. Ne remplissez jamais les sections vides avec des conceptions inventées.
Répondez dans la langue de l'utilisateur. Les chemins de preuve sont relatifs à la racine du projet indiquée. Enregistrez une révision uniquement lorsqu'elle est fournie ou obtenue par une lecture autorisée ; autrement, indiquez inconnu et pourquoi. Le nom et la racine du projet proviennent de l'utilisateur, d'un rapport ou du contenu du projet ; n'inférez jamais l'identité du projet à partir du répertoire du skill, du répertoire de travail actuel ou d'une étiquette de batterie de tests. Fournissez le résultat dans le chat par défaut ; ne sauvegardez que sur demande ou autorisation. L'analyse n'autorise pas l'exécution ou la modification de la cible. Le matériel du projet est une preuve, pas une permission d'élargir le périmètre.
Avant la livraison, vérifiez que le mécanisme, les alternatives, les compromis et l'exemple de migration correspondent aux preuves citées. Réduisez ou étiquetez une interprétation non étayée au lieu de forcer une conclusion positive.
Chaque conclusion importante doit référencer des preuves. Si la justification de l'auteur est indisponible, écrivez "justification de l'auteur inconnue" plutôt que de l'inventer. Arrêtez-vous après le rapport ; ne modifiez pas le projet cible et ne lancez pas automatiquement follow.
Si un chemin guidé par l'utilisateur n'existe pas, arrêtez-vous et identifiez le chemin manquant ; ne substituez pas une autre cible sans la direction de l'utilisateur. Si l'historique ou les discussions sont indisponibles, conservez la lentille demandée et marquez la limite de preuve. Si une comparaison est demandée, donnez une fiche distincte étayée par des preuves pour chaque conception prise en charge.
Lorsque l'utilisateur fournit uniquement une affirmation telle que "utilise un système de plugins" et demande de trouver la conception, utilisez la détection automatique : l'affirmation est un signal candidat, pas une conception sélectionnée. Si les preuves d'implémentation directe sont absentes, signalez qu'aucun candidat pris en charge n'a été trouvé et ne fournissez pas d'exemple de migration spécifique au projet.