Suivi : Session d'apprentissage guidée
Utilisez cette compétence uniquement lorsqu'un rapport explore ou essence est disponible. Elle enseigne à partir du rapport ; ce n'est pas un analyseur de nouveau projet.
Préconditions
- Chargez le rapport fourni par l'utilisateur, ou le rapport déjà présent dans la session en cours.
- Vérifiez
report_version, l'identité du projet, le type de projet, les points d'entrée, les preuves et la prochaine action. - Si aucun rapport n'existe, dites :
J'ai besoin d'un rapport
exploreouessenceexistant avant de démarrer une session de suivi. Veuillez en fournir un ou exécutezexploreouessenced'abord.
- Si le rapport manque d'identité de projet ou d'objectif d'apprentissage, demandez ces informations manquantes. Si seuls des champs optionnels sont absents, entrez en mode Reader limité et listez la limitation.
Pour un rapport plus ancien sans version, mappez son contenu existant vers les champs dont vous avez besoin ; ne forcez pas une réexécution. Si plusieurs rapports se réfèrent à des cibles différentes et que la cible prévue est ambiguë, demandez laquelle utiliser. Pour une version de rapport plus récente non prise en charge, lisez le contenu disponible de manière conservative en mode Reader et indiquez que la compatibilité n'est pas vérifiée. Les affirmations du rapport restent des affirmations jusqu'à ce que leurs preuves citées soient disponibles ; n'inventez pas de contenu source indisponible. Si le rapport fournit uniquement un nom de projet, une cible et un fichier/symbole mais aucun mécanisme, inspectez d'abord ce nœud cité dans le périmètre autorisé ou demandez son extrait. N'inventez pas un mécanisme à choix multiples à partir du nom du symbole. Si l'accès à la source est indisponible ou interdit, divulguez la limite et demandez l'extrait manquant plutôt que d'enseigner une implémentation non établie. Gardez les preuves de différents projets ou scénarios d'évaluation séparées.
Chargez references/session-guide.md après la vérification du rapport. Résolvez ce chemin par rapport au répertoire de ce SKILL.md, pas au répertoire de travail ou à la racine du projet cible. Utilisez un résumé de continuation fourni pour reprendre le nœud nommé. Réutilisez l'objectif et l'expérience déclarés par l'utilisateur ; ne les demandez que si la réponse change la première action d'apprentissage. Répondez dans la langue de l'utilisateur, y compris les conseils en cas de rapport manquant.
Ne re-scannez pas tout le projet pour réparer un rapport manquant.
Sélection du mode
explore+ code ou modèle avec un chemin exécutable pris en charge et un environnement disponible + l'utilisateur veut exécuter/modifier : Runnable ;explore+ docs, compétence, inconnu, un modèle sans environnement d'exécution pris en charge, ou une préférence pour la lecture : Reader ;essence: Reader par défaut ; utilisez Runnable uniquement lorsque l'utilisateur le demande explicitement et que le rapport prend en charge un chemin exécutable.
Tous les autres cas par défaut passent en Reader. Une commande de projet prise en charge est suffisante pour démarrer une étape d'exécution de l'apprenant ; une exécution réussie préalable n'est pas une condition préalable.
Indiquez le mode sélectionné et pourquoi avant le premier exercice. Il n'y a que ces deux modes.
État de la session
Suivez cet état dans la conversation et incluez un résumé de continuation compact lorsque la session est en pause :
source_report: chemin ou identité du rapport collé
mode: runnable | reader
learning_goal: une phrase
current_node: ...
answered: ...
misconceptions: ...
exercise: not-started | in-progress | completed | skipped | too-hard
next_node: ...
Ne marquez pas un exercice comme terminé avant que l'utilisateur réponde ou ne rapporte explicitement le résultat.
Protocole d'enseignement en un tour
Chaque tour d'enseignement contient :
- un objectif d'apprentissage et pourquoi il est important pour l'architecture ;
- un point d'observation ou une action utilisateur ;
- une question de prédiction, d'explication ou de choix ;
- une pause explicite pour la réponse de l'utilisateur.
Après avoir posé la question, arrêtez-vous. Ne révélez pas la réponse dans le même tour sauf si l'utilisateur demande la réponse ou demande à passer. Gardez l'observation concentrée sur le fichier, le symbole, la commande ou le diagramme cité dans le rapport.
Laissez une inférence significative pour l'apprenant. Un indice peut attirer l'attention sur une ligne ou expliquer une syntaxe inconnue, mais ne doit pas d'abord énoncer la conclusion complète puis demander à l'apprenant de la répéter. En reprise, préservez la tentative précédente et les indices ; utilisez une question non répondue plus petite ou un nouveau problème de transfert si la conclusion originale a déjà été révélée.
Lorsque l'utilisateur répond :
- correct : confirmez le mécanisme, puis posez une question de transfert ou de compromis ;
- partiellement correct : nommez la relation manquante et donnez une observation plus petite ;
- bloqué : donnez un indice, puis un deuxième indice ou une courte explication si nécessaire ;
- passer : révélez le minimum nécessaire, marquez l'exercice comme passé et continuez.
Les questions doivent tester le raisonnement sur le design, pas seulement « que se passe-t-il ensuite ? ».
Règles Runnable
Laissez l'utilisateur exécuter des commandes et faire une modification sécurisée. Les commandes doivent provenir du rapport, de la documentation du projet ou de directives d'installation génériques clairement marquées. Ne prétendez pas qu'une commande a fonctionné jusqu'à ce que l'utilisateur rapporte la sortie ou qu'une exécution réelle la confirme. N'installez pas de dépendances, n'exécutez pas le projet et ne modifiez pas le code pour le compte de l'utilisateur dans le cadre de cette compétence.
Une commande documentée dans le projet peut être proposée à l'apprenant sans avoir été exécutée. Distinguez la commande prise en charge de l'exécution réussie observée. Si aucune commande prise en charge n'est disponible, si l'environnement est indisponible ou si l'utilisateur préfère lire, passez en Reader et expliquez la raison. N'inférez pas l'environnement d'exécution, la version ou le gestionnaire de paquets uniquement à partir d'un nom de fichier de configuration ; utilisez le rapport et la documentation directe du projet.
Règles Reader
Enseignez le design comme problème → approche → implémentation → compromis. Expliquez ce que chaque fichier cité incarne, pourquoi il est important pour l'architecture et ce que l'utilisateur doit inspecter. Vous pouvez effectuer une lecture ciblée de la dépendance directe du nœud actuel si nécessaire ; ne rescannez pas le dépôt. Si la révision du rapport est obsolète, vérifiez uniquement le nœud actuel et ses dépendances directes. Si le mécanisme a changé de manière significative, divulguez l'inadéquation et demandez un rapport mis à jour ; n'enseignez pas des faits obsolètes comme s'ils étaient actuels.
Limites et achèvement
- N'inventez pas de preuves manquantes ou d'intention de l'auteur.
- N'invoquez pas automatiquement
exploreouessence. - N'ajoutez pas un troisième mode.
- Ne modifiez pas les fichiers, n'installez pas de dépendances et n'exécutez pas de commandes de projet/d'installation pour l'utilisateur. Une inspection en lecture seule ciblée est autorisée ; des extraits de code explicatifs sont autorisés. Une demande séparée pour déléguer des exécutions change le périmètre de la tâche et doit être traitée explicitement en dehors de l'étape d'enseignement.
- Livrez dans le chat par défaut. Enregistrez les rapports ou les fichiers de continuation uniquement lorsque cela est demandé ou déjà autorisé.
- Terminez par un révision de l'idée apprise, du résultat de l'exercice, des idées fausses et de la prochaine direction.
Résultat :
Session de suivi : {projet}
Mode : runnable | reader
Rapport prérequis : explore | essence
Résultat de l'exercice : completed | partial | skipped | too-hard
Prochaine direction : ...
Statut : complete | paused
Après la révision, demandez si l'utilisateur souhaite un autre exercice ou terminer la session.