Ressourcen

Dokumente, die ich selbst nutze

Leitfäden und Referenzdateien, die ich für meine eigene Arbeit geschrieben habe — veröffentlicht, damit du sie auch nutzen kannst. Keine E-Mail, keine Anmeldung.

Alles hier steht unter CC BY 4.0

Clean Code Styleguide

Wie ich Code schreibe: Namen, die keinen Kommentar brauchen, Docstrings, die den Vertrag beschreiben, ein Abstraktionsniveau pro Funktion, und die Regeln, die ich im Review anwende. Für Menschen geschrieben — deshalb kann ein KI-Agent sie auch befolgen.

Markdown (.md) · 227 Zeilen · CC BY 4.0 · 9 KB

Requirements-Styleguide

Wie ich Spezifikationen schreibe: ein Requirements-Ordner mit nummerierten Domain-Dateien, eine ID pro Anforderung, damit Plan, PR und Test dieselbe Stelle zitieren können, und eine Changelog-Regel, die verhindert, dass die Spezifikation etwas beschreibt, das es nicht mehr gibt.

Markdown (.md) · 228 Zeilen · CC BY 4.0 · 11 KB

Was du damit machst

Beide sind Markdown-Dateien: lesbar als Dokument und verwendbar als Skill-Datei für einen Agenten. Beides geht ohne Umbau.

  1. Lesen. Wenn du aus dem Clean-Code-Guide nur eine Regel mitnimmst: Code wird viel häufiger gelesen als geschrieben.
  2. Als Skill nutzen: in einen Ordner mit dem Skill-Namen legen und in SKILL.md umbenennen.
  3. Oder in die Agent-Instruktionen kopieren, damit die Regeln für jede Änderung gelten.
mkdir -p .agents/skills/clean-code .agents/skills/requirements
mv ~/Downloads/clean-code.md .agents/skills/clean-code/SKILL.md
mv ~/Downloads/requirements.md .agents/skills/requirements/SKILL.md

Warum eine Datei statt eines Blogposts

  • Ein Post ist für jemanden geschrieben, der nichts damit tut. Eine Datei ist dafür geschrieben, angewendet und zitiert zu werden.
  • Du kannst sie diffen. Wenn ich meine Regeln ändere, siehst du genau was sich geändert hat, statt eine Seite neu zu lesen.
  • Es ist derselbe Text, den meine eigenen Agenten lesen, bevor sie Code oder eine Spezifikation anfassen — Dokument und Praxis können nicht auseinanderlaufen.