1. Übersicht

Dieses Skill erforscht ein bestimmtes Thema (Tool, Bibliothek, Framework, API oder jede andere Software) und erstellt einen gut strukturierten Tutorial-Artikel im HackMD-kompatiblen Markdown-Format, der direkt in HackMD-Notizen verwendet werden kann. Die Kernfunktionen dieses Skills sind drei:

Erst forschen, dann schreiben – nie aus dem Gedächtnis schreiben.
Für Anfänger schreiben – mit einfachen Erklärungen und kurzen Beispielen, damit Leser die Technologie wirklich lernen.
Strikte Einhaltung eines Nummerierungs- und Blockformats, das HackMD korrekt parsen kann, sodass die Gliederung / das Inhaltsverzeichnis korrekt angezeigt wird.

Alle generierten Dokumente sind in traditionellem Chinesisch (Taiwanisch) verfasst. Selbst wenn der Benutzer Anweisungen in einer anderen Sprache gibt, müssen der Artikel (Titel, Fließtext, Beispieltexte) in traditionellem Chinesisch sein; nur der Code selbst (Variablen, Befehle, Syntax) folgt den Konventionen der ursprünglichen Sprache.

Zielgruppe und Tiefe

Standard: Anfänger-orientiert

Sofern der Benutzer nichts anderes fordert, ist der Lerngegenstand ein absoluter Neuling ohne Programmiererfahrung:

Vermitteln Sie dem Leser die tatsächliche Verwendung des Themas, streben Sie keine Vollständigkeit an.
Beispiele sollten die einfachste, kürzeste, direkt ausführbare Version sein, die ausreicht, um die im Abschnitt beschriebene Funktion zu demonstrieren.
Bei Fachbegriffen sollte beim ersten Auftreten eine kurze Erklärung in Umgangssprache gegeben werden (z.B. „Paketmanager: Ein kleines Tool, das Programme für dich herunterlädt und installiert.").
Jeder Schritt sollte erklären, „was du nach der Ausführung siehst", damit der Leser überprüfen kann, ob er alles richtig gemacht hat.
Die Länge hängt vom Thema ab, normalerweise etwa 1500–3000 Zeichen. Lieber kurz und klar, als mit unnötigem Material für Anfänger zu füllen.
Abschnitte wie „Erweiterte Einstellungen" oder „Vergleich mit Alternativen" sollten standardmäßig nicht enthalten sein.

Umschalten: Fortgeschrittene Version

Nur wenn der Benutzer ausdrücklich „tiefgehend", „fortgeschritten", „vollständig" oder „für erfahrene Entwickler" fordert, sollte eine fortgeschrittene Version geschrieben werden:

Die Länge kann 3000+ Zeichen betragen und es sollte erklärt werden, warum etwas so funktioniert, nicht nur, was die Syntax ist.
Abschnitte wie erweiterte Einstellungen, Randfälle, Leistungsaspekte und Vergleiche mit Alternativen können aufgenommen werden.

Technologie-Auswahl

Verwenden Sie nicht den standardmäßigen Technologie-Stack aus den Benutzereinstellungen (z.B. ASP.NET Core MVC, C#, SQL Server), es sei denn, der Artikel selbst handelt von dieser Technologie. Beispiele sollten in der Sprache und Umgebung gehalten sein, die in den offiziellen Dokumentationen des Themas am häufigsten vorkommt und für Anfänger am zugänglichsten ist.

Arbeitsablauf

Schritt 1: Thema und Ansatz klären (nur nachfragen, wenn es wirklich unklar ist)

Wenn das vom Benutzer genannte Thema bereits spezifisch genug ist, kann direkt mit der Arbeit begonnen werden (z.B. „Schreib mir ein Tutorial über Vite", „write a tutorial on FastAPI dependency injection"). Stell keine Fragen, sondern gehe direkt in die Recherchephase.

Nur in den folgenden zwei Fällen sollte der Benutzer befragt werden:

Der Themenname könnte sich auf verschiedene tatsächliche Dinge beziehen (z.B. „Mongo" könnte die MongoDB-Datenbank oder etwas anderes sein).
Der Umfang ist so unklar, dass er die Richtung des gesamten Artikels beeinflussen würde (z.B. „React" – ein allgemeiner Überblick oder eine bestimmte Funktion?).

Schritt 2: Gründlich recherchieren, bevor du schreibst

Dies ist der wichtigste Schritt. Schreibe nicht aus dem Gedächtnis und „überprüfe nachträglich", sondern recherchiere zuerst und schreibe dann.

Betrachte offizielle Dokumentationen/Websites und qualitativ hochwertige Tutorial-Artikel als zuverlässige Quellen. Offizielle Dokumentationen sind die beste Quelle für genaue Funktionslisten, Installationsschritte und API-Details; unabhängige Tutorials und Blogs eignen sich für reale Anwendungsbeispiele, häufige Fallstricke und tatsächliche Nutzungsszenarien, die in der offiziellen Dokumentation oft übersehen werden.
Passe die Anzahl der Suchvorgänge an die Breite des Themas an: Fokussierte Themen (einzelnes CLI-Tool, einzelne Bibliotheksfunktion) etwa 4–6 Suchvorgänge; breitere Themen (ganzer Framework) etwa 8–15+ Suchvorgänge, die verschiedene Aspekte abdecken (Installation, Kernkonzepte, Konfiguration, häufige Nutzungsszenarien, aktuelle Versionsänderungen).
Überprüfe unbedingt die aktuellste Version. Suche nach Schlüsselwörtern wie „release notes", „changelog", „version", „what's new", um sicherzustellen, dass Installationsanweisungen und Funktionsbeschreibungen den neuesten Stand widerspiegeln und nicht veralteten Erinnerungen entsprechen.
Verwende für die relevantesten Seiten (offizielle Einsteiger-Guides, Installationsseiten, wichtige Tutorials) ein Web-Scraping-Tool, um den vollständigen Text zu lesen. Verlasse dich nicht nur auf Zusammenfassungsausschnitte der Suchergebnisse, da diese in der Regel zu dünn sind, um genaue Inhalte zu schreiben.
Beachte das Urheberrecht: Gib niemals lange Textpassagen Stück für Stück aus einer Quelle wieder. Alle Inhalte müssen in eigenen Worten aus mehreren Quellen zusammengefasst werden, nicht direkt aus einer einzigen Quelle kopiert werden. Selbst geschriebene Codebeispiele sind normale technische Schreibarbeit und keine Inhaltsreproduktion.
Notiere während der Recherche die tatsächlich verwendeten Quell-URLs, um sie am Ende des Artikels im Abschnitt „Weiterführende Ressourcen" aufzulisten.

Schritt 3: Die Kapitelstruktur des Artikels basierend auf dem Thema bestimmen

Es gibt keine feste Vorlage. Die Art des Themas bestimmt, welche Abschnitte sinnvoll sind. Zwinge keine irrelevanten Abschnitte in ein einheitliches Schema. Ein Anfänger-Tutorial umfasst normalerweise die folgenden Teile:

Einführung: Was ist das? Warum sollte jemand es verwenden? Verwende lebensnahe Metaphern.
Funktionen/Merkmale: Was kann es tatsächlich tun? Wähle die für Anfänger relevantesten Funktionen aus.
Installation/Konfiguration: Füge dies nur hinzu, wenn die Installation tatsächlich relevant ist (für CLI-Tools oder Bibliotheken notwendig; für webbasierte SaaS-Produkte oder Programmierkonzepte möglicherweise nicht).
Schnellstart: Ein minimales, ausführbares Beispiel und erkläre, was nach der Ausführung zu sehen ist.
Anwendungsbeispiele: Ein bis zwei Beispiele, die nah an der realen Nutzung sind, aber dennoch kurz bleiben.
Häufige Fragen/Fehlerbehebung: Nur hinzufügen, wenn die Recherche tatsächlich existierende häufige Fehler oder Probleme aufgedeckt hat. Erfinde keine; wenn die Recherche nichts findet, lasse diesen Abschnitt einfach weg.
Zusammenfassung und weiterführende Ressourcen: Schlussfolgerung und füge Links zu den offiziellen Dokumentationen und Referenzartikeln hinzu, die bei der Recherche verwendet wurden.

Die fortgeschrittene Version kann zusätzlich Abschnitte wie „Erweiterte Einstellungen" und „Vergleich mit Alternativen" enthalten (siehe „Zielgruppe und Tiefe").

Schritt 4: Den Artikel im HackMD-Nummerierungsformat schreiben

Dies ist eine strenge Formatierungsvorschrift. HackMD parst diese Formate in ein Gliederungs-/Inhaltsverzeichnis-Panel. Das Befolgen der Regeln ist weitaus wichtiger als das Aussehen.

4-1 Dokumentenanfang: YAML-Metadaten

HackMD verwendet die Metadaten oder die erste Überschrift des Dokuments als Notizname. Um zu vermeiden, dass jede Notiz „1. Einleitung" heißt, füge am Anfang des Dokuments YAML-Metadaten mit Titel und Tags hinzu:

---
title: Vite Einsteiger-Tutorial
tags: Vite, Frontend, Tutorial
---

Nach den Metadaten eine Leerzeile, dann direkt mit der ersten Überschrift 1\. Einleitung beginnen. Füge keine separate # Artikeltitel-Zeile hinzu, da sonst eine unnumerierte Überschrift im Inhaltsverzeichnis erscheint.

4-2 Vier Überschriftsebenen

Ebene	Nummerierung	Markdown-Syntax	Hinweise
1	`1\.`, `2\.`, `3\.` ...	Setext H1: Text in einer separaten Zeile, nächste Zeile `===`	Der Punkt nach der Zahl muss mit einem Backslash maskiert werden, z.B. `2\. Installation und Konfiguration`
2	`1.1`, `1.2`, `2.1` ...	Setext H2: Text in einer separaten Zeile, nächste Zeile `---`	Keine Maskierung erforderlich, z.B. `1.1 Installationsmethode`
3	`1.1.1`, `1.1.2` ...	ATX H3: `### 1.1.1 Text`
4	`1.1.1.1`, `1.1.1.2` ...	ATX H4: `#### 1.1.1.1 Text`	Eine Zahl mehr als die vorherige Ebene, leicht zu übersehen; überprüfe jede.

⚠️ Warum der Punkt in Ebene 1 maskiert werden muss:

Wenn du 2. Installation und Konfiguration (ohne Maskierung) schreibst, interpretiert Markdown diese Zeile als „geordnetes Listenelement", und das === in der nächsten Zeile kann keine Setext-Überschrift bilden; die gesamte Überschrift wird falsch formatiert. Wenn du 2\. Installation und Konfiguration schreibst, entfernt HackMD bei der Darstellung den Backslash, der Leser sieht immer noch „2. Installation und Konfiguration", aber die Überschrift wird korrekt geparst.

Ebene 2 (1.1) ist nicht im Format „Zahl + Punkt + Leerzeichen", daher wird sie nicht fälschlicherweise als Liste interpretiert und benötigt keine Maskierung.

2. Installation und Konfiguration   ← Falsch: Wird als Listenelement geparst, === unwirksam
===

2\. Installation und Konfiguration  ← Richtig: Punkt maskiert, Setext-Überschrift wird korrekt geparst
===

4-3 Leerzeilen-Regeln

Der Überschriftentext und die Unterstreichung (=== oder ---) müssen direkt aufeinanderfolgende Zeilen sein, dazwischen darf keine Leerzeile sein, sonst behandelt Markdown sie als zwei getrennte, nicht zusammenhängende Inhalte.
Nach der Unterstreichung muss eine Leerzeile stehen, bevor der nächste Textabschnitt, die nächste Überschrift oder der nächste Trennstrich beginnt.

4-4 Trennstrich-Regeln

Um die Abschnitte visuell klar zu trennen, füge über bestimmten Überschriften einen separaten horizontalen Trennstrich --- hinzu:

Überschrift	Wann einen Trennstrich hinzufügen
Ebene 1 (`1\.`)	Immer hinzufügen. Einzige Ausnahme: Die erste große Überschrift des Dokuments (direkt nach den YAML-Metadaten) benötigt keinen.
Ebene 2 (`1.1`)	Wenn direkt darüber (nach dem Ignorieren von Leerzeilen) das `===` von Ebene 1 ist, nicht hinzufügen; wenn darüber Text, Code-Blöcke, Hinweisfelder oder andere Inhalte sind, dann hinzufügen.
Ebene 3, 4 (`###`, `####`)	Niemals hinzufügen.

Vor und nach dem Trennstrich muss jeweils eine Leerzeile stehen. Wenn --- direkt unter einer Textzeile steht, interpretiert Markdown es als Setext-H2-Unterstreichung für diese Textzeile, nicht als Trennstrich, und die nachfolgenden Überschriftsebenen werden durcheinandergebracht.

Richtige Schreibweise: Ende des vorherigen Abschnitts → Leerzeile → --- als eigene Zeile → Leerzeile → Nächste Überschrift.

...Ende des vorherigen Abschnitts...

---

1.2 Warum wird es benötigt?
---

...Inhalt dieses Abschnitts...

4-5 Weitere strenge Regeln

Die Nummerierung vertieft sich mit jeder Ebene genau um eine Zahl (1 → 1.1 → 1.1.1 → 1.1.1.1), überspringe keine Ebenen. Die Nummerierung auf derselben Ebene muss fortlaufend sein (nach 2.1 kommt 2.2, nicht 2.4).
Verwende für Ebene 1 und 2 Setext-Unterstreichungen (=== / ---), nicht # / ##; für Ebene 3 und 4 verwende ### / ####. Mische diese nicht; # 1\. Einleitung ist falsch.
Überschreite nicht Ebene 4. Wenn du eine feinere Ebene benötigst, sollte der Abschnitt aufgeteilt oder neu organisiert werden.
Nicht jeder Abschnitt benötigt alle vier Ebenen. Kurze Abschnitte können nur aus 1\. xxx und Text bestehen und benötigen überhaupt keine Unterabschnitte.
Alle Überschriften, die mit # beginnen, müssen nummeriert sein. Einzige Ausnahme sind Code-Erklärungsetiketten im :::success-Container (siehe 5-1). Außer diesen darf es keine nummerierten Überschriften geben.
Überschriftentexte sind immer auf traditionellem Chinesisch, unabhängig davon, in welcher Sprache der Benutzer die Anweisung gibt.

4-6 Vollständiges Strukturbeispiel

---
title: Vite Einsteiger-Tutorial
tags: Vite, Frontend, Tutorial
---

1\. Einleitung
===

1.1 Was ist das?
---

Erklärung...

---

1.2 Warum wird es benötigt?
---

Erklärung...

---

2\. Installation
===

Vor Beginn der Installation überprüfe bitte Folgendes:

---

2.1 Systemanforderungen
---

### 2.1.1 Betriebssystemunterstützung

Erklärung...

### 2.1.2 Abhängigkeiten

Erklärung...

---

2.2 Installationsschritte
---

### 2.2.1 Installation mit Paketmanager

#### 2.2.1.1 Windows-Umgebung

Erklärung...

#### 2.2.1.2 macOS-Umgebung

Erklärung...

Dieses Beispiel demonstriert gleichzeitig:

1.1 folgt direkt auf das === von 1\. Einleitung, daher wird kein Trennstrich hinzugefügt.
Über 2.1 steht erklärender Text, daher wird ein Trennstrich hinzugefügt.
2\. Installation ist nicht die erste große Überschrift, daher wird ein Trennstrich darüber hinzugefügt.

Schritt 5: HackMD-Blockformate

5-1 Code-Blöcke

Jeder einzelne Code-Block im Artikel muss in einen :::success-Container von HackMD eingeschlossen werden und die folgenden Regeln einhalten:

Die erste Zeile im Container ist ein Erklärungsetikett, fest formatiert als #### `Codebeispiel: Kurzbeschreibung`: Verwende ####-Überschrift, den Etikettentext in Backticks, kein Emoji und keine Nummerierung. Dies ist die einzige Ausnahme von der Regel 4-5 „Überschriften müssen nummeriert sein".
Zwischen dem Erklärungsetikett und dem Code-Block eine Leerzeile.
Der Code-Block muss immer eine Sprachangabe haben (bash, html, csharp, json usw.).
Für Code mit 3 oder mehr Zeilen füge = nach der Sprachangabe hinzu, um Zeilennummern anzuzeigen (z.B. ```html=); für kurze Befehle mit 1–2 Zeilen kein = hinzufügen, um das Layout nicht zu überladen.
Die Beispiele sollten direkt kopiert und ausgeführt werden können. Unterhalb des Code-Blocks (außerhalb des Containers) erkläre in ein bis zwei Sätzen, was nach der Ausführung zu sehen ist.

Beispiel für mehrzeiligen Code:

:::success
#### `Codebeispiel: Erstes Vite-Projekt erstellen`

```bash=
npm create vite@latest my-app
cd my-app
npm install
npm run dev
```
:::

Nach der Ausführung wird im Terminal eine lokale URL angezeigt (z.B. `http://localhost:5173`). Wenn du sie im Browser öffnest, siehst du die Beispielseite.

Beispiel für kurzen Befehl:

:::success
#### `Codebeispiel: Node.js-Version überprüfen`

```bash
node -v
```
:::

5-2 Wichtige Hinweise

Für Inhalte, die besonders hervorgehoben werden müssen (häufige Anfängerfehler, wichtige Konzepte), verwende das folgende Hinweisfeld-Format. Es müssen Trennstriche --- vor und nach dem Hinweisfeld eingefügt werden. Die Trennstrich-Regel (jeweils eine Leerzeile davor und danach) bleibt bestehen:

...Vorheriger Abschnitt...

---

>[!Warning] 💡 **Wichtiger Hinweis**
>
>---
> Wenn du nichts verstehst, **merke dir einfach diesen einen Befehl**.
> Nach jedem Schritt zeigt dir das Add-On, was du als Nächstes eingeben sollst.

---

...Nächster Abschnitt...

Verwende Hinweisfelder nur an wirklich wichtigen Stellen, maximal ein bis zwei pro Abschnitt. Zu viele schwächen die Warnwirkung.
Wenn auf das Hinweisfeld direkt eine Überschrift der Ebene 1 oder 2 folgt, für die ein Trennstrich benötigt wird, dient der abschließende --- des Hinweisfelds gleichzeitig als Trennstrich für diese Überschrift. Füge nur einen Trennstrich ein, nicht zwei aufeinanderfolgende ---.

Schritt 6: Selbstkontrolle vor der Ausgabe

Überprüfe den gesamten Artikel Punkt für Punkt, bevor du ihn abgibst. Korrigiere Fehler, bevor du die endgültige Version ausgibst:

Schritt 7: Endgültiges Ergebnis ausgeben

Standardmäßig als .md-Datei ausgeben, Dateiname basierend auf dem Thema, z.B. Vite-Einsteiger-Tutorial.md. Tutorials sind oft lang; das Speichern als Datei ist am bequemsten für den Benutzer, um sie vollständig in HackMD zu kopieren, und es gibt keine Probleme mit abgeschnittenen Code-Blöcken. Gib im Gespräch nur eine kurze Zusammenfassung des Inhalts des Artikels.
Wenn der Benutzer die Ausgabe direkt im Gespräch wünscht oder die aktuelle Umgebung kein Tool zum Erstellen von Dateien bietet, gib den vollständigen Text im Gespräch aus. Da der Artikel ``` Code-Blöcke enthält, muss der äußere Rahmen entweder vier Backticks oder ~~~ verwenden, um den gesamten Text einzuschließen, da sonst die inneren Code-Blöcke den äußeren Rahmen vorzeitig beenden und der Inhalt unterbrochen wird.
Gib nach der Ausgabe kurz die wichtigsten verwendeten Referenzquellen an (Links zu offiziellen Dokumentationen, wichtige Referenzartikel), damit der Benutzer sie selbst überprüfen oder sich weiter informieren kann.

johnsonshsu/claudecodedemo

Was ist claudecodedemo?

In Ihrer bevorzugten KI fragen

Dokumentation