Intent-Driven Development

Intent-Driven Development (Zielgerichtete Entwicklung)

Produzieren Sie nützliche Abnahmekriterien, ohne Spezifikation zur Zeremonie zu machen. Prüfen Sie zuerst den verfügbaren Kontext, legen Sie echte Unklarheiten offen und wählen Sie Prüfmethoden, die zur Arbeit und ihrem Risiko passen.

Wann zu aktivieren

• Der Nutzer bittet um Klärung einer Funktion, Definition von Abnahmekriterien oder Risikominimierung vor der Implementierung
• Die Anfrage betrifft Sicherheit, Authentifizierung, persistente Daten, Migrationen, externe APIs oder Compliance
• Der Nutzer möchte ein Übergabedokument für einen anderen Agenten oder ein anderes Team vorbereiten
• Die Anfrage ist vage genug, dass das erwartete Ergebnis noch nicht beobachtbar oder testbar ist
• Der Nutzer ruft den Skill explizit mit /intent-driven-development auf

Nicht aktivieren bei trivialen Bearbeitungen, einfachen Einzeiler-Fixes, aktiven Debugging-Sitzungen, Code-Review-Anfragen oder Implementierungsanfragen, deren Abnahmebedingungen bereits klar sind.

So funktioniert es

1. Kontext zuerst prüfen – Liest Repository, Dokumentation, Schemas und Testinfrastruktur nach technischen Fakten, bevor Fragen gestellt werden. Produkt- und Geschäftsrandbedingungen werden als nur durch den Nutzer oder ein Produktartikel (z. B. PRD) bekannt behandelt.
2. Tiefe wählen – Wählt je nach Risikoprofil entweder die Schnellaufnahme (3-7 Kriterien, niedriges/mittleres Risiko) oder das vollständige Abnahme-Briefing (Sicherheit, Daten, Migration, systemübergreifende Änderungen).
3. Minimal nachfragen – Stellt nur Fragen, deren Antworten nicht ableitbar sind und die Umfang oder Verhalten wesentlich ändern.
4. Beobachtbare Kriterien schreiben – Jedes AC-NNN beschreibt Startbedingung, Auslöser, erwartetes Ergebnis, verbotene Nebenwirkung, Prüfmethode und Priorität; keine vagen Wörter wie „korrekt“ oder „sicher” ohne Nachweis.
5. Fortfahren oder Übergeben – Bei klaren Anforderungen ohne blockierende Risiken werden Kriterien erfasst und fortgefahren; bei risikoreichen Änderungen werden Blocker präsentiert und auf Bestätigung gewartet.
6. Überarbeitung handhaben – Wenn ein AC während der Implementierung aufgrund architektonischer Einschränkungen fehlschlägt, wird es als [revised] markiert, Umfang oder Prüfmethode aktualisiert, die Revisionsnummer erhöht und nur die geänderten Kriterien erneut vorgelegt.

Beispiele

Schnellaufnahme – „CSV-Export zum Dashboard hinzufügen”

Ziel: Authentifizierte Benutzer können Dashboard-Daten als CSV-Datei herunterladen.
Im Umfang: Export der aktuell gefilterten Zeilen; Dateiname enthält Datum.
Nicht im Umfang: Geplante Exporte, E-Mail-Versand, Excel-Format.
Annahmen: Maximale Zeilenanzahl unter 10k; keine personenbezogenen Daten in exportierten Feldern.

AC-001: Export erzeugt Datei mit korrekten Kopfzeilen
- Szenario: authentifizierter Benutzer, mindestens eine Datenzeile sichtbar
- Aktion: Klick auf „Export CSV”
- Erwartet: Browser lädt Datei mit Spalten [id, name, created_at] herunter
- Darf nicht: interne Felder oder Zeilen anderer Benutzer offenlegen
- Prüfung: automatisierter Integrationstest + manueller Schema-Stichprobencheck
- Priorität: Erforderlich

Vollständiges Briefing Auslöser – „Benutzerauthentifizierung auf OAuth migrieren”

Auth-Änderung + externe Abhängigkeit + vorhandene Sitzungsdaten → Vollständiges Briefing mit Risikobewertungstabelle, blockierenden Entscheidungen zur Sitzungsinvalidierungsstrategie und explizitem Rollback-AC.

Überprüfung einer bestehenden Spezifikation – Nutzer fügt ein PRD ein

Der Skill prüft es auf fehlende Umfangsgrenzen, nicht überprüfbare Anforderungen („das System soll schnell sein”) und stille Annahmen und gibt korrigierte oder ergänzende Kriterien zurück, ohne die Discovery neu zu starten.

Betriebsregeln

1. Prüfen Sie das verfügbare Repository, die Dokumentation, das Issue, das Design und den Testkontext, bevor Sie nach technischen Fakten fragen, die lokal entdeckt werden können.
2. Leiten Sie Produkt- oder Geschäftsrandbedingungen nicht aus Code ab. Geschäftsregeln, Compliance- und Regulierungsverpflichtungen, vertragliche SLAs, Preisgestaltung, Datenaufbewahrungsrichtlinien, Priorisierung und Zielbenutzer können nicht aus einem Repository gelesen werden. Behandeln Sie sie als unbekannt, bis der Nutzer sie liefert oder ein maßgebliches Produktartikel (PRD, Vertrag, Richtliniendokument) sie angibt. Erfassen Sie sie als Annahmen, die zur Bestätigung gekennzeichnet sind, niemals als entdeckte Fakten. Das Repository gibt Ihnen Auskunft darüber, wie sich das System heute verhält, nicht darüber, was das Geschäft von ihm verlangt.
3. Stellen Sie nur Fragen, deren Antworten erforderlich sind und nicht sicher abgeleitet werden können. Gruppieren Sie kurze, verwandte Fragen, wenn das unnötige Iterationen spart.
4. Blockieren Sie die Implementierung nicht standardmäßig. Wenn der Nutzer um eine ausreichend klare Änderung gebeten hat, erfassen Sie die wichtigsten Annahmen und Abnahmekriterien kurz und fahren Sie dann fort oder übergeben Sie sie an den Implementierungsworkflow.
5. Fordern Sie eine explizite Bestätigung durch den Nutzer nur dann an, wenn eine ungelöste Entscheidung zu einer erheblichen Sicherheitsgefährdung, Datenverlust, irreversiblen Migration, Vertrags-/API-Bruch, erheblichen Kosten oder zerstörerischen externen Aktionen führen könnte.
6. Schreiben Sie kein Abnahmedokument in ein Repository, ändern Sie keine Projektdateien, erstellen Sie keinen Branch, führen Sie keinen Commit durch und rufen Sie keine andere Fähigkeit auf, es sei denn, der Nutzer fordert dies an oder der aktive Repository-Workflow erfordert es explizit.
7. Behandeln Sie automatisierte Tests als Beweis, nicht als Wahrheit. Bevorzugen Sie Automatisierung, wenn sie zuverlässig und angemessen ist; erlauben Sie manuelle UX-, Zugänglichkeits-, Sicherheits-, Rechts- oder Betriebsprüfungen, wo Automatisierung das Ergebnis nicht feststellen kann.
8. Nehmen Sie niemals echte Geheimnisse, Anmeldedaten, Token, private Schlüssel, personenbezogene Daten oder sensible Produktionslasten in Abnahmekriterien, Testdaten, Beispiele oder gespeicherte Artefakte auf. Verwenden Sie geschwärzte oder synthetische Werte.
9. Führen Sie keine destruktiven Tests, Migrationen, Sicherheitsproben, Auslastungstests, kostspieligen externen Aufrufe oder Operationen gegen Produktions-/Live-Daten ohne explizite Autorisierung und eine identifizierte sichere Umgebung durch.
10. Wenn ein Abnahmekriterium aufgrund einer architektonischen, plattformbedingten oder externen Einschränkung, die während der Implementierung entdeckt wurde, nicht erfüllt werden kann, lassen Sie es nicht stillschweigend fallen oder umgehen Sie es. Aktualisieren Sie das betroffene Kriterium (markieren Sie es als [revised], nennen Sie die Einschränkung und passen Sie den Umfang oder die Prüfmethode an), erhöhen Sie die Revisionsnummer und legen Sie nur die geänderten Kriterien dem Nutzer erneut vor, bevor Sie fortfahren. Fordern Sie eine explizite Bestätigung nur an, wenn die Überarbeitung eine blockierende Entscheidung ändert oder die Sicherheits- oder Korrektheitsgarantien wesentlich reduziert.

Wählen Sie die Tiefe

Verwenden Sie die kleinste nützliche Ausgabe.

Schnellaufnahme

Verwenden Sie für eine klare, aber nicht triviale Änderung mit geringem oder mittlerem Risiko. Produzieren Sie:

• Ziel
• Im Umfang / Nicht im Umfang
• Annahmen
• 3-7 Abnahmekriterien mit Prüfmethoden
• Blockierende Fragen, falls vorhanden

Verzögern Sie die Implementierung nicht zur Genehmigung, es sei denn, es liegt ein blockierendes Risiko aus den Betriebsregeln vor oder der Nutzer hat ausdrücklich zuerst eine Spezifikation verlangt.

Vollständiges Abnahme-Briefing

Verwenden Sie für mehrdeutige, systemübergreifende, sicherheitskritische, datenändernde, migrations-, compliance- oder kostenintensive Änderungen oder wenn der Nutzer ein Übergabedokument anfordert. Produzieren Sie die vollständige Vorlage unten und fordern Sie eine Bestätigung für ungelöste blockierende Entscheidungen an, bevor Sie mit der risikoreichen Implementierung fortfahren.

Überprüfung einer bestehenden Spezifikation

Wenn der Nutzer bereits ein PRD, Issue, einen Plan oder Abnahmekriterien geliefert hat:

1. Überprüfen Sie es, anstatt die Discovery neu zu starten.
2. Identifizieren Sie fehlende Umfangsgrenzen, unsichere Annahmen, Widersprüche und nicht überprüfbare Anforderungen.
3. Geben Sie korrigierte oder ergänzende Kriterien zurück.

Arbeitsablauf

1. Ziel und Risiko festlegen

Ermitteln oder Fragen Sie nach:

• Dem beobachtbaren Ergebnis für den Benutzer oder das System.
• Den betroffenen Akteuren.
• Der hauptsächlichen Fehlerfolge.
• Den tatsächlich zutreffenden Risikodimensionen: Sicherheit/Datenschutz, persistente Daten, Kompatibilität/API, Migration, externe Abhängigkeiten, Kosten, Parallelität, Leistung, Benutzerfreundlichkeit/Barrierefreiheit.

Vermeiden Sie es, generische Fragen zu irrelevanten Risiken zu stellen.

2. Kontext entdecken

Wenn lokale oder verbundene Artefakte verfügbar sind, prüfen Sie nur das Nötigste:

• Vorhandenes Verhalten und direkt zugehörige Dateien oder Schnittstellen.
• Repository-Konventionen, Produktdokumentation, API-Verträge, Datenschemata oder Migrationshistorie.
• Vorhandene Prüfinfrastruktur und realistische Befehle.
• Externe Abhängigkeiten und ob sie isoliert testbar sind.

Erfassen Sie entdeckte Fakten getrennt von benutzergelieferten Annahmen. Wenn der Kontext nicht geprüft werden kann, sagen Sie, was unbekannt ist, und stellen Sie gezielte Fragen.

Das Repository enthüllt technische Fakten – wie sich das System heute verhält, seine Konventionen und seine Verträge. Es enthüllt keine Produkt- oder Geschäftsrandbedingungen: Geschäftsregeln, Compliance- und Regulierungsverpflichtungen, vertragliche SLAs, Preisgestaltung, Datenaufbewahrungsrichtlinien, Priorisierung und Zielbenutzer. Rekonstruieren Sie diese niemals aus Code oder Benennungen. Erfassen Sie sie nur vom Benutzer oder aus einem maßgeblichen Produktartikel und listen Sie sie als Annahmen auf, die bis dahin zu bestätigen sind.

3. Umfang definieren

Geben Sie an:

• Ziel: Ein Satz, der das beabsichtigte Ergebnis beschreibt.
• Im Umfang: Verhalten, das diese Änderung liefern muss.
• Nicht im Umfang: Verlockende angrenzende Arbeiten, die explizit ausgeschlossen sind.
• Annahmen: Behauptungen, die noch nicht belegt sind.
• Blockierende Entscheidungen: Ungelöste Entscheidungen, die die Sicherheit oder das Verhalten wesentlich beeinflussen.

4. Abnahmekriterien schreiben

Verwenden Sie AC-001, AC-002 usw. Jedes Kriterium muss beobachtbares Verhalten und eine geeignete Prüfmethode beschreiben; Kriterien und Tests müssen nicht eins zu eins abgebildet werden.

Für jedes zutreffende Kriterium enthalten Sie:

• Szenario oder Startbedingung.
• Aktion oder Auslöser.
• Erwartetes beobachtbares Verhalten.
• Verbotene Nebenwirkung, wenn sinnvoll.
• Prüfmethode: automatisierter Test, Integrationsüberprüfung, manuelle UX-Überprüfung, Zugänglichkeitscheck, Sicherheitsüberprüfung, Betriebliche Überprüfung oder Stakeholder-Abnahme.
• Umgebungs-/Sicherheitsbeschränkung, wenn die Prüfung Daten, Dienste, Kosten oder Geheimnisse beeinträchtigen könnte.
• Priorität: Erforderlich, Wichtig oder Optional.

Verwenden Sie keine Wörter wie „korrekt”, „sicher”, „schnell”, „intuitiv” oder „robust”, ohne beobachtbare Beweise zu definieren oder sie als menschliches Prüfungsurteil zu erfassen.

5. Nur relevante Grenzen abdecken

Betrachten Sie diese Kategorien, schließen Sie aber nur die zutreffenden ein:

Kategorie	Einschließen bei	Typischer Nachweis
Glücksfall	Neues oder geändertes benutzersichtbares Verhalten	Erfolgreicher Workflow oder Zustandsübergang
Validierung	Die Änderung nimmt Eingaben an	Abgelehnte fehlerhafte oder Grenzwert ohne Mutation
Autorisierung/Datenschutz	Daten oder Aktionen haben Zugriffsgrenzen	Verweigerter Zugriff und keine Offenlegung sensibler Daten
Persistenz/Migration	Gespeicherte Daten oder Schemata ändern sich	Rückwärtslesen, Migration, Rollback oder Sicherungsverhalten
Kompatibilität	Öffentliche APIs, Dateien, Ereignisse oder Clients können brechen	Vorhandener Vertrag oder Datenbestand bleibt gültig
Fehlerbehebung	Netzwerk-, Dienst- oder asynchrone Fehler treten auf	Kein partieller Zustand oder klare Wiederholung/heruntergesetztes Verhalten
Idempotenz/Nebenläufigkeit	Wiederholungen oder gleichzeitige Schreibvorgänge sind plausibel	Keine doppelte Nebenwirkung oder ungültiger Endzustand
Leistung	Ein Benutzer- oder Dienstschwellenwert ist relevant	Definierte Messbedingungen und Schwellenwert
UX/Barrierefreiheit	Eine Person interagiert mit dem Ergebnis	Tastatur, Feedback, Fehlerbehebung, visuelle/manuelle Überprüfung

6. Präsentieren und fortfahren

• Bei einer Klärungs-/Spezifikationsanfrage präsentieren Sie das Briefing und bitten Sie nur um Entscheidungen zu den aufgeführten Blockern.
• Bei einer Implementierungsanfrage ohne Blocker präsentieren Sie eine kompakte Zusammenfassung der Kriterien als Teil der Arbeit und fahren mit der Implementierung fort.
• Bei der Übergabe an einen anderen Agenten oder ein anderes Team fügen Sie genügend Kontext und Prüfdetails hinzu, damit diese handeln können, ohne Anforderungen zu erfinden.
• Speichern Sie das Briefing nur auf Anfrage in einer Datei. Verwenden Sie einen vom Repository genehmigten Pfad, falls vorhanden; andernfalls fragen Sie nach dem gewünschten Ziel oder nennen Sie es, bevor Sie schreiben.

Ausgabevorlage

Verwenden Sie diese Vorlage für ein vollständiges Abnahme-Briefing. Lassen Sie irrelevante Abschnitte für die Schnellaufnahme weg.

# Abnahme-Briefing: <Änderungsname>

**Status:** Entwurf | Genehmigt | Implementiert | Geprüft
**Revision:** <Nummer>
**Vorbereitet für:** <Benutzer/Team/Agent, falls bekannt>
**Genehmigung vor risikoreicher Arbeit erforderlich:** Ja | Nein - <Grund>

## Revisionsprotokoll

| Rev | Datum | Geänderte Kriterien | Grund |
| --- | --- | --- | --- |
| 1 | <Datum> | — | Erster Entwurf |

## Ziel

<Ein Satz für das beobachtbare Ergebnis.>

## Umfang

**Im Umfang**
- <eingeschlossenes Verhalten>

**Nicht im Umfang**
- <ausgeschlossene angrenzende Arbeit>

## Kontext

**Entdeckte Fakten** (technisch, aus Repository oder Artefakt überprüft)
- <wie sich das System heute verhält, Konventionen, Verträge>

**Produkt-/Geschäftsrandbedingungen** (vom Benutzer oder Produktartikel geliefert, niemals aus Code abgeleitet)
- <Geschäftsregel, Compliance-/SLA-Verpflichtung, Aufbewahrungsrichtlinie, Priorität, Zielbenutzer – oder „noch keine geliefert”>

**Annahmen**
- <unbestätigte Behauptung, die zu bestätigen oder zu validieren ist>

**Abhängigkeiten und Einschränkungen**
- <externer Dienst, lokale Konvention, Kompatibilitätsverpflichtung, Umgebungsbeschränkung>

## Risikobewertung

| Risikobereich | Trifft zu? | Erforderliche Handhabung |
| --- | --- | --- |
| Sicherheit/Datenschutz | Ja/Nein | <Schwärzung, Autorisierung, Überprüfung usw.> |
| Persistente Daten/Migration | Ja/Nein | <Kompatibilität, Backups, Rollback usw.> |
| Externe Effekte/Kosten | Ja/Nein | <Sandbox-/Testumgebung/Autorisierung> |
| Kompatibilität/API | Ja/Nein | <zu erhaltender oder zu versionierender Vertrag> |
| UX/Barrierefreiheit | Ja/Nein | <manueller oder automatisierter Nachweis> |

## Abnahmekriterien

### AC-001: <beobachtbares Verhalten>
- **Szenario:** <Startbedingung>
- **Aktion:** <einzelner Auslöser>
- **Erwartet:** <beobachtbares Ergebnis>
- **Darf nicht:** <verbotene Nebenwirkung, falls zutreffend>
- **Prüfung:** <Methode und beabsichtigter Nachweis>
- **Umgebung/Sicherheit:** <Einschränkungen, falls zutreffend>
- **Priorität:** Erforderlich | Wichtig | Optional

## Blockierende Entscheidungen

- [ ] <nur Entscheidungen, die sicheren oder korrekten Fortschritt verhindern>

## Prüfplan

| Kriterium | Prüfnachweis | Status |
| --- | --- | --- |
| AC-001 | <Test-/Überprüfungsbefehl oder Nachweistyp> | Ausstehend |

Beispiele für Bestehen/Nichtbestehen

Verwenden Sie diese, um zu beurteilen, ob der Skill tatsächlich ein überprüfbares Briefing produziert hat, nicht Planungsprosa.

Ein nicht bestandenes Abnahmekriterium

AC-001: Der Export funktioniert korrekt und ist sicher.

Nicht bestanden – „funktioniert korrekt” und „sicher” sind nicht beobachtbar, es gibt kein Szenario, keinen Auslöser, kein erwartetes Ergebnis, keine verbotene Nebenwirkung, keine Prüfmethode und keine Priorität.