G1en-114/rtfm-first-skill

RTFM-First

Behandle die vom Benutzer bereitgestellten Handbücher als die einzige autoritative Quelle für diese Aufgabe. Schreibe keinen Code aus dem Gedächtnis oder basierend auf Online-Informationen.

Eiserne Regeln

1. Wenn ein Handbuch existiert, lies es zuerst, dann schreibe Code; API-Namen, Parameter, Standardwerte, Einheiten und Verhalten richten sich ausschließlich nach dem Handbuch.
2. Vor dem Programmieren muss die Handbuchversion mit der aktuellen Umgebungsversion abgeglichen werden (siehe „Umgebung scannen und Version abgleichen“) und dem Benutzer das Ergebnis mitgeteilt werden.
3. Gib bei der Referenzierung wichtiger Fakten aus dem Handbuch die Quelle an: .rtfm/<name>.txt:Zeilennummer oder SEITE n.
4. Bei Widersprüchen zwischen Handbuch und Code oder Umgebung: Korrigiere den Code nicht sofort nach Online-Konventionen; halte inne, erkläre die Abweichung und lass den Benutzer entscheiden.
5. Wenn kein Handbuch vorhanden ist, fordere es an oder bestätige den Pfad; beginne nicht aus dem Gedächtnis mit der Implementierung.
6. Jede „Korrektur“ muss vorher angeben, welche Regel aus dem Handbuch verletzt wird; ohne Quellenangabe darf nicht geändert werden.

Arbeitsablauf

1. Handbuch lokalisieren und extrahieren

• Wenn der Benutzer keinen Pfad angibt, durchsuche das Projekt nach Kandidaten (*.pdf, *.md, docs/**, in der README erwähnte Spezifikationen); liste mehrere Kandidaten auf und bitte den Benutzer um Bestätigung.
• Die Skripte befinden sich im Verzeichnis scripts/ neben dieser SKILL.md.
• Extrahiere einheitlich in das Verzeichnis .rtfm/ im Projektstamm (bei Git-Repository stelle sicher, dass .gitignore das Verzeichnis .rtfm/ enthält):
  • PDF: Führe das Skript scripts/extract_manual.py <manual.pdf> .rtfm/<name>.txt aus.
  • MD/TXT: Führe ebenfalls dieses Skript aus, das den Text kopiert.
• Bei mehreren Handbüchern (z. B. API-Referenz + Protokollspezifikation + SDK-Dokumentation) extrahiere alle und erstelle für jedes einen eigenen Index; gib bei Referenzen an, aus welchem Handbuch stammt.
• Wenn das PDF ein Scan ist (extrahierter Text zu kurz), melde, dass OCR erforderlich ist; versuche nicht, den Inhalt zu erraten.
• Wenn das Skript „Kein PDF-Text-Extraktor“ meldet, installiere wie empfohlen poppler-utils oder pypdf (bitte vor systemweiter Installation um Zustimmung des Benutzers) und versuche es erneut; überspringe das PDF nicht und schreibe nicht aus dem Gedächtnis.
• Lies zuerst die Titelseite/Einführung/Versionshistorie und notiere: Produktname, Handbuchversion, gültige Version, Datum, Änderungsbeschreibung.

2. Index erstellen

• Führe das Skript scripts/index_manual.py .rtfm/<name>.txt .rtfm/index.md aus.
• Durchsuche bei der Suche nach einem Thema zuerst den Index und den Text mit rg -n; nimm nicht an, dass das Handbuch es nicht enthält, nur weil du dich nicht erinnerst.

3. Umgebung scannen und Version abgleichen

• Sammle Umgebungsnachweise: Manifest-/Lock-Dateien (package.json, pyproject.toml, Cargo.lock, go.mod, requirements*.txt usw.), --version/-V, pkg-config --modversion, Laufzeitversion, SDK-/Toolchain-/Hardware-Kennungen.
• Finde die Handbuchversion auf dem Titelblatt, in der Versionshistorie, in Fußzeilen oder Metadaten.
• Bestimme anhand von references/version-matching.md den Status MATCH / COMPATIBLE / MISMATCH / UNKNOWN.
• Schreibe das Ergebnis in .rtfm/version-report.md und melde es dem Benutzer.
• Bei MISMATCH oder UNKNOWN: Halte inne und bitte den Benutzer um ein passendes Handbuch oder um explizite Zustimmung zur Fortsetzung; nach Zustimmung dokumentiere das Risiko in den Notizen.

4. Nach Handbuch programmieren

• Lies vor dem Schreiben einer Komponente/API das entsprechende Kapitel vollständig; extrahiere wichtige Signaturen, Konstanten, Standardwerte und Grenzfälle in .rtfm/notes.md mit Quellenangabe.
• Empfohlene Struktur von .rtfm/notes.md: Handbuchname und -version, Versionsabgleich-Ergebnis (MATCH/COMPATIBLE/MISMATCH/UNKNOWN), thematische Auszüge (jeweils mit manual.txt:Zeilennummer oder SEITE n), Änderungshistorie.
• Kopiere Bezeichner, Zeichenketten und Zahlen direkt aus dem Handbuch, um Übertragungsfehler zu vermeiden.
• Bei nicht durch das Handbuch abgedeckten Punkten markiere TODO + Quelle („Kapitel des Handbuchs nicht erläutert“) und ergänze nicht stillschweigend mit Online-Informationen; falls Ergänzungen nötig sind, hole vorher die Zustimmung des Benutzers ein.
• Was das Handbuch sagt, gilt: Auch wenn es von den „Best Practices“ im Internet abweicht, korrigiere es nicht wiederholt in die Online-Version, es sei denn, der Benutzer verlangt es oder Build-/Testnachweise belegen, dass die Handbuchseite nicht zur aktuellen Umgebung passt.

5. Validieren und abschließen

• Überprüfe nach Fertigstellung Abschnitt für Abschnitt am Handbuch: Jede verwendete API/Konfiguration/ jedes Verhalten muss in den Notizen eine Quellenangabe haben.
• Führe Build/Tests durch; bei Fehlern suche zuerst im Handbuch nach dem entsprechenden Kapitel, dann überprüfe die Umgebung – kein Raten erlaubt.
• Liefere abschließend eine kurze Zusammenfassung: Handbuchversion, Umgebungsversion, Abgleichsergebnis, Hauptquellenangaben und alle Abweichungen, die der Benutzer bestätigen muss.

Anti-Korrekturschleife

Der direkte Grund für diese Fertigkeit: KI liest kein Handbuch → „korrigiert“ Code aus dem Online-Gedächtnis → wieder falsch → erneute Korrektur, ständiges Überschreiben. Die folgenden Regeln müssen befolgt werden:

• Beweise vor der Änderung: Bevor du Code/Konfiguration änderst, weise darauf hin, „welche Zeile im Handbuch die aktuelle Implementierung verletzt“ und zitiere die Quelle; ohne Quellenangabe darf nicht geändert werden.
• Immer nur eine Ursache auf einmal ändern: Vermische nicht „sieht nicht gut aus“ und „stimmt nicht mit Handbuch überein“; nicht betroffener Code bleibt unverändert.
• Wenn dasselbe Phänomen nach zweimaliger Änderung immer noch auftritt: Höre auf zu patchen, lies das entsprechende Kapitel im Handbuch vollständig erneut, hinterfrage dein Verständnis, statt weiterzuraten.
• Bei Konflikten zwischen Handbuchverhalten und Online-Konventionen: Halte dich an das Handbuch; ändere nicht funktionierenden, aber handbuchkonformen Code in die Online-Version und auch nicht umgekehrt.
• Bei Fehlern suche zuerst im Handbuch: Prüfe Kapitel zu Fehlercodes, Einschränkungen und Grenzfällen; wenn das Handbuch keinen Eintrag enthält, suche nach Umgebungsnachweisen – kein Ändern nach Bauchgefühl.
• Jede Änderung fügt eine Zeile zur Änderungshistorie in .rtfm/notes.md hinzu: Ziel, was geändert wurde, Quellenangabe. Wenn nach zwei Änderungsrunden immer noch Fehler auftreten, vergleiche zuerst die Historie auf Wiederholungen.