WinMedic

Ziel

Den Host-Agenten als Reasoning-Schicht und die lokale PowerShell sowie die integrierte Engine als Ausführungsschicht nutzen. Zuerst die Ursache durch Beweise lokalisieren, dann die minimalste Reparatur vorschlagen, nach Bestätigung ausführen und verifizieren.

Dieses Skill startet kein eigenständiges Modell, stellt keine Internetverbindung her, sammelt keine Telemetriedaten und unterliegt stets den Berechtigungen und Genehmigungsmechanismen des Hosts.

Überprüfung vor der Ausführung

Sicherstellen, dass die Plattform Windows, die Shell PowerShell und der aktuelle Zustand Administrator ist. Nicht aus Benutzerbeschreibungen ableiten.
Sicherstellen, dass der Wirkungsbereich der lokale Rechner ist. Vom Benutzer angegebene Ausschlüsse („nicht an die WeChat-Daten gehen“, „Laufwerk D: nicht löschen“) als Einschränkungen notieren und während des gesamten Prozesses einhalten.
Einmal engine\winmedic.ps1 doctor ausführen, um Berechtigungen/PS-Version/WizTree-Verfügbarkeit zu erhalten.
Wenn der Host keine lokale Ausführungsfähigkeit hat (nur Chat), in den Modus „manuelle Schritte + Prüfpunkte“ wechseln und nicht so tun, als würde ausgeführt.

Erzwungener Workflow

1. Zieldefinition

Aufschlüsseln in: Symptom, gewünschter Zustand, unveränderliche Einschränkungen.
Mehrere Ziele einzeln beibehalten, Löschen nicht durch Migration ersetzen, Neuinstallation nicht durch Reparatur ersetzen.
Nur bei Mehrdeutigkeit, die den Pfad signifikant ändert, nachfragen.

2. Playbook-Routing

playbook-index.md lesen und das spezifischste Playbook basierend auf dem Symptom auswählen.
Nur das benötigte playbooks/*.md laden, nicht alle auf einmal lesen.
Bei mehreren unabhängigen Problemen nacheinander vorgehen, geordnet nach „Auswirkung × Abhängigkeitsreihenfolge“.

3. Schreibgeschützte Diagnose

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

Der Probe ist schreibgeschützt. Jeder Schreibvorgang in diesem Schritt ist ein Fehler; sofort anhalten und melden.
Nicht erfassbare Punkte ehrlich als „Nicht erfassbar“ kennzeichnen, nicht raten.

4. Planerstellung

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

Ausgabe: plan.json + plan.md + planHash. Den originalen Text von plan.md dem Benutzer präsentieren, nicht durch vage Beschreibungen ersetzen.

plan.md enthält nun zwei Abschnitte:

Empfehlungen (nach Priorität) – Domainübergreifende Behandlungsvorschläge, high zuerst (Neustart ausstehend, kein Wiederherstellungspunkt, Sicherheitsrisiko, Speicherplatzalarm)
- Behandlung Spalte mit ausführbar: <action>: kann direkt mit winmedic.ps1 apply --action <action> --yes ausgeführt werden
- Mit manuell: <playbook>: die Schritte dieses Playbooks einzeln befolgen, keine eigenen Schritte erfinden
Details – Von der Engine ausführbare Bereinigungselemente (nach ID ausführen)

Die Quelle des Empfehlungsabschnitts sind deterministische Regeln (keine Modellschätzung), die Beweise verweisen auf Playbooks oder Katalogeinträge.

5. Bestätigung

Jeden Punkt einzeln auflisten: Aktion, Auswirkung, Risikostufe, Rollback-Fähigkeit.
Nur die vom Benutzer bestätigten IDs ausführen. Wenn der Benutzer „alles in Ordnung“ sagt, standardmäßig nur Tier 1 + Tier 2 ausführen.
Tier 3 muss Punkt für Punkt bestätigt werden; Tier 4 wird grundsätzlich nicht ausgeführt.

6. Ausführung

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

Standardmäßig in die Isolationszone (weicher Löschvorgang), nicht einfach --purge hinzufügen.
Bei teilweisem Fehlschlag (Exit-Code 7) zuerst das Journal prüfen, dann entscheiden, ob fortgefahren wird.

7. Verifikation

winmedic.ps1 verify --journal <id>

Verfügbaren Speicherplatz, Dienststatus, ob das Ziel verschwunden ist, überprüfen.
Wenn pendingReboot = true ist, dem Benutzer deutlich mitteilen „wird erst nach Neustart vollständig wirksam“, keinen Erfolg vortäuschen.

8. Bericht

Feste fünf Abschnitte: Aktueller Zustand → Was gefunden wurde → Was getan wurde → Verifikationsergebnis → Was nicht getan wurde (und warum).

Aktionsstufen

Stufe	Bedeutung	Ausführungsbedingung
1	Null Risiko, System läuft auch nach Löschung	Nur Bestätigung nötig
2	Cache, wird neu aufgebaut	Wiederherstellungskosten erklären
3	Beurteilung nötig, kann Funktion beeinträchtigen	Punktweise Bestätigung + Beweisvorlage
4	Rote Linie	Ausführung verweigern, Grund nennen und manuellen Pfad angeben

Übersichtsdiagnose und Vergleich

winmedic.ps1 probe --set intake        # Domainübergreifende schreibgeschützte Erfassung (ca. 60-90 Sek.)
winmedic.ps1 summary                   # Neun-Domänen-Übersicht mit OK/WARN/BAD
winmedic.ps1 diff --from a.json --to b.json   # Vergleich zweier Erfassungen

Nicht erfasste Domänen in der Zusammenfassung zeigen [?] Nicht erfasst; daraus keine Schlüsse ziehen, zuerst die Erfassung nachholen.

Am Ende der Zusammenfassung werden direkt „Empfehlungen“ (nach Priorität) aufgelistet, die aus derselben Quelle stammen wie der Empfehlungsabschnitt des plan. Für maschinenlesbare Ausgabe --json hinzufügen und umleiten:

winmedic.ps1 summary --json > status.json

Spezifische Software (Workload-Domäne)

Wenn der Benutzer eine bestimmte Software nennt (LaTeX, PyCharm, Steam, Zotero, Word, Proxy-Tool …) zuerst ausführen:

winmedic.ps1 probe --set workloads

Es misst den Cache- und Daten-Umfang jeder Software anhand der Signaturtabelle in catalog/workloads.json und prüft die Proxy-Kettenkonsistenz.

Wichtige Unterscheidungen:

kind=cache (Shader-Cache, IDE-Index, texmf-var, OfficeFileCache) → Bereinigbar, Nachteil ist der Wiederaufbau
kind=data (Spiel-Dateien, Zotero-Anhänge, WeChat-Chatprotokolle, texmf-dist) → Niemals löschen, nur Migration möglich
kind=review (Tencent Video-Downloads, gemischte Verzeichnisse) → Muss zuerst bestätigt werden, kann vom Benutzer heruntergeladene Inhalte enthalten
probe.proxy-chain listet die Proxy-Werte der fünf Ebenen system/WinHTTP/git/npm/pip auf; consistent=false bedeutet Konflikt

Das Hinzufügen neuer Software erfordert keine Codeänderungen: Einfach eine Signatur (detect + measure + playbook) in catalog/workloads.json einfügen.

Migrationsentscheidung (wenn der Benutzer sagt „Cache/Software auf ein anderes Laufwerk verschieben“ oder „neue Software passt nicht auf C:")

Dies ist eine Beurteilungsaufgabe, keine Tabellenabfrage. Die Engine liefert nur Fakten, die Lösung bestimmst du, aber du musst die Checkliste vollständig durchgehen.

winmedic.ps1 relocate            # Datenträgerübersicht + Entscheidungsliste + Fakten + Standardempfehlung
winmedic.ps1 relocate --json     # Gleiches, strukturiert

Die Ausgabe besteht aus drei Abschnitten mit unterschiedlicher Bedeutung: Nicht verwechseln

Abschnitt	Bedeutung	Verwendung
Entscheidungsliste	Drei zwingend zu beantwortende Fragen	Müssen im Antworttext Punkt für Punkt beantwortet werden, nicht überspringen
Fakten	Pfad/Umfang/Medium/Vorhandensein/Bekannte Ordner/Software-deklarierter Pfad	Entscheidungsgrundlage
Standardempfehlung	Standardansicht der Engine (gekennzeichnet mit `policySource=default-hint`)	Nur als Referenz, kann durch deine Beurteilung überschrieben werden; nicht als Schlussfolgerung direkt wiedergeben

Die drei Checklistenfragen (müssen in der Antwort explizit abgedeckt werden)

Befindet sich das Element in einem bekannten Ordner? Ja → Den gesamten Ordner einmal verschieben, keinem einzelnen Software-Pfad zuweisen; aber zuerst Punkt 3 prüfen
Heiße oder kalte Daten? Heiß (Echtzeit-Render-Cache, IDE-Index, Streaming-Cache) → Auf dem schnellsten Laufwerk belassen; Kalt (Spiele/VMs/Bibliothek/Chatprotokolle) → Erst dann Verschiebung auf ein Speicherlaufwerk in Betracht ziehen
Hat die Software bereits einen absoluten Pfad aufgezeichnet (zuerst installiert, dann verschoben)? Ja → Nach dem Verschieben muss die Softwareeinstellung synchron aktualisiert werden, sonst zeigt sie auf den alten Pfad

Deine (DSH) Aufgaben

Zuerst das Medium in der Fakten-Tabelle prüfen: Heiße Daten auf eine HDD zu verschieben ist falsch, auch wenn sie größer ist
Zuerst den Software-deklarierten Pfad prüfen: Das ist der harte Beweis für „zuerst installiert, dann verschoben“
Die Lösung sollte als „Was tun → Warum → Risiko → Verifikationsmethode“ formuliert sein und erst nach Bestätigung durch den Benutzer ausgeführt werden
Die Engine führt die Migration nicht für dich durch; deine Aufgabe ist es, eine begründete Lösung zu liefern

Siehe Playbook apps-relocate-cache (PB-913).

Krankheitsverlauf (Was wächst, nicht nur was am größten ist)

winmedic.ps1 trend --record      # Einen Snapshot speichern (empfohlen täglich)
winmedic.ps1 trend --days 14     # Änderung und Rate anzeigen

Bewertungsregeln:

confidence=insufficient (<2 Stichproben) → Keine Schlussfolgerung ziehen, zuerst aufzeichnen
confidence=low (Intervall <0.5 Tage) → Nur Änderungsmenge anzeigen, keine tägliche Rate
confidence=ok → Erst dann „Wächst um X GB pro Tag“ sagen können

Anwendung: Bei vollem C-Laufwerk zuerst den Trend prüfen, dann entscheiden, ob Cache geleert oder nach einer bestimmten Software gesucht werden soll, die massiv Logs schreibt.

Differentialdiagnose (Szenarien wie „C-Laufwerk voll“ oder „Netzwerkproblem“, die eine Ursachenforschung erfordern)

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

Die Ausgabe ist eine Faktentabelle (Hypothese × Metrik × Wert × Signal × Datenquelle), keine Schlussfolgerung.

Zu tun: Jede Zeile beurteilen, erklären, welche Hypothesen ausgeschlossen und welche gestützt werden, dann eine Lösung vorschlagen.

Wenn die Quelle trend enthält, handelt es sich um eine Änderungsmenge. Mit niedrig gekennzeichnete Werte erlauben keine Ratenberechnung. Mit ungenügend gekennzeichnete haben keinen Wert.

Bei Bedarf an externen Tools zuerst die Werkzeugliste prüfen: winmedic.ps1 tools (nur erkennen, keine automatische Ausführung von Tier ≥3).

Fallbibliothek (Erfahrungssammlung)

Unter cases/ befinden sich Fälle im Sieben-Abschnitts-Format: Symptom / Umgebung / Erfassung / Hypothesen & Ausschluss / Behandlung / Ergebnis / Lehre.

Bei gleichen Problemen zuerst die Fallbibliothek durchsuchen; das kann eine ganze Runde Fehlersuche ersparen
Nach der Lösung eines neuen Problems einen Fall nach cases/_template.md schreiben, sonst muss beim nächsten Mal wieder bei Null angefangen werden
Mit ausstehend gekennzeichnete Einträge sind noch nicht durch Beweise vor Ort gestützte Prüfpunkte und dürfen nicht als Schlussfolgerung zitiert werden

Abfrage von Nachweisen

Bevor eine Aktion ausgeführt wird, wenn der Benutzer nach dem „Warum“ oder der „Grundlage“ fragt, direkt nachschlagen:

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

Die Ausgabe enthält: Stufe, Rollback-Fähigkeit, Befehl, Hinweise, Originaltext des Nachweises und offiziellen Link, Prüfdatum, Verifikationsregel.

Risikotor

apply prüft die Wiederherstellungsfähigkeit (Wiederherstellungspunkte/Volumenschattenkopien):

Ziel enthält Tier 3 (nicht rollbackbar) und Wiederherstellungsfähigkeit ist nicht bereit → Ausführung verweigern, Rückgabecode 4
In diesem Fall korrekt vorgehen: Zuerst apply --action recovery.create-restore-point --yes ausführen, um einen Wiederherstellungspunkt zu erstellen, oder den Benutzer explizit --accept-risk hinzufügen lassen
Nicht, um die Aufgabe voranzutreiben, eigenmächtig --accept-risk hinzufügen

Benutzerausschlüsse (Harte Einschränkungen)

Wenn der Benutzer sagt „Nicht an die WeChat-Daten gehen“ oder „Laufwerk D: nicht anfassen“, sofort als Ausschluss festschreiben, nicht nur im Kopf behalten:

winmedic.ps1 profile --exclude "C:\Users\<user>\Documents\WeChat Files"
winmedic.ps1 profile --exclude "D:\*"
winmedic.ps1 profile                       # Aktuelle Ausschlüsse anzeigen
winmedic.ps1 profile --exclude "..." --remove  # Entfernen

Ausschlüsse wirken auf zwei Ebenen: Sie werden in der Planungsphase ausgeschlossen und in der Anwendungsphase erneut abgelehnt und protokolliert.

Wann unbedingt anzuhalten ist

Das Ziel sind Dateien in Windows\WinSxS, Windows\Installer, System32, WindowsApps
Das Ziel sind Chatprotokollverzeichnisse (WeChat Files / xwechat_files) oder vom Benutzer deklarierte Ausschlüsse
Es sind nur noch 1–2 Systemwiederherstellungspunkte vorhanden und der Benutzer fordert das Löschen eines Wiederherstellungspunktes
Das Einreichungsvolumen nähert sich der Obergrenze und der Benutzer fordert die Verkleinerung der Auslagerungsdatei
Der Benutzer verlangt „alles löschen“, „keine Risiken beachten“ – Zuerst erklären, dann nur Tier 1/2 ausführen

Engine-Aufrufkonvention

Wenn der Host nur über MCP auf Werkzeuge zugreifen kann, engine\mcp\winmedic-mcp.ps1 verwenden (siehe docs/MCP.md); Die Werkzeugparameter entsprechen eins zu eins den folgenden Befehlen; für Schreibwerkzeuge muss yes=true gesetzt werden. Alle anderen Regeln sind identisch.

Alle Unterbefehle unterstützen --json. Ohne --json wird eine für Menschen lesbare Zusammenfassung ausgegeben.
Exit-Codes: 0 Erfolg / 2 Verwendung / 3 Berechtigung / 4 Voraussetzung nicht erfüllt / 5 Plan ungültig / 6 Rote Linie / 7 Teilweiser Fehlschlag
Die Engine nicht umgehen und direkt Löschbefehle ausführen. Der Wert der Engine liegt in der Hash-Bindung, der Isolationszone und dem Audit-Log.

Berichtserstellung

winmedic.ps1 report --journal <runId>        # Fünf-Abschnitts-Abschlussbericht
winmedic.ps1 report --set storage --out report.md

Der Bericht besteht aus festen fünf Abschnitten: Aktueller Zustand → Was gefunden wurde → Was getan wurde → Verifikationsergebnis → Was nicht getan wurde (und warum).

Bei fehlenden Daten ehrlich „Nicht erfasst“ schreiben, nichts erfinden.

Berichtsvorlage

## Aktueller Zustand
C: 98.7 GB, verfügbar 16.7 GB (83%)

## Was gefunden wurde
| Element | Größe | Stufe | Begründung |
| Papierkorb | 7.03 GB | 1 | Keine Auswirkung |
| hiberfil.sys | 6.32 GB | 1 | Microsoft-Dokumentation: powercfg /h off |

## Was getan wurde
R1 Papierkorb leeren: 7.03 GB -> 0
R2 Ruhezustand deaktivieren: 6.32 GB freigegeben

## Verifikationsergebnis
C: verfügbar 16.7 -> 30.1 GB; Standby S0 normal; kein pendingReboot

## Was nicht getan wurde
SoftwareDistribution (vom Benutzer zum Überspringen angefordert), Windows\Installer (hohes Risiko, spezielles Tool empfohlen)

Awenforever/winmedic-skill

Was ist winmedic-skill?

In Ihrer bevorzugten KI fragen

Dokumentation