Ein konzeptionelles Minimum, kein Website-Verzeichnisbaum
Dies ist ein minimales konzeptionelles Beispiel, keine Darstellung des echten Website-Aufbaus.
project/
├── AGENTS.md
├── agent_instructions/
│ ├── [project-defined].md
│ └── [other-project-defined].md
├── specifications/
│ └── [project-defined specification documents]
└── ...
Der zentrale Einstieg findet dauerhafte Markdown-Anweisungen. Dateinamen, Anzahl, Quellverzeichnisse, Testwerkzeuge und Spezifikationsgranularität sind Projektentscheidungen. Der Spezifikationslebenszyklus nutzt die drei folgenden Verzeichnisse. Eine einzelne agentengepflegte Master-Datei bleibt eine untersuchte Option, keine Pflicht.
Der Spezifikationslebenszyklus: specifications/requests/ enthält menschlich verfasste, noch umzusetzende Anfragen; specifications/archive/ bewahrt umgesetzte menschliche Anfragen als historische Aufzeichnungen; specifications/current/ enthält agentengepflegte Beschreibungen des aktuell erforderlichen Produktverhaltens. Umgesetzte Anfragen unverändert archivieren und aktuelle Spezifikationen pflegen. Direkte Prompts und Gespräche können Entwicklung ohne formale Spezifikationsdatei beauftragen; der aktuelle Stand wird unabhängig vom Anfrageformat dokumentiert.
Spezifikationen verwalten
SHAPE trennt menschlich verfasste Änderungsanforderungen von agentengepflegten aktuellen Soll-Spezifikationen. Formale Anforderungen können warten, bis ihre Umsetzung autorisiert ist. Umgesetzte Anforderungen werden archiviert; aktuelle Soll-Spezifikationen beschreiben fortlaufend die geforderte Produktfunktionalität.
specifications/requests/— Menschlich verfasste Anforderungen, deren Umsetzung noch aussteht.specifications/archive/— Umgesetzte menschliche Anforderungen zur Nachvollziehbarkeit.specifications/current/— Agentengepflegte, logisch gegliederte Spezifikationen der aktuell geforderten Funktionalität.
Gesprächsanweisungen müssen vor der Umsetzung nicht in requests/ abgelegt werden: Sie
können den Agenten unmittelbar steuern. Der dargestellte Weg über requests/ ist für
Gespräche optional. Hinweise zur Pflege stehen unter
Spezifikationen.
Die minimale Orientierungsanweisung
# AGENTS.md
Read and observe all Markdown (`.md`) files in `agent_instructions/` before starting work and throughout implementation.
Der Einstieg verweist auf alle Markdown-Dateien, statt sie aufzuzählen. Jede Anweisungsdatei erklärt ihren Zweck zu Beginn. Namen wie STACK.md, DESIGN.md, ARCHITECTURE.md, LIBRARIES.md und OBJECTIVES.md sind Beispiele, keine Pflicht. Der echte Website-Einstieg ist umfangreicher; siehe Repository-Rundgang.
Was wohin gehört und wer entscheidet
| Kategorie | Inhalt und Abgrenzung | Entscheidungen und Agentenarbeit | Zweck und Geltung |
|---|---|---|---|
Zentrales AGENTS.md | Orientierungseinstieg; kein universeller Detailkatalog | Eigentümer kontrolliert Änderungen; Agenten lesen | Dauerhaften Kontext auffindbar machen |
agent_instructions/ | Selbsterklärende dauerhafte Regeln/Kontext; kein Funktionsverhalten | Fachverantwortliche steuern Standards; Agenten lesen und ändern nur mit Befugnis | Trennung ohne Pflichtdateinamen |
| Produktwissen | Absicht, Abläufe, Berechtigungen, Ausnahmen, Ergebnisse; nicht bloße Codebeobachtung | Menschen entscheiden wesentliche Absicht; Agenten pflegen während Implementierung | Kontinuität und unabhängige Prüfung bei flexibler Gruppierung |
| Implementierung/Tests | Produkt und gewöhnliche Prüfungen; keine Befugnis, Richtlinien zu erfinden | PE steuert freigegebene Implementierung; anderer Kontext prüft unabhängig | Projektgewählte Architektur und Werkzeuge |
| Unternehmensbausteine | Gemeinsame Plattformen, Bibliotheken, UI/Design, Identität, Integration; keine unnötigen Kopien | Autorisierte Unternehmenseigentümer steuern Änderungen und Zugriff | Wiederverwendung und technische Grenzen auch außerhalb des Repositorys |
Text schafft keine Befugnis
Ein Agent erhält keine Rechte, indem er sie niederschreibt. Geschützte Framework- oder Unternehmensdirektiven brauchen Entscheidungen autorisierter Eigentümer; Projektkontext darf nur im gewährten Umfang wachsen. Produktabsichtspflege unterscheidet sich vom Ändern der begrenzenden Engineering-Regeln. Bei unbekannter Rangfolge oder Zuständigkeit beim Repository-Eigentümer nachfragen, statt universelle Hierarchien zu erfinden. Markdown leitet; Berechtigungen, Prüfungen und Ausführungskontrollen setzen Grenzen durch. Siehe Anweisungs-Governance und Ausführungsgrenzen.