Phodal Huang ist chinesischer Softwareentwickler, Buchautor und Betreiber von phodal.com. In seinem Blogpost "/phodal-writer" beschreibt er, wie er zehn Jahre Schreiberfahrung systematisch in ein wiederverwendbares AI-Skill-System ueberführt hat. Das Resultat ist kein besserer Prompt, sondern eine strukturierte Wissensarchitektur, die modell- und kontextuebergreifend stabil funktioniert. Der Ansatz ist direkt uebertragbar auf andere Formen von Expertise.
Das Problem: Style-Prompts driften
Der naive Ansatz -- einem LLM sagen "schreib wie ich" und ein paar Beispiele anhaengen -- funktioniert genau so lange, wie man im selben Modell, im selben Thread und mit aehnlichen Aufgaben bleibt. Sobald sich eine Variable aendert -- anderes Modell, anderer Einstiegspunkt, anderer Artikeltyp -- driftet das Ergebnis. Struktur, Rhythmus und das, was Phodal "Urteilsdichte" nennt, weichen sofort ab.
Das Problem ist grundsaetzlich: Ein Prompt beschreibt Oberflaeche. Er sagt "sachlich, nuechtern, strukturiert" -- aber nicht, wo genau Urteile platziert werden, wie Fragen ueber Abschnitte hinweg transformiert werden oder welche Archetypen ein Artikel folgt. Das Modell interpoliert, und jede Interpolation ist eine andere.
Die Methodik: Drei Stufen zur Kodifizierung
Phodals Loesung ist ein systematischer Extraktionsprozess in drei Schritten.
1. Historische Segmentierung
Eigene Arbeit wird nicht als homogener Korpus behandelt, sondern nach Zeitperioden segmentiert -- in Phodals Fall 2014-2019, 2020-2023, 2024-2025. Das Ziel ist nicht der Durchschnitt ueber alles, sondern die Evolution. Fruehe Muster koennen veraltet sein. Aktuelle Muster spiegeln das heutige Qualitaetsniveau wider.
Fuer einen Entwickler uebersetzt: Nicht alle Code Reviews der letzten fuenf Jahre gleichwertig behandeln, sondern erkennen, welche Heuristiken sich durchgesetzt haben und welche man laengst aufgegeben hat.
2. Musterextraktion
Ueber die Zeitperioden hinweg werden stabile Patterns identifiziert -- Muster, die sich trotz Evolution erhalten haben. Phodal extrahiert entlang konkreter Dimensionen: Eroeffnungsstrategien, Strukturprogression, Urteilsplatzierung, Informationsdichte. Das Ergebnis ist keine Stilbeschreibung, sondern eine Bestandsaufnahme operationaler Muster.
3. Regeluebersetzung
Der entscheidende Schritt: Beobachtungen werden in ausfuehrbare Regeln uebersetzt. Nicht "ich schreibe strukturiert", sondern konkrete Anweisungen, die ein LLM deterministisch befolgen kann. Phodal extrahiert vier Kernregeln als Beispiel:
- Problem-Rekursion: Hauptfragen werden ueber Schichten hinweg transformiert -- von Phaenomen zu Engineering-Problem zu Mechanismus zu Entscheidung. Jeder Abschnitt benennt die Frage um.
- Urteils-Positionierung: Schlussfolgerungen stehen am Ende eines Abschnitts oder einer Sektion, nicht am Anfang. Das erzwingt eine argumentative Progression.
- Prototyp-First: Artikel folgen benannten Archetypen -- Trendanalyse, Methodologie, Retrospektive, Framework-Erklaerung, Produktrelease, Reflexion. Der Archetyp bestimmt Struktur und Tonalitaet.
- Quantifizierte Anker: Urteile werden an verifizierbare Metriken gebunden -- Projektnamen, Versionswechsel, Zeitdifferenzen, Code-Umfang. Keine freischwebenden Behauptungen.
Skill statt Prompt: Die Architektur
Der strukturelle Unterschied zu einem Prompt liegt in der Architektur. Phodal organisiert sein Wissen als Skill-Verzeichnis:
/phodal-writer/
SKILL.md (Kernregeln)
references/
article_archetypes.md
writing_structure.md
style_core.md
quality_checklist.md
style_evolution/
Das Prinzip dahinter ist progressive Wissensenthuellung: Nicht alles wird auf einmal in den Kontext geladen. SKILL.md enthaelt die Kernregeln, die immer gelten. Die Referenz-Dokumente werden nur geladen, wenn sie fuer die aktuelle Aufgabe relevant sind -- Archetypen beim Planen, Struktur-Referenz beim Schreiben, Qualitaets-Checkliste beim Pruefen.
Das loest ein konkretes technisches Problem: Kontextfenster sind endlich, und je mehr irrelevante Information ein LLM verarbeiten muss, desto schlechter wird die Ausgabe. Progressive Enthuellung haelt den Kontext scharf und signalstark.
Die Kernunterscheidung: Ein Prompt loest "wie mache ich das einmal". Ein Skill loest "wie mache ich das wiederholbar und uebertragbar". Der Unterschied ist operationale Persistenz versus Einmal-Instruktion. Der Skill ueberlebt Modellwechsel, Kontextwechsel und Aufgabenwechsel, weil er nicht auf implizitem Verstaendnis basiert, sondern auf expliziten, ausfuehrbaren Regeln.
Uebertragung auf den eigenen Alltag
Der Ansatz ist nicht auf Schreiben beschraenkt. Jede Expertise, die sich in Regeln ausdruecken laesst, kann als Skill kodifiziert werden. Konkrete Anwendungsfelder:
- Code Reviews: Welche Muster prueft ein erfahrener Reviewer zuerst? Wie werden Schweregrade eingestuft? Welche Klasse von Fehlern wird konsistent uebersehen? Das laesst sich extrahieren und als Skill strukturieren.
- Architekturentscheidungen: Heuristiken wie "wenn Service X mehr als drei Downstream-Abhaengigkeiten hat, Queue statt synchronem Call" sind implizites Wissen, das explizit gemacht werden kann.
- Debugging-Strategien: Die Reihenfolge, in der ein erfahrener Entwickler Hypothesen prueft, ist kein Zufall. Sie folgt Mustern, die sich kodifizieren lassen.
- Technische Dokumentation: Strukturvorgaben, Detailtiefe pro Dokumenttyp, Zielgruppen-Anpassung -- alles kodifizierbar.
Der praktische Einstieg ist derselbe wie bei Phodal: Eigene Arbeit segmentieren, stabile Muster identifizieren, in ausfuehrbare Regeln uebersetzen. Beschreibungen wie "gruendlich" oder "pragmatisch" durch konkrete Anweisungen ersetzen, die ein LLM ohne Interpretation befolgen kann.
Quellen
- Phodal Writer Skill -- Phodal Huang, phodal.com