diodesign/diosix-agent-skills

Diosix dokumentieren

Jede Dokumentationsseite in docs/ und README.md muss zu 100% synchron mit der Implementierung in hypervisor/, tools/ und scripts/ sein und muss die Vorgaben aus docs/style-guide.md einhalten, damit die Dokumentation beim ersten Durchlauf reviewing-diosix besteht.

Kernanforderungen

1. Klare, korrekte englische Prosa (Grundvoraussetzung): Alle Dokumentation muss in amerikanischem Englisch mit geprüfter Rechtschreibung, korrekter Grammatik und präzisem Wortlaut verfasst sein, der niemals die technische Klarheit oder Genauigkeit opfert.
2. Wahrheitsgetreue Dokumentation: Niemals veraltete CLI-Flags, SBI-Funktions-IDs, ioctl-Nummern, C-Struct-Layouts (uint64_t vs. unsigned long), Dateipfade oder Konfigurationsschlüssel in docs/ belassen. Jede Codeänderung, die das Verhalten, CLI-Optionen, modulare Dateipfade oder Konfigurationsschemata verändert, muss docs/ in der selben Änderung aktualisieren.
3. Zielgruppengerechtes Design: Explizit auf zwei unterschiedliche Zielgruppen ausrichten:
   • Benutzer (Anfänger & Experten): Betreiber, die Diosix booten, die geführte Tour absolvieren, Gast-VMs mit dsx starten oder deklarative System-/Charter-Manifeste konfigurieren.
   • Entwickler & Maintainer: Ingenieure, die den M-Mode-Hypervisor, den S-Mode-dynarec und die U-Mode-Tools entwickeln, testen, debuggen und erweitern.
4. Strenge Einhaltung des Stils (docs/style-guide.md):
   • Text, Listeneinträge und Codeblöcke auf maximal 80 Zeichen pro Zeile umbrechen (mit Ausnahme von Markdown-Tabellenzeilen und langen URLs). Dateibasename im Markdown-Linktext verwenden ([S50dropbear](../tools/.../S50dropbear)), damit Linkzeilen sauber innerhalb von 80 Spalten umbrechen.
   • Aktivform und Präsens verwenden ("Der Hypervisor validiert die GPA", niemals "Die GPA wird vom Hypervisor validiert").
   • Satzfall in Überschriften verwenden (## Hierarchisches Gastmodell, niemals ## Hierarchisches Gastmodell).
   • Abkürzungen bei erster Verwendung pro Seite ausschreiben (Supervisor Binary Interface (SBI)), danach nur die Abkürzung (SBI) verwenden.
   • Nummerierte Listen ausschließlich für sequenzielle Mehrschritt-Prozeduren und Aufzählungspunkte für nicht-sequenzielle Elemente verwenden.
5. Im Zweifel anhalten und den leitenden Maintainer fragen: Wenn das beabsichtigte Verhalten, die Terminologie oder der Zielgruppenumfang unklar ist, anhalten und den leitenden Maintainer um Klärung bitten, anstatt zu raten oder Details zu erfinden.

Fokussierte Referenzhandbücher

Lesen Sie die entsprechende Referenzdatei, bevor Sie Dokumentation entwerfen oder bearbeiten:

• Stil & kanonische Terminologie: Englische Grammatik-/Rechtschreibstandards, 80-Zeichen-Umbruch, Regeln zum Ausschreiben von Abkürzungen und kanonische Hardware-/Virtualisierungs- Definitionen (Host-Build-Maschine, Host-Hardware, Zielplattform, HPA, GPA, GVA, CID).
• Zwei Zielgruppen & Dokumentenstruktur: Anpassung des Inhalts für Anfänger/Experten vs. Maintainer, Zuordnung von Codeänderungen zu bestimmten docs/*.md-Dateien und Dokumentation von Testkonventionen.