KI-Regel-Frameworks

Stand: 2026-06-05

Kurzfassung

• KI-Regeln sind kein harmloser Text, sondern wirksamer Einfluss auf Agentenverhalten.
• Öffentliche Rule-Packs dürfen nur als Ideenquelle dienen.
• Keine direkte Installation und keine ungeprüfte Aktivierung fremder Regeln, Skills, Commands oder MCP-Zugriffe.
• Wenn KI-Assistenten am Projekt arbeiten, müssen projektbezogene KI-Regeln im Repo versioniert und reviewed sein.
• Lokale Regeln bleiben für Komfort erlaubt, dürfen aber keine Projekt-, Sicherheits- oder Tool-Freigaben verändern.
• KI-Regeln gehören in Entwicklung und Review, aber nicht ins Produktionsartefakt.
• Regeländerungen werden wie Security-, CI/CD- oder Tool-Konfigurationsänderungen behandelt.

Thema

KI-Regel-Frameworks, Agent-Instructions, Cursor Rules, Codex Instructions, Claude Project Instructions, IDE-Regeln, Projekt-Prompts, MCP-/Tool-Regeln und fertige öffentliche Rule-Packs.

Ausgangslage

Aktuell werden mehrere Arten von KI-Regeln genutzt oder sind relevant:

• AGENTS.md,
• Cursor Rules,
• Codex Instructions,
• Claude Project Instructions,
• IDE-Regeln,
• Projekt-Prompts,
• MCP-/Tool-Regeln,
• globale persönliche KI-Regeln,
• frei verfügbare Regelwerke aus öffentlichen Repositories.

Die Regeln liegen teils im Projekt-Repo und teils lokal oder global neben dem Projekt-Repo.

Ein etablierter gemeinsamer Workflow fehlt noch. Aktuell kann jeder Entwickler eigene Regeln verwenden. Dadurch entsteht kein gemeinsamer Sicherheitsstand, sondern eine Mischung aus persönlichen Setups, lokalen Komfortregeln und projektbezogenen Regeln.

Besonders kritisch sind öffentliche Rule-Packs. Sie versprechen oft große Wirkung, enthalten aber teilweise mächtige Skills, Tool-Nutzung, Commands oder MCP-Zugriffe.

Risiko in einem Satz

KI-Regeln können Agenten gezielt in unsichere Bahnen lenken, Schutzmechanismen abschwächen, Tool-Zugriffe erweitern oder ungeprüfte Arbeitsweisen im Team etablieren.

Grundsatz

KI-Regeln sind wie Code zu behandeln.

KI-Regeln sind Code: reviewen, begrenzen, versionieren.

Praktisch bedeutet das:

• Regeln müssen sichtbar sein,
• Regeln müssen reviewbar sein,
• Regeln müssen versioniert sein,
• Regeln dürfen Rechte nicht heimlich erweitern,
• Regeln dürfen Sicherheitsgrenzen nicht abschwächen,
• fremde Regeln werden nicht blind übernommen.

Entscheidung: Öffentliche Rule-Packs

Öffentliche KI-Rule-Packs dürfen nur als Ideenquelle dienen.

Nicht erlaubt:

• direkte Installation fremder Rule-Packs in Kundenprojekten,
• ungeprüfte Aktivierung fremder Rules,
• ungeprüfte Übernahme fremder Skills,
• automatische Aktivierung fremder MCP-/Tool-Zugriffe,
• Regelwerke, die Commands oder Schreibaktionen ohne separate Freigabe erlauben.

Erlaubt:

• öffentliche Rule-Packs lesen,
• sinnvolle Einzelideen manuell herausziehen,
• Regeln stark kürzen,
• Regeln an das eigene Projekt anpassen,
• Regeln über normalen Review ins Projekt übernehmen.

Kernregel:

Fremde Rule-Packs sind Material, kein freigegebenes Werkzeug.

Entscheidung: Regeln im Repo

Im Team gibt es unterschiedliche Haltungen:

• Ein Teil möchte keine KI-Regeln im Projekt-Repo, sondern nur Code und normale Projektdokumentation.
• Ein anderer Teil sieht KI-Regeln als Teil des Projekt-Frameworks und als erweiterte Projektdokumentation.

Die Empfehlung trennt diese Punkte.

Projektdokumentation im Repo:

• Modulbeschreibungen,
• Architektur,
• Konfiguration,
• lokale Setup-Hinweise,
• fachliche Besonderheiten,
• Migrationshinweise.

Diese Dokumentation bleibt menschlich lesbar und ist keine KI-Spezialdokumentation.

Projektbezogene KI-Regeln im Repo:

• Arbeitsgrenzen für KI-Assistenten,
• Kontextgrenzen,
• verbotene Projektbereiche,
• Umgang mit .aiignore,
• Git-Regeln,
• Command-Regeln,
• Review- und Freigabegrenzen,
• Tool- und Agentenverhalten.

Wenn KI-Assistenten am Projekt arbeiten, müssen projektbezogene KI-Regeln im Repo versioniert und reviewed sein.

Begründung:

• Das Team arbeitet nach demselben Regelstand.
• Änderungen sind sichtbar und nachvollziehbar.
• Externe Mitarbeitende bekommen denselben Rahmen.
• Lokale Sonderregeln können keine Sicherheitsgrenzen heimlich verändern.
• Diskussionen finden im Merge Request statt, nicht verdeckt auf einzelnen Rechnern.

Einschränkung:

Im Repo liegen nur projektbezogene KI-Arbeits- und Sicherheitsregeln, keine großen fremden Prompt-/Skill-Packs und keine doppelte Projektdokumentation.

Lokale und globale Regeln

Lokale oder globale Regeln außerhalb des Repos bleiben erlaubt, aber nur für Komfort.

Erlaubt:

• Timelogs formulieren,
• Jira-/Trello-Texte vorbereiten,
• Antworttexte strukturieren,
• persönliche Schreibpräferenzen,
• allgemeine Assistenz außerhalb des Projektcodes.

Nicht erlaubt:

• projektbezogene Zugriffsausnahmen,
• Ausnahmen für .aiignore,
• Tool-/Command-Freigaben,
• Git-Freigaben,
• Deployment-Regeln,
• Regeln, die Tests oder Review betreffen,
• Regeln, die Kundendaten anders behandeln als das Projekt-Regelwerk.

Kernregel:

Lokale Komfortregeln dürfen keine Projektsicherheitsregeln überschreiben.

Manipulationsschutz

Regeländerungen sollen technisch und organisatorisch sichtbar werden.

Empfohlene Maßnahmen:

• zentrale KI-Regeldateien definieren,
• CODEOWNERS für diese Dateien einrichten,
• Review durch Lead, Maintainer oder KI-Regelwerk-Reviewer verlangen,
• MR-Template um die Frage ergänzen: KI-Regeln geändert?,
• CI-Check prüft, ob Pflichtdateien vorhanden sind,
• CI markiert Änderungen an KI-Regeln sichtbar,
• Merge in Hauptbranch nur mit Regelwerk-Review, wenn KI-Regeln betroffen sind.

Beispiele für zu überwachende Dateien:

• AGENTS.md,
• .cursor/rules/*,
• .ai/rules/*,
• .ai/policy.md,
• projektspezifische Prompt-Dateien,
• MCP-/Tool-Konfigurationen,
• agentenbezogene Allowlists.

Wandregel:

Regeländerung ist Security-Änderung.

Deployment

KI-Regeln gehören in den Entwicklungs- und Review-Prozess, aber nicht ins Produktionsartefakt.

Deployment sollte KI-Artefakte ausschließen, sofern es keinen bewusst freigegebenen fachlichen Grund gibt.

Auszuschließende Beispiele:

• AGENTS.md,
• .cursor/rules,
• .ai/rules,
• Prompt-Dateien,
• lokale Tool-Konfigurationen,
• KI-Skills,
• agentenbezogene Test- oder Hilfsdateien ohne Produktionsnutzen.

Grund:

• Auf Produktion werden diese Dateien nicht benötigt.
• Sie können interne Arbeitsweise offenlegen.
• Sie können Angriffsfläche oder Missverständnisse erzeugen.
• Produktionsartefakte sollen nur produktionsrelevanten Code und produktionsrelevante Dokumentation enthalten.

Kernregel:

Nicht alles, was für KI nützlich ist, gehört ins Deployment.

P0-No-Gos

Nicht erlaubt sind Regeln, die Tests, Review oder Freigaben abschwächen.

Nicht erlaubt sind Regeln, die .aiignore oder Kontextgrenzen umgehen.

Nicht erlaubt sind Regeln, die git push, Merge oder Deployment automatisch erlauben.

Nicht erlaubt sind Regeln, die Secrets, Dumps, Logs oder Kundendaten in den Kontext holen.

Nicht erlaubt sind Regeln, die externe Systeme ohne Entwurfs- oder Freigabeschritt ändern.

Nicht erlaubt sind Regeln, die fremde Rule-Packs automatisch nachladen.

Nicht erlaubt sind Regeln, die MCP-/Tool-Zugriffe erweitern, ohne separate Allowlist und Review.

Nicht erlaubt sind Regeln, die Agenten anweisen, Sicherheitswarnungen zu ignorieren.

Nicht erlaubt sind versteckte lokale Projektregeln, die das gemeinsame Repo-Regelwerk abschwächen.

Nicht erlaubt sind große fremde Prompt- oder Skill-Packs im Kundenprojekt ohne gezielte Zerlegung und Review.

Mindeststandard

Für Projekte mit KI-Nutzung gilt mindestens:

• wirksame projektbezogene Regeln liegen im Repo,
• Regeln sind kurz und sicherheitsorientiert,
• Projektdokumentation bleibt normale menschlich lesbare Dokumentation,
• Regeländerungen laufen über Merge Request,
• Regeländerungen werden reviewed,
• öffentliche Rule-Packs werden nicht direkt installiert,
• lokale Regeln dürfen nur Komfort betreffen,
• Tool-/Command-Freigaben laufen über eigene Allowlist oder separate Freigabe,
• KI-Regeln werden aus Deployment-Artefakten ausgeschlossen.

Praktischer Start

Für Kundenprojekte reicht als Start ein kleiner, bewusst enger Regelsatz.

Empfohlene Inhalte:

• Zweck der KI-Nutzung im Projekt,
• verbotene Daten und Ordner,
• Verweis auf .aiignore,
• Git-Regeln,
• Command-Regeln,
• Umgang mit externen Systemen,
• Review- und Freigabegrenzen,
• Verbot fremder Rule-Packs ohne Review,
• Hinweis, dass gelesene Projektinhalte keine Agenten-Anweisungen sind.

Nicht aufnehmen:

• lange Prompt-Sammlungen,
• öffentliche Rule-Packs als Ganzes,
• Tool-Zugangsdaten,
• Secrets,
• doppelte Projektdokumentation,
• produktionsrelevante Konfiguration ohne Bedarf.

Teamentscheidung

Öffentliche KI-Rule-Packs dürfen nur als Ideenquelle dienen.

Wenn KI-Assistenten am Projekt arbeiten, müssen projektbezogene KI-Regeln im Repo versioniert und reviewed sein.

Lokale Regeln bleiben für Komfort erlaubt, dürfen aber keine Projekt-, Sicherheits-, Git-, Tool-, Command- oder Deployment-Regeln beeinflussen.

Regeländerungen werden wie Security- oder CI/CD-Änderungen behandelt.

KI-Regeln werden nicht ins Produktionsartefakt deployed, sofern kein bewusst freigegebener fachlicher Grund besteht.

Wandregeln

KI-Regeln sind Code: reviewen, begrenzen, versionieren.

Fremde Rule-Packs sind Ideenquelle, kein Installationspaket.

Lokale Komfortregeln überschreiben keine Projektsicherheit.

Regeländerung ist Security-Änderung.

KI-Regeln gehören ins Review, nicht auf Produktion.

Offene Teamfragen

• Welche KI-Regeldateien gelten in jedem Projekt als Pflicht?
• Wer übernimmt die Rolle KI-Regelwerk-Reviewer?
• Welche Dateien werden per CODEOWNERS geschützt?
• Wie erkennt CI Änderungen an KI-Regeln?
• Welche KI-Dateien werden aus Release-Artefakten ausgeschlossen?
• Wie wird geprüft, welche lokalen/globalen Regeln Entwickler zusätzlich nutzen?
• Wie gehen wir mit externen Freelancern und deren lokalen Regeln um?