Pokayoke: So baust du Fehler-Schutzmechanismen direkt in dein Repository ein

Shigeo Shingo, ein japanischer Fertigungspionier, prägte den Begriff Pokayoke in den 1960er Jahren. Sein Ziel war damals dasselbe Problem, das Entwickler heute kennen: Wie sorgt man dafür, dass Fehler gar nicht erst passieren – oder zumindest sofort auffallen?

Die Grundidee ist simpel. Anstatt darauf zu vertrauen, dass Menschen Regeln perfekt einhalten, baust du Systeme, die Abweichungen automatisch erkennen. Eine Steckdose, die nur in einer Richtung passt. Ein Sensor, der die Produktionslinie stoppt, wenn etwas nicht stimmt. In der Fertigung verhindert das mangelhafte Produkte. In der Softwareentwicklung verhindert es, dass sich falsche Muster in deiner Codebasis festsetzen.

Pokayoke.codes überträgt genau diese Philosophie auf Repositories – mit einem Tool, das von Grund auf für die Ära der KI-gestützten Entwicklung konzipiert wurde.

Mehr als nur Linting: Richtlinien als lebendige Dokumentation

Die meisten Teams nutzen bereits Linter. ESLint meldet ungenutzte Variablen. Prettier kümmert sich um Formatierung. TypeScript fängt Typfehler ab. Diese Werkzeuge leisten gute Arbeit – aber sie erfassen nicht das implizite Wissen, das nur in den Köpfen deines Teams existiert. Konventionen, die jeder kennt, aber die niemand je niedergeschrieben hat.

Vielleicht folgen eure API-Endpunkte einem bestimmten Namensschema. Vielleicht gibt es Regeln, welche Pakete in welchem Kontext erlaubt sind. Oder es gibt eine mündliche Absprache über die Dateistruktur, die nirgends durchgesetzt wird.

Hier kommt Pokayoke ins Spiel. Es ermöglicht dir, repositoriespezifische Regeln zu definieren, die außerhalb des Scopes traditioneller Linter liegen – aber genauso wichtig für konsistenten Code sind.

Von Grund auf für KI-Agenten gemacht

Das macht Pokayoke wirklich interessant: Das Tool ist zuerst für KI-Agenten gedacht.

Moderne Coding-Assistenten können sich durch deine Codebasis navigieren, neue Features schreiben und bestehenden Code umbauen. Aber sie auf Konventionen auszurichten? Das ist oft noch Handarbeit. Du fügst Regeln in den System-Prompt ein – aber Agenten vergessen, halluzinieren oder wissen schlicht nicht, was dir wichtig ist.

Pokayoke löst das, indem es Richtlinien zu Bürgern erster Klasse macht. Agenten können sie lesen, verstehen und befolgen. Der Befehl pokayoke agent SKILL.md bringt Agenten zum autonomen Arbeiten. Die Regeln selbst sind so gestaltet, dass sie von KI geschrieben und gepflegt werden können – nicht nur für menschliche Entwickler.

Wenn du einen Vibe-Coding-Workflow aufbaust, bei dem KI den Großteil der Arbeit übernimmt, gibt dir Pokayoke eine Möglichkeit, deine Standards in einem Format zu kommunizieren, das wirklich funktioniert.

Versteht sich mit deinem Stack

Ein berechtigter Einwand gegen neue Tools: Die Gefahr der Fragmentierung. Du hast bereits ESLint, Prettier, Husky und diverse andere Helfer, die deinen Code im Griff halten. Pokayoke zu installieren bedeutet nicht, irgendetwas davon zu ersetzen – es bedeutet, deine bestehende Pipeline zu erweitern.

Die Dokumentation betont, dass Pokayoke unvoreingenommen ist. Formatierung interessiert es nicht (dafür gibt es Prettier). Allgemeine Codequalität auch nicht (dafür gibt es ESLint). Stattdessen konzentriert es sich auf die projektspezifischen Regeln, die nur dein Team kennt.

Die TypeScript-Regeln sind lokal in deinem Repository gespeichert und prüfen gegen die Einschränkungen, die für dein Setup relevant sind. Stell es dir als eine zusätzliche Validierungsschicht über deinem Standard-Werkzeugkasten vor.

Der Einstieg

Bereit, dein Repository fehlersicher zu machen? Die Installation ist unkompliziert:

npx skills add rorz/pokayoke

Danach kannst du Regeln definieren, die eure Team-Konventionen festhalten. Die Regeln sind so gestaltet, dass sie sich selbst dokumentieren – sowohl Menschen als auch Agenten können sie lesen, um zu verstehen, welche Richtlinien gelten und warum.

Der größere Zusammenhang

Pokayoke steht für einen bemerkenswerten Shift in der Art, wie wir über Code-Qualitätstools denken. Traditionelle Linter erzwingen Syntax und Stil. Statische Analyzer finden Bugs. Aber wenn KI-Coding-Assistenten zu primären Kollaborateuren werden, brauchen wir neue Kategorien von Tools, die Absicht vermitteln können – in einer Form, die Agenten tatsächlich verarbeiten und befolgen können.

Es geht nicht mehr nur darum, Fehler zu finden. Es geht darum, deine Standards maschinenlesbar, agentenfreundlich und schwer zu verletzen zu machen – egal ob der Code von einem menschlichen Entwickler oder einem KI-Assistenten stammt.

In diesem Sinne könnte Pokayoke eines der ersten Tools sein, das bewusst für die Art gebaut wurde, wie wir in einigen Jahren alle programmieren werden. Auf jeden Fall einen Blick wert.