Coding-Standards deines Teams für Claude Code, Cursor und Codex

Coding-Agents sind nur so gut wie der Kontext, den sie bekommen. Ohne Kontext schreiben sie Code, der kompiliert, aber nicht nach deiner Codebasis aussieht: andere Namen, ein anderer Stil bei der Fehlerbehandlung, Tests am falschen Ort. Also fangen Teams an, ihnen Kontext zu geben. Und genau da beginnt das Problem.

Das Kopierproblem

Der übliche erste Schritt ist eine Regeldatei in jedem Repository. Für ein Projekt funktioniert das. Bei fünf Repositories hast du fünf Kopien, die auseinanderlaufen. Jemand ändert die Regel zur Fehlerbehandlung in einer davon, die anderen behalten die alte Version, und der Agent im nächsten Repository folgt munter der veralteten.

Dasselbe passiert zwischen Tools. Eine Entwicklerin nutzt Claude Code, ein anderer Cursor, ein dritter Codex. Jedes Tool hat seinen eigenen Ort für Anweisungen, und jede Kopie muss von Hand synchron gehalten werden.

Eine Quelle, bei Bedarf geladen

Die Alternative: Du hältst deine Standards an einem Ort, und die Agents holen sie, wenn eine Aufgabe sie braucht. Genau dafür gibt es MCP, das Model Context Protocol. Das ist ein offener Standard, mit dem KI-Tools externe Tools und Daten nutzen können.

Ist sqemes über MCP verbunden, bekommt ein Agent Tools, um deine Bibliothek zu durchsuchen und einen Skill zu laden. Betrifft eine Aufgabe deine API, kann er den Skill mit deinen API-Konventionen finden und laden. Ist ein Pull Request fertig, kann er die Review-Checkliste laden. Niemand muss etwas hineinkopieren.

Skills werden schrittweise geladen. Der Agent sieht zuerst die Gliederung eines Skills und liest eine Referenzdatei erst, wenn die Aufgabe sie braucht. So füllt ein großer Styleguide nicht das Kontextfenster, wenn nur eine Zeile zu korrigieren ist.

Was in einen Engineering-Skill gehört

Fang mit dem an, was Reviewer am häufigsten anmerken:

• Coding-Konventionen: Benennung, Struktur, Fehlerbehandlung, Logging.
• Die Review-Checkliste: was ein Pull Request haben muss, bevor er gemergt werden kann.
• Architekturkontext: wie das System zusammenhängt, als Referenzdatei, die der Agent liest, wenn er sie braucht.
• Doku-Stil: ein Leitfaden für jedes README und jede Doku-Seite.

Ein Skill kann auch Skriptdateien enthalten. Die Skripte reisen mit dem Skill mit, und das Tool, das sie lädt, führt sie auf seiner Seite aus. Code aus einem Skill führt sqemes selbst nie aus.

Personas für Rollen

Sobald du ein paar Skills hast, bündelt eine Persona sie. Eine Tech-Lead-Persona kann sagen: Lade die Coding-Konventionen, während Code geschrieben wird, lade die Review-Checkliste, wenn ein Pull Request geprüft wird, und nutze den Release-Notes-Prompt, wenn eine Version erscheint. Über MCP können Claude Code, Cursor und Codex diese Persona laden und in der Rolle arbeiten.

Einrichtung

In sqemes führt dich der Bereich Settings, API & MCP in drei Schritten durch die Einrichtung jedes Clients. Alle im Team verbinden sich mit dem eigenen Konto und sehen die Playbooks, auf die sie Zugriff haben. Die Rechte sind dieselben wie in der App: Ist ein Skill auf das Plattformteam beschränkt, bleibt er in jedem Agent beschränkt.

Ändere eine Konvention einmal, und jeder Agent lädt ab dann die neue Version. Ist die Freigabe eingeschaltet, wartet eine Änderung an einem geteilten Skill auf ihre Freigabe, bevor der Rest des Teams damit arbeitet.

Sieh dir an, wie der MCP-Server funktioniert oder was sqemes für Engineering-Teams tut.