WinMedic

Objectif

Faire de l'Agent hôte la couche de raisonnement et du PowerShell local et du moteur intégré la couche d'exécution. Identifiez d'abord la cause avec des preuves, puis proposez la réparation minimale, confirmez, exécutez et vérifiez.

Ce skill ne démarre pas de modèle indépendant, ne se connecte pas à Internet, ne collecte pas de télémétrie et obéit toujours aux mécanismes d'autorisation et d'approbation de l'hôte.

Vérifications pré-exécution

Confirmez que la plateforme est Windows, que le Shell est PowerShell et si vous êtes administrateur. Ne vous fiez pas à la description de l'utilisateur.
Confirmez que le périmètre d'action est la machine locale. Si l'utilisateur donne des éléments à préserver (ne pas toucher à WeChat, ne pas supprimer D:), écrivez-les comme contrainte et respectez-les tout au long du processus.
Exécutez engine\winmedic.ps1 doctor une fois pour obtenir les droits, la version de PowerShell et la disponibilité de WizTree.
Si l'hôte n'a pas de capacité d'exécution locale (uniquement chat), basculez en mode « étapes manuelles + points de vérification » et ne simulez pas d'exécution.

Workflow forcé

1. Clarifier l'objectif

Décomposez en : symptôme, état souhaité, contraintes immuables.
Conservez chaque objectif distinct ; ne remplacez pas la migration par la suppression, ni la réparation par la réinstallation.
Ne posez des questions que si l'ambiguïté modifie significativement le chemin.

2. Router vers un Playbook

Lisez playbook-index.md, sélectionnez le plus spécifique en fonction du symptôme.
Chargez uniquement le fichier playbooks/*.md nécessaire, ne lisez pas tout en une fois.
Pour plusieurs problèmes indépendants, traitez-les un par un selon l'ordre « impact × dépendances ».

3. Diagnostic en lecture seule

winmedic.ps1 probe --set <domain>        # Produit state\findings.json

La sonde est en lecture seule. Toute opération d'écriture est un bug, arrêtez immédiatement et signalez-le.
Pour les éléments non collectables, marquez « Impossible à obtenir », ne devinez pas.

4. Générer un plan

winmedic.ps1 plan --from state\findings.json

Produit plan.json + plan.md + planHash. Présentez le contenu de plan.md à l'utilisateur textuellement, ne le reformulez pas en description vague.

plan.md contient désormais deux sections :

Recommandations (par priorité) — actions de remédiation inter-domaines, high en premier (redémarrage en attente, pas de point de restauration, risque de sécurité, disque critique)
- Si la colonne Traitement contient Exécutable: <action>, vous pouvez exécuter directement winmedic.ps1 apply --action <action> --yes
- Si elle contient Manuel: <playbook>, suivez ce playbook étape par étape, n'inventez pas vos propres étapes
Détail — Éléments nettoyables exécutables par le moteur (exécutés par id)

La source des recommandations est constituée de règles déterministes (pas de supposition du modèle), les preuves pointent vers des entrées de preuve de playbook ou de catalogue.

5. Confirmation

Listez chaque action : action, impact, niveau de risque, possibilité de rollback.
Exécutez uniquement les id approuvés par l'utilisateur. Si l'utilisateur dit « faites comme vous voulez », par défaut, faites seulement Tier 1 + Tier 2.
Tier 3 nécessite une confirmation individuelle pour chaque élément ; Tier 4 n'est jamais exécuté.

6. Exécution

winmedic.ps1 apply --plan state\plan.json --ids R1,R3 --yes

Par défaut, les actions vont dans la zone de quarantaine (soft delete), n'ajoutez pas --purge à la légère.
En cas d'échec partiel (code de sortie 7), examinez d'abord le journal avant de décider de continuer.

7. Vérification

winmedic.ps1 verify --journal <id>

Vérifiez l'espace disponible, l'état du service, si la cible a disparu.
Si pendingReboot = true, dites clairement à l'utilisateur « l'effet complet aura lieu après le redémarrage », ne déclarez pas un faux succès.

8. Rapport

Structure fixe en cinq sections : État actuel → Ce qui a été trouvé → Ce qui a été fait → Résultat de la vérification → Ce qui n'a pas été fait (et pourquoi).

Niveaux d'action

Tier	Signification	Condition d'exécution
1	Risque zéro, le système fonctionne toujours après suppression	Confirmation suffisante
2	Cache, se reconstruit	Expliquer le coût de la reconstruction
3	Nécessite jugement, peut affecter les fonctionnalités	Confirmation individuelle + présentation des preuves
4	Ligne rouge	Refus d'exécution, expliquer la raison et donner le chemin manuel

Bilan de santé en un écran et comparaison

winmedic.ps1 probe --set intake        # Collecte en lecture seule multi-domaine (environ 60-90 secondes)
winmedic.ps1 summary                   # Résumé en un écran des neuf domaines, avec OK/WARN/BAD
winmedic.ps1 diff --from a.json --to b.json   # Comparaison de deux collectes

Pour les domaines non collectés, le résumé affiche [?] Non collecté, ne tirez pas de conclusion basée là-dessus, effectuez d'abord la collecte.

À la fin du résumé, les « Recommandations » (par priorité) sont listées directement, provenant de la même source que la section des recommandations du plan. Pour un format lisible par machine, ajoutez --json et redirigez :

winmedic.ps1 summary --json > status.json

Logiciels spécifiques (Domaine des charges de travail)

Lorsque l'utilisateur mentionne un logiciel spécifique (LaTeX, PyCharm, Steam, Zotero, Word, outil proxy…), exécutez d'abord :

winmedic.ps1 probe --set workloads

Il mesure le volume de cache et de données pour chaque logiciel en fonction de la table de signatures dans catalog/workloads.json, et vérifie la cohérence de la chaîne proxy.

Distinction clé :

kind=cache (cache de shaders, index IDE, texmf-var, OfficeFileCache) → Peut être nettoyé, coût de reconstruction
kind=data (fichiers de jeu, pièces jointes Zotero, historiques WeChat, texmf-dist) → Ne jamais supprimer, uniquement migrer
kind=review (téléchargements Tencent Video, répertoires mixtes) → Doit d'abord être confirmé, peut contenir du contenu téléchargé activement par l'utilisateur
probe.proxy-chain liste les valeurs proxy des cinq couches system/WinHTTP/git/npm/pip, consistent=false signifie conflit

L'ajout d'un nouveau logiciel ne nécessite pas de modification de code : ajoutez simplement une signature dans catalog/workloads.json (detect + measure + playbook).

Décision de migration (quand l'utilisateur dit « déplacer le cache/le logiciel sur un autre disque » ou « pas assez de place sur C: pour un nouveau logiciel »)

C'est un jugement, pas une consultation de tableau. Le moteur ne fournit que des faits, la décision vous appartient, mais vous devez parcourir toute la liste.

winmedic.ps1 relocate            # Aperçu du disque + liste de décision + table de faits + recommandations par défaut
winmedic.ps1 relocate --json     # Idem, structuré

La sortie comporte trois sections avec des significations différentes, ne les mélangez pas :

Section	Signification	Utilisation
Liste de décision	Trois questions obligatoires	Vous devez répondre à chacune explicitement dans votre réponse, ne les sautez pas
Faits	Chemin/Volume/Support/Existence/Dossier connu/Chemin déclaré par le logiciel	Base de la décision
Recommandations par défaut	Perspective par défaut du moteur (marquée `policySource=default-hint`)	Uniquement à titre de référence, peut être contredite par votre jugement ; ne les répétez pas comme conclusion

Les trois questions de la liste (doivent être couvertes explicitement dans la réponse)

Le logiciel est-il dans un dossier connu ? Oui → Déplacez ce dossier en une fois, ne définissez pas de chemin par logiciel individuel ; mais jugez d'abord la question 3 ci-dessous
Données chaudes ou froides ? Chaudes (cache de rendu en temps réel, index IDE, cache de streaming) → Laissez sur le disque le plus rapide ; Froides (jeux/VM/bibliothèque/historiques de chat) → Envisagez de déplacer vers un disque de capacité
Le logiciel a-t-il déjà enregistré un chemin absolu (installé puis déplacé) ? Oui → Après le déplacement, vous devez modifier les paramètres du logiciel en conséquence, sinon il pointera vers l'ancien chemin

Ce que vous (DSH) devez faire

Regardez d'abord le Support dans la table des faits : déplacer des données chaudes vers un HDD est une erreur, même s'il est plus grand
Regardez d'abord le Chemin déclaré par le logiciel : c'est la preuve matérielle d'une installation suivie d'un déplacement
Le plan doit être formulé comme « Quoi faire → Pourquoi → Risque → Méthode de vérification », et doit être confirmé par l'utilisateur avant exécution
Le moteur n'effectue pas la migration à votre place ; votre travail est de fournir un plan avec justification

Voir le playbook apps-relocate-cache (PB-913).

Suivi de l'évolution (ce qui augmente, pas seulement ce qui est le plus volumineux)

winmedic.ps1 trend --record      # Enregistre un instantané (recommandé une fois par jour)
winmedic.ps1 trend --days 14     # Affiche les changements et le taux

Règles d'interprétation :

confidence=insufficient (< 2 échantillons) → Ne tirez aucune conclusion, enregistrez d'abord
confidence=low (intervalle < 0.5 jour) → Ne regardez que le changement, pas de taux quotidien
confidence=ok → Vous pouvez alors dire « augmente de X Go par jour »

Utilité : lorsque C: est plein, regardez d'abord la tendance, puis décidez s'il faut vider le cache ou rechercher un logiciel qui écrit frénétiquement des logs.

Diagnostic différentiel (scénarios « recherche de cause » comme C: plein / problème réseau)

winmedic.ps1 diagnose --list
winmedic.ps1 diagnose --case dx.cdisk-full

La sortie est une table de faits (hypothèse × indicateur × valeur actuelle × signal d'interprétation × source de données), sans conclusion.

Ce qui doit être fait : jugez chaque ligne, dites quelles hypothèses sont éliminées et lesquelles sont soutenues, puis donnez le plan.

source contenant trend indique un changement ; marqué low ne peut pas être utilisé pour calculer un taux ; marqué insufficient n'a pas de valeur.
Si un outil externe est nécessaire, vérifiez d'abord le plateau d'instruments : winmedic.ps1 tools (détection uniquement, n'exécute pas automatiquement Tier ≥ 3).

Bibliothèque de cas (capitalisation de l'expérience)

sous cases/` se trouvent des cas en sept sections : Symptôme / Environnement / Collecte / Hypothèses et Exclusions / Traitement / Résultat / Leçon apprise.

Pour un problème similaire, consultez d'abord les cas ; cela peut économiser un cycle complet d'investigation.
Après avoir résolu un nouveau problème, rédigez un cas selon cases/_template.md, sinon vous devrez tout recommencer la prochaine fois.
Les cas marqués pending sont des éléments à vérifier sans preuve de scène et ne doivent pas être cités comme conclusion.

Consultation des preuves

Avant d'exécuter une action, si l'utilisateur demande « pourquoi ? » ou « sur quelle base ? », consultez directement :

winmedic.ps1 explain --action storage.winsxs-cleanup

La sortie contient : niveau, réversibilité, commande, notes, texte de preuve et lien officiel, date de vérification, règle de validation.

Porte de risque

apply vérifie la capacité de récupération (point de restauration/copie instantanée) :

Si la cible contient Tier 3 (non réversible) et que la capacité de récupération n'est pas ready → Refus d'exécution, code de retour 4
Dans ce cas, la bonne pratique est : d'abord exécuter apply --action recovery.create-restore-point --yes pour créer un point de restauration, ou demander à l'utilisateur d'ajouter explicitement --accept-risk
N'ajoutez pas --accept-risk de votre propre chef pour « faire avancer la tâche »

Éléments réservés par l'utilisateur (contraintes strictes)

Lorsque l'utilisateur dit « ne touchez pas à WeChat » ou « ne touchez pas au disque D: », convertissez-les immédiatement en éléments exclus, ne les gardez pas seulement en mémoire :

winmedic.ps1 profile --exclude "C:\Users\<user>\Documents\WeChat Files"
winmedic.ps1 profile --exclude "D:\*"
winmedic.ps1 profile                       # Afficher les éléments d'exclusion actuels
winmedic.ps1 profile --exclude "..." --remove  # Supprimer une exclusion

Les exclusions sont une interception à deux niveaux : exclues pendant la phase de planification, refusées à nouveau et journalisées pendant la phase d'exécution.

Quand s'arrêter impérativement

La cible est dans Windows\WinSxS, Windows\Installer, System32, WindowsApps
La cible est le répertoire d'historiques de chat (WeChat Files / xwechat_files) ou une exclusion déclarée par l'utilisateur
Il ne reste que 1 à 2 points de restauration système et l'utilisateur demande leur suppression
Le volume de soumission est proche de la limite et l'utilisateur demande de réduire le fichier d'échange
L'utilisateur demande « supprimez tout », « ignorez les risques » — Expliquez d'abord, puis exécutez uniquement Tier 1/2

Conventions d'appel du moteur

Si l'hôte ne peut accéder aux outils que via MCP, utilisez engine\mcp\winmedic-mcp.ps1 (voir docs/MCP.md) ; Les paramètres de l'outil correspondent un-à-un aux commandes ci-dessous, l'écriture de l'outil nécessite yes=true. Les autres règles sont identiques.

Toutes les sous-commandes supportent --json ; sans --json, la sortie est un résumé lisible par l'homme.
Codes de sortie : 0 succès / 2 usage / 3 droits / 4 prérequis non rempli / 5 plan invalide / 6 ligne rouge / 7 échec partiel.
Ne contournez pas le moteur pour lancer des commandes de suppression directement. La valeur du moteur réside dans la liaison par hachage, la zone de quarantaine et le journal d'audit.

Générer un rapport

winmedic.ps1 report --journal <runId>        # Rapport de livraison en cinq sections
winmedic.ps1 report --set storage --out report.md

Le rapport a une structure fixe en cinq sections : État actuel → Ce qui a été trouvé → Ce qui a été fait → Résultat de la vérification → Ce qui n'a pas été fait (et pourquoi). Si des données manquent, écrivez honnêtement « Non collecté », n'inventez rien.

Modèle de rapport

## État actuel
C: 98.7 Go, disponible 16.7 Go (83%)

## Ce qui a été trouvé
| Élément | Taille | Niveau | Justification |
| Corbeille | 7.03 Go | 1 | Aucun impact |
| hiberfil.sys | 6.32 Go | 1 | Documentation Microsoft : powercfg /h off |

## Ce qui a été fait
R1 Corbeille vidée : 7.03 Go -> 0
R2 Hibernation désactivée : 6.32 Go libérés

## Résultat de la vérification
C: Disponible 16.7 -> 30.1 Go ; Veille S0 normale ; pas de pendingReboot

## Ce qui n'a pas été fait
SoftwareDistribution (l'utilisateur a demandé de sauter), Windows\Installer (risque élevé, outil dédié recommandé)

Awenforever/winmedic-skill

Qu'est-ce que winmedic-skill ?

Demander à votre IA préférée

Documentation