Läuft komplett lokal: Steering ist nur eine Markdown-Datei im Projekt. Keine Abhängigkeiten.
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:
# 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.Standardmäßig wird Steering immer einbezogen (Inclusion „always“). Über Front-Matter lässt sich das steuern (z. B. nur bei bestimmten Dateien) — hier nicht nötig.
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.