Prelint

Prelint stellt sich neben dein bestehendes Code-Review und betrachtet eine Schicht, die die meisten Tools ignorieren: ob der Code zu dem passt, was das Team tatsächlich zu bauen beschlossen hat. Es liest Markdown-Spezifikationen, Aufzeichnungen über Architekturentscheidungen und Produktanforderungsdokumente aus deinem Repository und macht daraus Prüfkriterien. Widerspricht ein PR einer dieser Entscheidungen, sagt Prelint das.

Das Problem, das es angeht, ist konkret. KI-Coding-Agenten schreiben sauberen, testkonformen, gut strukturierten Code, der trotzdem die Regeln deines Produkts bricht. Eine Preisseite, die 60-Tage-Konditionen nennt, während die Abrechnungsrichtlinie 30 sagt, oder ein Anmeldeablauf, der für reine US-Kunden einen DSGVO-Zustimmungsschritt einfügt. Dein Linter fängt das nicht. Dein menschlicher Prüfer vielleicht, wenn er Zeit hat und sich an die Richtlinie erinnert. Was füllt also die Lücke, wenn keiner von beiden es tut?

Die größte Grenze ist der Umfang von der Konzeption her. Prelint ersetzt weder deinen Linter noch deinen Typenprüfer noch deinen Sicherheitsscanner, und es repariert den Code nicht für dich. Es liest Kontext innerhalb eines Zeichenbudgets und hängt von der Qualität der Dokumente ab, die du ihm gibst. Müll rein, Müll raus.

Erste Schritte

1. Installiere die GitHub App und wähle aus, welche Repositories Prelint prüfen soll. Keine CI-Änderungen und keine YAML-Dateien sind nötig.
2. Füge Kontext zum Repository hinzu, indem du Produktspezifikationen, Entscheidungsprotokolle oder Architekturdokumente hineinlegst. Markdown-Dateien werden automatisch indexiert.
3. Öffne einen Pull Request. Prelint prüft ihn in Sekunden und postet Befunde als Inline-Kommentare, angeheftet an die Zeilen, die sie ausgelöst haben.
4. Lies das Entscheidungsregister, um zu sehen, wer was wann entschieden hat und ob ein Mensch oder eine KI die Wahl traf. Genehmigte Entscheidungen werden zu Kontext, den deine Agenten beim nächsten Mal wiederverwenden.