Lab 5: Steering-Mini

← Zurück zur Übersicht

Ziel

Eine kleine Steering-Datei anlegen und beobachten, wie sich Kiros Verhalten sofort daran hält — bei jedem folgenden Prompt, ohne dass man die Regeln erneut nennt.

Vorbereitung

• Ein beliebiges Projekt geöffnet (z. B. das Kanban-Board aus Lab 2).
• Kiro im Chat-Modus.

Schritt 1 – Ausgangsverhalten festhalten

Stelle eine kurze Frage, z. B.:

Schreibe eine kleine Funktion, die prüft, ob eine Zahl gerade ist.

Notiere: In welcher Sprache/Stil antwortet Kiro? Kommentare? Erklärtext?

Schritt 2 – Steering-Datei anlegen

Erstelle .kiro/steering/tech.md:

---
inclusion: always
---

# Team-Regeln

- Antworte immer auf Deutsch.
- Nutze TypeScript, keine var-Deklarationen (nur const/let).
- Kommentiere jede Funktion mit einer kurzen Zeile, was sie tut.
- Halte Antworten knapp: Code zuerst, dann höchstens zwei Sätze Erklärung.

Schritt 3 – Wirkung prüfen

Stelle eine ähnliche Frage wie in Schritt 1, aber ohne die Regeln zu wiederholen:

Schreibe eine kleine Funktion, die prüft, ob ein String eine gültige
E-Mail-Adresse ist.

Beobachte: Kiro antwortet jetzt auf Deutsch, in TypeScript, mit const/let, kurzem Kommentar und knapper Erklärung — obwohl du das im Prompt gar nicht gesagt hast.

Schritt 4 – Regel ändern, sofort wirksam

Ändere in tech.md eine Regel (z. B. „Antworte immer auf Englisch“) und speichere. Nächster Prompt → das neue Verhalten greift sofort beim nächsten Turn.

Lernpunkte

• Steering ist ein persistentes Gedächtnis: einmal definiert, gilt es für jeden Turn.
• Trennung: Steering = „wie gebaut wird“, Specs = „was gebaut wird“.
• Global (~/.kiro/steering/) vs. Projekt (.kiro/steering/); Projekt hat i. d. R. Vorrang.
• Spart Tokens/Credits, weil man Regeln nicht in jedem Prompt wiederholt.
• Zentrales Team-Steering sichert einheitliche Standards über alle Teams.

Wofür ist Steering gut? Beispiele

Steering ist überall dort sinnvoll, wo etwas dauerhaft gelten soll, ohne dass du es in jedem Prompt wiederholst. Ein paar typische Einsatzfälle:

Wie funktioniert Steering?

Steering-Dateien sind einfache Markdown-Dateien im Ordner .kiro/steering/. Kiro liest sie und legt ihren Inhalt zu Beginn in den Kontext des Gesprächs.

Was ist Front-Matter?

Front-Matter ist ein kleiner Kopfblock ganz oben in der Datei, eingerahmt von zwei Zeilen mit drei Bindestrichen (---). Darin stehen Einstellungen im YAML-Format — also einfache schlüssel: wert-Paare. Bei Steering steuert dieser Block, wann die Datei geladen wird. So sieht das aus:

---
inclusion: fileMatch
fileMatchPattern: "*.tsx"
---

# Regeln für React-Komponenten
- Nutze funktionale Komponenten, keine Klassen.
- Jede Komponente bekommt einen kurzen Kommentar.

Alles zwischen den beiden --- ist die Konfiguration, alles darunter der eigentliche Inhalt. Wichtig: Das Front-Matter muss ganz am Anfang der Datei stehen, ohne Leerzeile davor. Wenn du gar kein Front-Matter angibst, gilt automatisch always — genau das war bei unserer tech.md oben der Fall.

Die vier Modi (der Wert bei inclusion:)

• always – immer geladen (Standard, wenn kein Front-Matter da ist). Gut für Kern-Regeln, die überall gelten.
• fileMatch – nur, wenn bestimmte Dateien im Spiel sind (z. B. nur bei *.tsx, gesteuert über fileMatchPattern). Spart Platz im Kontext.
• manual – nur auf Abruf, wenn du sie mit #dateiname im Chat ziehst.
• auto – wird automatisch aktiv, wenn deine Anfrage thematisch passt.

Hinweis: In der Kiro CLI werden diese Modi aktuell nicht ausgewertet — dort werden immer alle Steering-Dateien geladen.

Wie das Steering beim Agenten ankommt

Interessant ist, was Kiro dem Modell wirklich schickt. Deine Steering-Datei wird als „Included Rules“ in den Kontext gelegt — und Kiro hängt dabei automatisch noch einen kleinen Block über deine Arbeitsumgebung an. Für unsere tech.md sieht das ungefähr so aus:

---
inclusion: always
---

# Team-Regeln

- Antworte immer auf Deutsch.
- Nutze TypeScript, keine var-Deklarationen (nur const/let).
- Kommentiere jede Funktion mit einer kurzen Zeile, was sie tut.
- Halte Antworten knapp: Code zuerst, dann höchstens zwei Sätze Erklärung.

<EnvironmentContext>
This information is provided as context about user environment. Only consider it if it's relevant to the user request ignore it otherwise.

<OPEN-EDITOR-FILES>
No files are open
</OPEN-EDITOR-FILES>

<ACTIVE-EDITOR-FILE>
No file is active in editor
</ACTIVE-EDITOR-FILE>
</EnvironmentContext>

Der obere Teil ist deine Steering-Regel, genau wie du sie geschrieben hast. Der <EnvironmentContext>-Block darunter kommt von Kiro selbst. Er sagt dem Modell, welche Dateien gerade offen oder aktiv sind — hier keine. Diesen Block schreibst du nicht, er wird bei jedem Turn automatisch ergänzt.

Warum ist das gut zu wissen? Zum einen sieht man, dass Steering wirklich als Text im Kontext landet und kein magischer Schalter ist. Zum anderen erklärt es, warum sich Antworten manchmal ändern, wenn eine andere Datei geöffnet ist: Kiro teilt dem Modell diesen Zustand mit.

Warum wirkt Steering nicht immer? Ist das ein Bug?

Wichtig vorab zur Einordnung: Die offizielle Kiro-Dokumentation beschreibt Steering positiv — es soll dafür sorgen, dass Kiro sich „konsequent“ an deine Vorgaben hält. Eine eigene Fehlerseite zum Thema „Steering wird nicht befolgt“ gibt es dort nicht.

In der Praxis erlebt man aber, dass sich der Agent nicht immer an eine Steering-Regel hält. Das ist meist kein technischer Fehler in Kiro, sondern liegt in der Natur der Sache: Steering ist keine harte Wenn-dann-Regel wie in einem Programm, sondern zusätzlicher Kontext für ein KI-Modell. Das Modell versucht, sich daran zu halten, aber unter bestimmten Umständen geht eine Regel unter.

Dass es dieses Verhalten gibt, ist offen dokumentiert — nämlich im Bugtracker von Kiro. Kiro nutzt sein GitHub-Repository (kirodotdev/Kiro) als öffentlichen Ort für Fehler und Verbesserungswünsche. Dort finden sich reale Meldungen dazu, z. B.:

• Issue #6518: Der Agent hatte die Steering-Datei im Kontext, hielt sich beim Ausführen einer Spec-Task aber erst daran, nachdem der Nutzer zweimal darauf hingewiesen hatte.
• Issue #2250: Eine Regel mit inclusion: always wurde von allgemeinen Task-Anweisungen „überstimmt“, obwohl sie eigentlich gelten sollte.
• Issue #6171 / #9117: Steering-Dateien (teils die globalen aus ~/.kiro/steering/) wurden gar nicht erst in den Kontext geladen.

Das zeigt zweierlei: Erstens ist es ein bekanntes, offen behandeltes Thema und kein Zeichen, dass du etwas falsch machst. Zweitens lohnt sich ein Blick in den Bugtracker, wenn etwas nicht wie erwartet läuft — oft steht dort schon eine Erklärung oder ein Workaround.

Typische Ursachen aus der Praxis

Merksatz: Steering ist ein starker, aber kein garantierter Hebel. Je kürzer, klarer und konkreter die Regeln sind und je gezielter sie geladen werden, desto zuverlässiger hält sich der Agent daran. Wenn eine Regel wirklich hart erzwungen werden muss, ist oft ein anderer Mechanismus die bessere Wahl (z. B. ein Lint-/Build-Schritt oder eine Permission-Regel). Und wenn etwas klar nicht funktioniert: im Bugtracker nachsehen oder dort selbst melden.