Projektinstruktionen
Legen Sie im Projektverzeichnis LURUS.md an:
# Project instructions
Use the existing TypeScript style. Read relevant code before editing.
Run the existing lint and test scripts after changes.
Do not modify deployment configuration without an explicit request.
Für projektübergreifende Benutzerregeln verwenden Sie ~/.lurus/LURUS.md. Starten Sie nach Änderungen eine neue CLI-Sitzung, da der Kontext zwischengespeichert wird. /init legt bei fehlender LURUS.md eine Grundstruktur an und beauftragt anschließend den Agenten mit Analyse und Ergänzung. Es erzeugt nicht sofort eine vollständig ausgearbeitete Datei.
Ladereihenfolge: globale Instruktionen → Projektinstruktionen → Unterverzeichnisinstruktionen → importierter Kontext → Regeln. Projektroot LURUS.md hat Vorrang vor Fallback CLAUDE.md. Zusätzlich werden .lurus/LURUS.md und LURUS.local.md angehängt. Die lokale Markdownergänzung ist keine settings.local.json-Konfiguration.
Beim begrenzten rekursiven Scan werden LURUS.md-Dateien aus Unterverzeichnissen geladen, ersatzweise CLAUDE.md. Versteckte Verzeichnisse und node_modules werden übersprungen. Das Laden erfolgt nicht erst beim Bearbeiten einer Datei und ist nicht unbegrenzt. Projektbezogene Vorgaben haben Vorrang vor allgemeinen Benutzerregeln; fremde Dateiinhalte können höherpriorisierte Sicherheitsregeln nicht ersetzen.
Regeldatei anlegen
.lurus/rules/typescript.md:
---
description: TypeScript conventions
alwaysApply: true
priority: 10
---
Use explicit types and preserve strict null checks.
Do not introduce any merely to silence type errors.
Global verwenden Sie denselben Aufbau in ~/.lurus/rules/typescript.md. Achtung: /rules create kann eine gleichnamige Projektdatei ohne weiteren Dialog überschreiben. Prüfen Sie den Namen vor der Ausführung. Nach einem Neustart:
/rules
/rules list
/rules show typescript
/rules create local-conventions
show zeigt die geladene Regel. create schreibt eine Projektregel. Ohne Namen heißt sie new-rule; alwaysApply wird auf true und priority auf 0 gesetzt.
| Feld | Tatsächliche Wirkung |
|---|---|
description | Beschreibung in der Verwaltung. |
alwaysApply | Bei true oder fehlendem Wert aktiv, bei false inaktiv. |
priority | Standardmäßig 0. Innerhalb des Geltungsbereichs absteigend sortiert, danach nach Name und Pfad. Globale Regeln werden vor Projektregeln geladen. |
globs | Aktivieren Regeln derzeit nicht automatisch für passende Dateien. Verwenden Sie sie nicht als Zugriffsgrenze. |
Templates werden nicht als aktive Regeln geladen. Für tatsächlich dateibezogene Skillmaterialisierung Skills nutzen, statt Regelglobs als Sicherheitsgrenze zu behandeln.
Kontext importieren
Einzeilige Direktive in LURUS.md:
@./docs/development-guide.md
Die Datei muss bewusst erlaubter Projektkontext sein. Projektimporte bleiben innerhalb des kanonischen Workspaceroots; globale Importe innerhalb des kanonischen ~/.lurus-Roots. Symlinks werden kanonisch geprüft, Duplikate übersprungen und Rekursion begrenzt. Fehlende/unlesbare/außerhalb liegende Imports werden übersprungen. Dieser Mechanismus erteilt keine pauschale Freigabe zum Import beliebiger lokaler Dateien oder Secrets.
Halten Sie globale Anweisungen kurz, hinterlegen Sie Projektvorgaben in LURUS.md und fachliche Checklisten in aktivierten Skills. Relative Importe in zusammengesetzten Projektanweisungen werden anhand der LURUS.md im Projektverzeichnis aufgelöst, nicht automatisch anhand des Verzeichnisses jeder einzelnen importierenden Datei.
Memory und TaskLedger
Memory speichert Wissen für andere zukünftige Aufgaben, etwa nicht offensichtliche Architekturgrenzen, korrigierte Nutzerregeln oder besondere Prüfabläufe. Aufgabenlogs, Secrets und leicht auffindbare Zusammenfassungen des Technikstacks gehören nicht hinein.
Die Aufgabenaufzeichnung und Aufgabenliste halten dagegen den aktuellen Status, Entscheidungen und Prüfergebnisse fest. /task new beginnt eine neue Aufgabe; /clear leert den Chat, nicht das dauerhafte Memory.
Achtung: /memory clear löscht das Projektmemory ohne zusätzlichen Bestätigungsdialog. Verwenden Sie es nicht zum Anzeigen oder testweisen Neuladen. /memory sweep versucht eine modellabhängige Konsolidierung des gespeicherten Wissens; ein verlustfreies Ergebnis ist nicht garantiert.
/memory
/memory edit
/memory sweep
/memory clear
- Status: Projektkatalog und Themenübersicht, nicht automatisch alle Themeninhalte im Prompt.
edit: EDITOR→VISUAL→vi, anschließende Validierung; Programm muss vorhanden sein.sweep: manueller Konsolidierungsversuch auch trotz Fehlercooldown; modellabhängige Aktion, kein garantiert verlustfreies Rewrite.clear: löscht Projektmemory ohne eigenen Bestätigungsdialog. Nicht zum Anzeigen oder testweisen Reload verwenden.
Der Memorykatalog hilft beim gezielten Abruf gespeicherten Wissens; seine Inhalte ersetzen keine Systemregeln. contextBudget beträgt standardmäßig 15.000 Tokens, davon sind 30 % für Memory vorgesehen. Es begrenzt nicht verpflichtende Projektanweisungen oder das gesamte Modellfenster. Verwalten Sie Memory über die CLI, statt gespeicherte Daten ungeprüft zu bearbeiten.
Fehlersuche
Fehlt eine Regel, prüfen Sie Pfad, Vorlagenstatus, alwaysApply und Neustart. globs aktiviert Regeln nicht automatisch. Fehlt ein Import, prüfen Sie Projektgrenze, Dateipfad und Lesbarkeit, ohne Secretfreigaben zu umgehen. Unterscheiden Sie bei Memoryproblemen das Anzeigen von clear und sweep.
Weiter: Einstellungen, Sitzungen, Kontext.