Steering Files oder Shared Skills? Unternehmensvorgaben für Coding-Agenten

Wenn wir mit Coding-Agenten arbeiten, muss das Unternehmen dann zentral vorgeben, wie jeder Entwickler seinen Agenten benutzt?

Meine Antwort war ja und nein. Die Sicherheitsrichtlinien, Architekturvorgaben und Betriebsanforderungen des Unternehmens müssen dem Agenten verfügbar sein. Ob ein Entwickler dagegen viele Rückfragen möchte oder mit welchem persönlichen Ablauf er von der Idee zur Implementierung kommt, ist erst einmal seine Arbeitsweise.

Die nächste Frage ist dann, wo diese Vorgaben hingehören. Viele Teams schreiben alles in eine Steering-Datei, die mit jeder Woche länger wird. Die eigentlichen Richtlinien liegen gleichzeitig weiter in Confluence, in Word-Dokumenten oder in den Köpfen einzelner Kollegen.

In diesem Post geht es darum, wie du diese Informationen als zentral gepflegte Skills bereitstellst, was weiterhin in ein Steering File gehört und wie du mit einem kleinen Pilot anfängst. Ich nutze Coding-Agenten als Beispiel. Die genaue Einbindung hängt vom eingesetzten Harness ab, das Prinzip ist aber dasselbe: wenige dauerhafte Regeln und gezielt geladener Kontext für die aktuelle Aufgabe.

Der Agent kann eure internen Vorgaben nicht kennen

Ein Coding-Agent bringt allgemeines Wissen mit, aber er kennt nicht automatisch die freigegebenen Libraries, die internen Infrastrukturbausteine oder die Betriebsanforderungen deiner Organisation. Auch aktuelle technische Details sollte er bei Bedarf aus geeigneten Quellen beziehen, statt sich ausschließlich auf sein Trainingswissen zu verlassen.

Wenn diese Informationen fehlen, entsteht vielleicht funktionierender Code, der trotzdem nicht ins Unternehmen passt. Dann erfährt das Team erst im Review, dass ein anderer Construct verwendet werden muss, eine Abhängigkeit nicht freigegeben ist oder ein Betriebsnachweis fehlt.

Mein Ziel ist deshalb, relevante Vorgaben schon bei der Spec und beim Plan verfügbar zu machen, nicht erst bei der Implementierung. Ein Agent, der eine Architektur entwirft, braucht die Architekturvorgaben. Ein Agent, der eine Pipeline einbaut, braucht den Pipeline-Standard. Nicht jeder Agent braucht zu jedem Zeitpunkt beides vollständig.

Steering Files und Skills haben unterschiedliche Aufgaben

Steering Files sind ein naheliegender Einstieg, weil viele Tools sie direkt anbieten. Problematisch wird es, wenn eine Datei zum Sammelbecken für sämtliche Unternehmensvorgaben wird.

Bei dauerhaft geladenen Anweisungen ist ihr Inhalt in jeder Session im Kontext, unabhängig davon, ob der Agent gerade eine Pipeline baut, eine Datenbankabfrage debuggt oder eine Dokumentation schreibt. Je mehr fachfremder Kontext hinzukommt, desto schwieriger wird es, die relevanten Regeln übersichtlich zu halten.

Skills ermöglichen eine andere Struktur: Zunächst ist eine kurze Beschreibung verfügbar, und der vollständige Inhalt wird geladen, wenn die Aufgabe dazu passt. Details können wiederum in Referenzdateien liegen. So muss nicht jede Session sämtliche Vorgaben mitführen.

Das genaue Ladeverhalten ist allerdings eine Eigenschaft des Harnesses. Manche Tools unterstützen auch bedingt geladene Steering-Regeln. Entscheidend ist deshalb nicht allein der Dateiname, sondern die Frage: Was wird immer geladen, und was nur für die passende Aufgabe?

Ich würde die Aufteilung so vornehmen:

Ein Skill ist damit kein neues Ablageformat für ein riesiges Regelwerk, sondern ein Einstieg in das Wissen, das für eine konkrete Aufgabe gebraucht wird.

Unternehmensvorgaben zentral, persönliche Arbeitsweise individuell

Das Unternehmen muss nicht jede Vorliebe beim Umgang mit Agenten vereinheitlichen. Ob jemand zunächst ein Interview führt, wie ausführlich sein persönlicher Plan ist oder welche Hilfsskills er verwendet, kann individuell bleiben.

Anders ist es bei Anforderungen an das Ergebnis und an verbindliche Prozesse. Sicherheitsrichtlinien, Architekturstandards, Pflichtprüfungen und erforderliche Freigaben sind keine persönliche Präferenz. Wenn eine Spec bestimmte Nachweise enthalten muss, kann ein Entwickler nicht durch einen persönlichen Skill darauf verzichten.

Die Grenze verläuft also nicht einfach zwischen „Code“ und „Arbeitsweise“, sondern zwischen verbindlichen Anforderungen des Unternehmens und frei wählbaren Methoden innerhalb dieses Rahmens.

Diese Trennung hilft auch bei der Pflege: Das Unternehmen verantwortet die zentralen Vorgaben. Entwickler können eigene Skills ergänzen, dürfen damit aber keine zentralen Anforderungen aufheben.

Ein konkreter Einstieg: der Coding-Style-Skill

Ein guter erster Skill ist der Coding-Style. Solange Menschen Code reviewen und warten, sollte der nächste Leser schnell verstehen, was passiert, und nicht in jedem Repository einen völlig anderen Stil vorfinden.

Für eine fiktive Musterbank könnte eine SKILL.md im offenen Agent Skills Format so aussehen:

---
name: musterbank-coding-style
description: Coding-Style der Musterbank für TypeScript und AWS CDK. Verwenden, wenn Code in einem Musterbank-Repository geschrieben, geändert oder reviewt wird.
---

# Musterbank Coding Style

## Vor Beginn
- Lies die für die Aufgabe relevanten Referenzen.
- Wenn eine Vorgabe unklar ist oder sich widerspricht, kläre sie vor der Umsetzung.
- Eine benötigte Ausnahme darfst du nicht selbst genehmigen.

## Allgemein
- Sprache im Code und in Kommentaren ist Englisch, Fachbegriffe aus dem Bankwesen bleiben unübersetzt.
- Keine neuen Abhängigkeiten ohne Eintrag in der freigegebenen Library-Liste (siehe references/approved-libraries.md).

## AWS CDK
- Ressourcen nur über die internen L3-Constructs aus @musterbank/cdk-constructs anlegen.
- Jede Ressource bekommt die Pflicht-Tags CostCenter, DataClassification und Owner.
- Keine Ressourcen außerhalb von eu-central-1 ohne dokumentierte Ausnahme.
- Beispiele für die internen Constructs stehen in references/cdk-examples.md.

## Logging
- Strukturierte Logs im JSON-Format, keine personenbezogenen Daten in Logs.

## Vor Abschluss
- Führe die im Repository vorgesehenen Tests und Prüfungen aus.
- Benenne offene Punkte und Abweichungen ausdrücklich.

Die Regeln und Paketnamen in diesem Beispiel sind erfunden. In einem echten Unternehmen würde ich bestehende Vorgaben übernehmen und mit den Verantwortlichen klären, statt beim Schreiben des Skills neue Standards zu erfinden.

Der Skill bleibt kurz. Die Library-Liste und die Construct-Beispiele liegen daneben, damit sie unabhängig gepflegt und gezielt gelesen werden können.

Aus einer Richtlinie einen brauchbaren Skill machen

Eine Word-Datei in Markdown umzuwandeln ist noch keine ausreichende Umsetzung. Der Agent muss erkennen können, wann die Vorgabe gilt und was er konkret tun soll.

Ich würde für jeden Skill vier Dinge klären:

1. Auslöser: Bei welchen Aufgaben muss der Skill geladen werden? Die Beschreibung sollte das eindeutig sagen.
2. Handlung: Was soll der Agent vor, während und nach der Aufgabe tun?
3. Referenzen: Welche Details braucht er in welcher Situation, und wo stehen sie?
4. Grenzen: Wann muss er nachfragen, anhalten oder eine Ausnahme an die zuständige Person geben?

Zusätzlich sollte nachvollziehbar sein, aus welcher freigegebenen Richtlinie eine Regel stammt. Der Skill ist die praktische Aufbereitung der Vorgabe, nicht eine zweite, unabhängig davon gepflegte Wahrheit.

Wenn die Richtlinie unklar ist, darf diese Unklarheit nicht stillschweigend beim Übersetzen verschwinden. Dann ist zuerst eine Entscheidung durch den zuständigen Verantwortlichen nötig.

Skills nach Aufgaben schneiden

Wenn sämtliche Standards in einem einzigen Unternehmens-Skill landen, hat man das Problem des großen Steering Files nur verschoben. Besser sind abgegrenzte Skills, beispielsweise für Architekturprüfung, Pipeline-Änderungen, Infrastruktur und Betriebsdokumentation.

Die Beschreibung entscheidet mit darüber, ob der Agent den richtigen Einstieg findet. „Enthält unsere IT-Vorgaben“ ist dafür zu unspezifisch. „Verwenden, wenn eine CI/CD-Pipeline angelegt oder geändert wird“ benennt dagegen eine konkrete Situation.

Ein Beispiel aus dem Gespräch war die Person im Plattformteam, zu der jeder geht, wenn er eine neue Pipeline braucht. Sie baut die Pipeline jedes Mal nach demselben Muster ein und öffnet einen Pull Request. Dieses wiederkehrende Vorgehen ist ein guter Kandidat für einen Skill: benötigte Informationen, freigegebene Bausteine, Umsetzungsschritte und Prüfungen.

Die Plattformverantwortlichen bleiben wichtig. Ihre Aufgabe verschiebt sich dabei von der wiederholten manuellen Umsetzung zur Pflege des Standards und der Beispiele. Spezialisierten Agenten kann man passende Skill-Sets geben, aber auch ein einzelner Agent profitiert schon von dieser Aufteilung.

Zentral pflegen heißt nicht automatisch überall aktuell

Ein gemeinsames Repository ist ein sinnvoller Ort für Skills und Referenzen. Es sollte aber klar sein, wer Änderungen verantwortet, wer sie reviewt und wie eine freigegebene Version in den Teams ankommt.

Ein Merge im zentralen Repository aktualisiert nicht automatisch jeden lokalen Agenten. Die Organisation braucht einen definierten Verteilungsweg, beispielsweise versionierte Pakete oder nachvollziehbare Updates in den konsumierenden Repositories. Wie dieser Weg aussieht, hängt vom Harness und der Entwicklungsumgebung ab.

Für einen nachvollziehbaren Einsatz sollte das Team erkennen können, welche Version es verwendet. Auch der Umgang mit dringenden Änderungen und veralteten Versionen muss geklärt sein. Sonst existiert zwar ein aktueller Standard, aber die Agenten arbeiten weiterhin mit einer alten Kopie.

Ein geladener Skill ist noch keine durchgesetzte Kontrolle

Gerade in regulierten Unternehmen ist diese Grenze wichtig: Skills erklären die Regeln. Sie garantieren nicht, dass ein Agent sie lädt, richtig versteht oder vollständig einhält.

Für Anforderungen, die technisch geprüft oder begrenzt werden können, sollte es deshalb zusätzlich Kontrollen geben. Formatierung kann ein Formatter übernehmen, bestimmte Infrastrukturvorgaben lassen sich automatisiert prüfen, und fehlende Produktionsrechte verhindern Aktionen, die der Agent gar nicht ausführen dürfen soll.

Auch die Aussage des Agenten, er habe alle Vorgaben beachtet, ersetzt kein Review und keine erforderliche Freigabe. Skills machen eine regelkonforme Umsetzung wahrscheinlicher und erleichtern die Prüfung. Sie sind aber kein Compliance-Nachweis für sich genommen.

Mit zwei Skills anfangen und am Ergebnis lernen

Mein Vorschlag für den Einstieg ist ein Coding-Style-Skill und ein Skill für die wichtigsten Architekturvorgaben. Beide sollten auf bestehenden Standards beruhen und einen klaren Verantwortlichen haben.

Testet sie an einer überschaubaren Änderung. Prüft dabei nicht nur, ob der Agent die Dateien laden kann, sondern ob er sie bei der richtigen Aufgabe tatsächlich verwendet, notwendige Referenzen liest und bei offenen Entscheidungen nachfragt.

Im Review würde ich festhalten:

• Welche Vorgaben wurden korrekt umgesetzt?
• Welche wurden übersehen oder missverstanden?
• Welche Informationen fehlten in den Referenzen?
• Welche Anforderungen sollten zusätzlich automatisiert geprüft werden?

Auch eine sachfremde Aufgabe ist ein sinnvoller Test: Der Coding-Style-Skill sollte nicht unnötig geladen werden, wenn der Agent beispielsweise nur einen allgemeinen Text formuliert.

Aus diesen Beobachtungen werden Beschreibung, Anweisungen und Referenzen verbessert. Erst danach würde ich weitere Unternehmensvorgaben ergänzen.

Fazit

Unternehmenswissen gehört nicht pauschal in eine immer längere Steering-Datei. Wenige dauerhafte Anweisungen, klar zugeschnittene Skills und gezielt geladene Referenzen machen den Kontext besser handhabbar.

Zentral vorgegeben wird, was für Ergebnisse und Prozesse verbindlich ist. Die persönliche Arbeitsweise bleibt innerhalb dieses Rahmens individuell. Technische Kontrollen und Freigaben sichern Anforderungen ab, die nicht allein von der Aufmerksamkeit eines Agenten abhängen dürfen.

Fangt mit zwei konkreten Skills an, klärt Pflege und Verteilung und überprüft ihre Wirkung an einer echten Änderung. So entsteht aus vorhandenen Richtlinien ein nutzbarer Einstieg für Agenten, statt nur ein weiteres Dokument, das niemand liest.

Wenn du Unterstützung dabei möchtest, eure Vorgaben in eine solche Struktur zu bringen, melde dich gerne bei mir.

Referenzen

• Agent Skills Spezifikation
• Kiro Dokumentation