Wiederverwendbare Ausgangspunkte ohne zusätzliche Bürokratie
Diese Vorlagen veranschaulichen eine konsistente Möglichkeit, wichtige Entscheidungen und Ergebnisse im SHAPE Framework zu dokumentieren. Sie sind bewusst kurz. Teams sollten sie an Produktkomplexität und Unternehmensrichtlinien anpassen, statt jede Überschrift mit wiederholtem Text zu füllen.
Das Framework schreibt keine feste Sammlung benannter Markdown-Dokumente in agent_instructions/ vor. Die folgenden Beispiele zeigen mögliche Artefakte und ihre Aufgaben. Funktionsspezifikationen bleiben von dauerhaften Anweisungen getrennt.
Vorlage A. Zentrale `AGENTS.md`
Ein zentraler Einstieg sollte eine Aufgabe erfüllen: den Coding-Agenten zu den dauerhaften Projektanweisungen führen. Eine gepflegte Liste einzelner Dateinamen sollte nicht nötig sein.
# AGENTS.md
Lies und beachte alle Markdown-Dateien (`.md`) in `agent_instructions/` vor Arbeitsbeginn und während der gesamten Implementierung.
Die zentrale Datei kann so einfach bleiben, auch wenn Projekte weitere dauerhafte Anweisungen ergänzen.
Vorlage B. Selbsterklärendes Anweisungsdokument
Jede Markdown-Datei in agent_instructions/ sollte zunächst ihren Gegenstand benennen. Dieses Beispiel ist bewusst allgemein; sein Dateiname ist nicht vorgeschrieben.
# [Zweck: erläutern, was dieses Anweisungsdokument regelt]
## Geltungsbereich
- [Für welches Projekt oder welche Tätigkeit diese Anweisungen gelten]
## Regeln
- [Verpflichtende, umsetzbare Regel]
- [Falls erforderlich eine weitere Regel]
## Freigabe oder Eskalation
- [Welche Entscheidungen die Zustimmung eines Verantwortlichen benötigen]
## Zugehöriger Kontext
- [Optionale Verweise auf anderes maßgebliches Material]
Diese Vorlage kann Projektziele, Architekturbeschränkungen, Gestaltungsvorgaben, freigegebene Abhängigkeiten oder ein anderes Thema abdecken. Verbinden Sie unzusammenhängende Belange nicht nur deshalb, weil sie alle in Markdown verfasst sind. Beachten Sie die Dokumentfreigaberegeln der Organisation.
Vorlage C. Projektziele
Ein Projektzieldokument erklärt, warum das Produkt existiert und was es erreichen soll. Ablageort und Name können vom Projekt als Teil seines dauerhaften Kontexts gewählt werden.
# Produktziele und Umfang für [Produktname]
## Problem
[Welches Problem besteht heute und für wen?]
## Beabsichtigte Ergebnisse
- [Beobachtbares Ergebnis]
- [Gegebenenfalls weiteres Ergebnis]
## Benutzer und Stakeholder
- [Akteur oder Stakeholder und dessen Interesse]
## Anfänglicher Umfang
- [Enthaltene Fähigkeit]
## Ausschlüsse
- [Ausdrücklich ausgeschlossene Fähigkeit]
## Beschränkungen und Abhängigkeiten
- [Bestehende Richtlinien, Systeme, Grenzen oder Freigaben]
## Offene fachliche Entscheidungen
- [Frage, Entscheidungsverantwortlicher und aktueller Stand]
Vorlage D. Funktionsspezifikation
Speichern Sie Funktionsspezifikationen im Bereich specs/ des Projekts. Verwenden Sie eine stabile Kennung und halten Sie das Dokument bei der Weiterentwicklung des Verhaltens aktuell.
# SPEC-[ID]: [Funktionsname]
## Zweck
[Benutzer- oder Geschäftsergebnis und Grund für die Funktion]
## Umfang
[Enthaltenes Verhalten und wichtige Ausschlüsse]
## Akteure und Berechtigungen
[Wer sehen, auslösen, ändern oder entscheiden darf]
## Voraussetzungen
[Erforderlicher Zustand, Daten oder Richtlinienannahmen]
## Erwartetes Verhalten
1. [Beobachtbares Verhalten]
2. [Beobachtbares Verhalten]
## Geschäftsregeln
- [Regel und ihre Folgen]
## Ausnahmen und Fehler
- [Verhalten bei ungültiger Eingabe, verweigertem Zugriff oder ausgefallener Abhängigkeit]
## Akzeptanzbedingungen
- AC-01: [Beobachtbare, verifizierbare Bedingung]
- AC-02: [Beobachtbare, verifizierbare Bedingung]
## Abhängigkeiten und Verweise
- [Andere Spezifikationen oder freigegebene Standards]
## Offene Entscheidungen
- [Gegebenenfalls offener Punkt und Entscheidungsverantwortlicher]
Eine Spezifikation muss weder Quellcodestruktur noch ein bestimmtes UI-Layout vorgeben, sofern diese Beschränkung nicht selbst eine freigegebene Produktanforderung ist.
Vorlage E. Architektenprüfprotokoll
# Technische Prüfung: [Produkt / Änderung]
## Prüfphase
[Erste Prüfung Zyklus 1 / Abschlussprüfung Zyklus 1 / Erforderliche Prüfung Zyklus 2]
## Umfang
[Was geprüft wurde und relevante Spezifikationen oder Änderungen]
## Befunde
| Kennung | Bedeutung | Befund und Folge | Erforderliche Maßnahme | Verantwortung | Status |
|---------|-----------|------------------|------------------------|---------------|--------|
| R-01 | [Stufe] | [Problem] | [Korrektur oder Entscheidung] | [Verantwortlicher] | [Offen/Behoben] |
## Offene Risiken oder Ausnahmen
[Wesentliche Punkte und ihre freigegebene Behandlung]
## Technische Schlussfolgerung
[Bereit / Nicht bereit / Gemäß Richtlinie bedingt bereit, mit Prüfer]
Das Protokoll ist der Änderung angemessen. Es dokumentiert wichtige Engineering-Urteile, ohne eine Architektenprüfung mit fachlicher Abnahme gleichzusetzen.
Vorlage F. Ergebnis spezifikationsbasierter Tests
# Unabhängige Spezifikationsverifikation: [Produkt / Änderung]
## Umfang
[Einbezogene Spezifikationen und Verhaltensweisen]
## Unabhängigkeit der Verifikation
[Wie der Verifikationskontext von der Implementierung getrennt wurde]
## Umgebung und Grenzen
[Autorisierter Testkontext, repräsentative Daten, blockierte Fähigkeiten]
## Ergebnisse
| Anforderung | Ausgeführte Prüfung | Erwartung | Beobachtung | Status | Nachweis/Verweis |
|-------------|---------------------|-----------|-------------|--------|-----------------|
| SPEC-X / AC-01 | [Prüfung] | [Erwartung] | [Beobachtung] | Bestanden / Fehlgeschlagen / Blockiert / Klärungsbedarf | [Verweis] |
## Offene Befunde
[Fehler, Blockaden, Unklarheiten und ihre Verantwortlichen]
## Ergebnis erneuter Tests
[Was geändert und was erneut getestet wurde]
## Zusammenfassung
[Verifizierter Umfang und verbleibende Unsicherheit ohne übertriebene Abdeckungsbehauptung]
Dies ist ein beispielhafter Berichtsaufbau. Bestehende Testmanagementverfahren des Unternehmens können gleichwertige Nachweise bereitstellen.
Vorlage G. Schlanke Retrospektive
# Entwicklungsretrospektive: [Produkt / Zyklus]
## Was funktioniert hat
- [Konkrete wirksame Praxis]
## Was wiederholt Reibung verursacht hat
- [Konkretes Problem und Auswirkung]
## Vereinbarte Verbesserungen
| Änderung | Lokal oder gemeinsam | Verantwortliche Person | Freigabe nötig? |
|----------|----------------------|------------------------|-----------------|
| [Maßnahme] | [Umfang] | [Verantwortlicher] | [Ja/Nein] |
## Entscheidungen gegen Maßnahmen
[Optionale Erklärung zu bewusst unverändert belassenen Punkten]
Eine Retrospektive muss keine neuen Maßnahmen erzeugen, wenn bestehende Praktiken funktionieren. Änderungen gemeinsamer Unternehmensmaterialien folgen deren etablierter Governance.
Vorlagen verantwortungsvoll einsetzen
Ersetzen Sie Hinweise in eckigen Klammern durch projektspezifische Fakten und Entscheidungen. Entfernen Sie irrelevante Überschriften, statt Inhalte zu erfinden. Halten Sie Spezifikationen mit tatsächlichem Produktverhalten konsistent. Kopieren Sie keine beispielhaften Berechtigungsregeln oder impliziten Sicherheitsmechanismen in ein Produktionsprojekt, ohne dessen Richtlinien anzuwenden.