Intent-Driven Development

Intent-Driven Development (Zielgerichtete Entwicklung)

Produzieren Sie nützliche Akzeptanzkriterien, ohne die Spezifikation zur Zeremonie werden zu lassen. Überprüfen Sie zuerst den verfügbaren Kontext, decken Sie echte Mehrdeutigkeiten auf und wählen Sie Verifikationsmethoden, die zur Arbeit und ihrem Risiko passen.

Wann zu aktivieren

• Der Benutzer bittet darum, ein Feature zu klären, Akzeptanzkriterien zu definieren oder eine Änderung vor der Implementierung zu entschärfen
• Die Anfrage betrifft Sicherheit, Authentifizierung, persistente Daten, Migrationen, externe APIs oder Compliance
• Der Benutzer möchte ein Übergabe-Artefakt für einen anderen Agenten oder ein Team vorbereiten
• Die Anfrage ist so mehrdeutig, dass das erwartete Ergebnis noch nicht beobachtbar oder testbar ist
• Der Benutzer aktiviert dieses Skill explizit mit /intent-driven-development

Nicht aktivieren für triviale Änderungen, einfache Einzeiler-Fixes, aktive Debugging-Sitzungen, Code-Review-Anfragen oder Implementierungsanfragen, deren Akzeptanzbedingungen bereits klar sind.

Wie es funktioniert

1. Zuerst den Kontext prüfen – liest das Repository, die Dokumentation, Schemata und die Testinfrastruktur nach technischen Fakten, bevor eine Frage gestellt wird, behandelt Produkt-/Geschäftseinschränkungen jedoch als etwas, das nur der Benutzer oder ein Produkt-Artefakt liefern kann
2. Tiefe wählen – wählt basierend auf dem Risikoprofil zwischen Quick Capture (3-7 Kriterien, niedriges/mittleres Risiko) oder Full Acceptance Brief (Sicherheit, Daten, Migration, systemübergreifende Änderungen) aus
3. Minimal nachfragen – stellt nur Fragen, deren Antworten nicht abgeleitet werden können und die den Umfang oder das Verhalten wesentlich ändern
4. Beobachtbare Kriterien schreiben – jedes AC-NNN beschreibt eine Startbedingung, einen Auslöser, ein erwartetes Ergebnis, eine verbotene Nebenwirkung, eine Verifikationsmethode und eine Priorität; keine vagen Wörter wie "korrekt" oder "sicher" ohne Nachweis
5. Fortfahren oder übergeben – für klare Anfragen ohne blockierende Risiken werden die Kriterien aufgezeichnet und fortgefahren; für riskante Änderungen werden Blocker präsentiert und auf Bestätigung gewartet
6. Revisionen handhaben – falls ein AC während der Implementierung aufgrund architektonischer Einschränkungen fehlschlägt, wird es als [revised] markiert, der Umfang oder die Verifikationsmethode aktualisiert, die Revisionsnummer erhöht und nur die geänderten Kriterien erneut präsentiert

Beispiele

Quick Capture – "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-Zustellung, Excel-Format.
Annahmen: Maximale Zeilenanzahl unter 10k; keine personenbezogenen Daten in exportierten Feldern.

AC-001: Export generiert Datei mit korrekten Überschriften
- Szenario: authentifizierter Benutzer, mindestens eine Datenzeile sichtbar
- Aktion: Klick auf "CSV exportieren"
- Erwartet: Browser lädt Datei mit Spalten [id, name, created_at] herunter
- Darf nicht: interne Felder oder Zeilen anderer Benutzer offenlegen
- Verifikation: automatisierter Integrationstest + manueller Schema-Stichprobencheck
- Priorität: Erforderlich

Full Acceptance Brief Auslöser – "Benutzer-Authentifizierung auf OAuth migrieren"

Auth-Änderung + externe Abhängigkeit + vorhandene Sitzungsdaten → Full Brief mit Risk Review Tabelle, blockierenden Entscheidungen zur Sitzungsinvalidierungsstrategie und explizitem Rollback-AC.

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

Das Skill überprüft es auf fehlende Umfangsgrenzen, nicht verifizierbare Anforderungen ("das System muss schnell sein") und stille Annahmen und gibt dann korrigierte oder ergänzende Kriterien zurück, ohne die Discovery neu zu starten.

Betriebsregeln

1. Überprüfen Sie den verfügbaren Repository-, Dokumentations-, Issue-, Design- und Testkontext, bevor Sie nach technischen Fakten fragen, die lokal entdeckt werden können.
2. Leiten Sie keine Produkt- oder Geschäftsbeschränkungen aus Code ab. Geschäftsregeln, Compliance- und regulatorische Verpflichtungen, vertragliche SLAs, Preisgestaltung, Datenaufbewahrungsrichtlinien, Priorisierung und Zielbenutzer können nicht aus einem Repository gelesen werden. Behandeln Sie sie als unbekannt, bis der Benutzer sie liefert oder ein maßgebliches Produkt-Artefakt (PRD, Vertrag, Richtliniendokument) sie angibt. Notieren Sie sie als Annahmen, die zur Bestätigung markiert sind, niemals als entdeckte Fakten. Das Repository sagt Ihnen, wie sich das System heute verhält, nicht, 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, zusammenhängende Fragen, wenn das unnötige Interaktionen spart.
4. Blockieren Sie die Implementierung nicht standardmäßig. Wenn der Benutzer um eine ausreichend klare Änderung gebeten hat, notieren Sie die wichtigsten Annahmen und Akzeptanzkriterien kurz und fahren Sie dann fort oder übergeben Sie sie an den Implementierungs-Workflow.
5. Fordern Sie nur dann eine explizite Benutzerbestätigung an, bevor Sie fortfahren, wenn eine ungelöste Entscheidung zu einem erheblichen Sicherheitsrisiko, Datenverlust, irreversibler Migration, vertraglichem/API-Bruch, erheblichen Kosten oder einer destruktiven externen Aktion führen könnte.
6. Schreiben Sie kein Akzeptanzdokument in ein Repository, ändern Sie keine Projektdateien, erstellen Sie keinen Branch, führen Sie keinen Commit durch oder rufen Sie kein anderes Skill auf, es sei denn, der Benutzer fordert es an oder der aktive Repository-Workflow verlangt es ausdrücklich.
7. Behandeln Sie automatisierte Tests als Beweis, nicht als Wahrheit. Bevorzugen Sie Automatisierung, wenn sie zuverlässig und verhältnismäßig ist; erlauben Sie manuelle UX-, Zugänglichkeits-, Sicherheits-, rechtliche oder betriebliche Verifikation, wo Automatisierung das Ergebnis nicht feststellen kann.
8. Fügen Sie niemals echte Geheimnisse, Anmeldeinformationen, Token, private Schlüssel, personenbezogene Daten oder sensible Produktions-Payloads in Akzeptanzkriterien, Testdaten, Beispiele oder gespeicherte Artefakte ein. Verwenden Sie geschwärzte oder synthetische Werte.
9. Führen Sie keine destruktiven Tests, Migrationen, Sicherheitsscans, Lasttests, kostenpflichtigen externen Aufrufe oder Operationen gegen Produktions-/Live-Daten ohne ausdrückliche Genehmigung und eine identifizierte sichere Umgebung durch.
10. Wenn ein Akzeptanzkriterium aufgrund einer während der Implementierung entdeckten architektonischen, plattform- oder externen Einschränkung 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 Verifikationsmethode an), erhöhen Sie die Revisionsnummer und präsentieren Sie dem Benutzer nur die geänderten Kriterien erneut, bevor Sie fortfahren. Fordern Sie nur dann eine explizite Bestätigung an, wenn die Revision eine blockierende Entscheidung ändert oder die Sicherheits- oder Korrektheitsgarantien wesentlich reduziert.

Wählen Sie die Tiefe

Verwenden Sie die kleinste nützliche Ausgabe.

Quick Capture

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 Akzeptanzkriterien mit Verifikationsmethoden
• Blockierende Fragen, falls vorhanden

Verzögern Sie die Implementierung nicht für eine Genehmigung, es sei denn, es besteht ein blockierendes Risiko aus den Betriebsregeln oder der Benutzer hat ausdrücklich zuerst eine Spezifikation angefordert.

Full Acceptance Brief

Verwenden Sie für mehrdeutige, systemübergreifende, sicherheitssensible, datenändernde, migrations-, compliance- oder kostenintensive Änderungen oder wenn der Benutzer ein Übergabe-Artefakt 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 Benutzer bereits ein PRD, ein Issue, einen Plan oder Akzeptanzkriterien geliefert hat:

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

Workflow

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 relevanten Risikodimensionen: Sicherheit/Datenschutz, persistente Daten, Kompatibilität/API, Migration, externe Abhängigkeiten, Kosten, Parallelität, Leistung, Benutzerfreundlichkeit/Zugänglichkeit.

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

2. Kontext entdecken

Wenn lokale oder verbundene Artefakte verfügbar sind, überprüfen Sie nur, was benötigt wird:

• Vorhandenes Verhalten und direkt verwandte Dateien oder Schnittstellen.
• Repository-Konventionen, Produktdokumentation, API-Verträge, Datenschemata oder Migrationshistorie.
• Vorhandene Verifikationsinfrastruktur und realistische Befehle.
• Externe Abhängigkeiten und ob sie isoliert testbar sind.

Notieren Sie entdeckte Fakten getrennt von benutzergelieferten Annahmen. Wenn der Kontext nicht überprü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äftsbeschränkungen: Geschäftsregeln, Compliance- und regulatorische Verpflichtungen, vertragliche SLAs, Preisgestaltung, Datenaufbewahrungsrichtlinien, Priorisierung und Zielbenutzer. Rekonstruieren Sie diese niemals aus Code oder Benennungen. Erfassen Sie sie nur vom Benutzer oder einem maßgeblichen Produkt-Artefakt und listen Sie sie bis dahin als zu bestätigende Annahmen auf.

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 verwandte Arbeiten, die explizit ausgeschlossen sind.
• Annahmen: Behauptungen, die noch nicht bewiesen sind.
• Blockierende Entscheidungen: ungelöste Entscheidungen, die die Sicherheit oder das Verhalten wesentlich beeinflussen.

4. Akzeptanzkriterien schreiben

Verwenden Sie AC-001, AC-002 usw. Jedes Kriterium muss beobachtbares Verhalten und eine geeignete Verifikationsmethode beschreiben; Kriterien und Tests sind nicht erforderlich, um eins-zu-eins abgebildet zu werden.

Fügen Sie für jedes anwendbare Kriterium Folgendes ein:

• Szenario oder Startbedingung.
• Aktion oder Auslöser.
• Erwartetes beobachtbares Verhalten.
• Verbotene Nebenwirkung, wenn sinnvoll.
• Verifikationsmethode: automatisierter Test, Integrationscheck, manuelle UX-Überprüfung, Zugänglichkeitscheck, Sicherheitsüberprüfung, betrieblicher Check oder Stakeholder-Abnahme.
• Umgebungs-/Sicherheitseinschränkung, wenn die Verifikation 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 Überprüfungsurteil zu notieren.

5. Nur relevante Grenzen abdecken

Berücksichtigen Sie diese Kategorien, aber fügen Sie nur die Kategorien ein, die zutreffen:

Kategorie	Einfügen, wenn	Typischer Nachweis
Happy Path	Neues oder geändertes benutzersichtbares Verhalten	Erfolgreicher Workflow oder Zustandsübergang
Validierung	Die Änderung akzeptiert Eingaben	Abgelehnte fehlerhafte oder Grenzwert-Eingabe ohne Mutation
Autorisierung/Datenschutz	Daten oder Aktionen haben Zugriffsgrenzen	Zugriff verweigert und keine sensiblen Offenlegungen
Persistenz/Migration	Gespeicherte Daten oder Schemata ändern sich	Rückwärtslesen, Migration, Rollback- oder Backup-Verhalten
Kompatibilität	Öffentliche APIs, Dateien, Ereignisse oder Clients können brechen	Vorhandener Vertrag oder Fixture bleibt gültig
Fehlerbehebung	Netzwerk-, Dienst- oder asynchroner Fehler vorhanden	Kein Teilzustand oder klare Wiederholungs-/Degradierungsverhalten
Idempotenz/Nebenläufigkeit	Wiederholungen oder gleichzeitige Schreibvorgänge sind plausibel	Kein doppelter Nebeneffekt oder ungültiger Endzustand
Leistung	Ein Benutzer- oder Dienstschwellenwert ist wichtig	Definierte Messbedingungen und Schwellenwert
UX/Zugänglichkeit	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 die Beschreibung und fragen Sie nur nach 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 Sie mit der Implementierung fort.
• Bei der Übergabe an einen anderen Agenten oder ein Team: Fügen Sie genügend Kontext und Verifikationsdetails hinzu, damit diese ohne das Erfinden von Anforderungen handeln können.
• Speichern Sie die Beschreibung nur in einer Datei, wenn dies angefordert wird. Verwenden Sie einen vom Repository genehmigten Pfad, falls vorhanden; fragen Sie andernfalls nach dem gewählten Ziel oder geben Sie es an, bevor Sie schreiben.

Ausgabe-Vorlage

Verwenden Sie diese Vorlage für einen Full Acceptance Brief. Lassen Sie für Quick Capture irrelevante Abschnitte weg.

# Akzeptanzbeschreibung: <Änderungsname>

**Status:** Entwurf | Genehmigt | Implementiert | Verifiziert
**Revision:** <Nummer>
**Erstellt 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

<Einen Satz mit beobachtbarem Ergebnis.>

## Umfang

**Im Umfang**
- <eingeschlossenes Verhalten>

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

## Kontext

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

**Produkt-/Geschäftsbeschränkungen** (vom Benutzer oder Produkt-Artefakt geliefert, niemals aus Code abgeleitet)
- <Geschäftsregel, Compliance-/SLA-Verpflichtung, Aufbewahrungsrichtlinie, Priorität, Zielbenutzer – oder "noch keine geliefert">

**Annahmen**
- <unbestätigte Behauptung zur Bestätigung oder Validierung>

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

## Risikoüberprüfung

| Risikobereich | Anwendbar? | Erforderliche Handhabung |
| --- | --- | --- |
| Sicherheit/Datenschutz | Ja/Nein | <Schwärzung, Autorisierung, Überprüfung usw.> |
| Persistente Daten/Migration | Ja/Nein | <Kompatibilität, Backup, Rollback usw.> |
| Externe Effekte/Kosten | Ja/Nein | <Sandbox-/Testumgebung/Autorisierung> |
| Kompatibilität/API | Ja/Nein | <Vertrag zu erhalten oder zu versionieren> |
| UX/Zugänglichkeit | Ja/Nein | <manueller oder automatisierter Nachweis> |

## Akzeptanzkriterien

### AC-001: <beobachtbares Verhalten>
- **Szenario:** <Startbedingung>
- **Aktion:** <einzelner Auslöser>
- **Erwartet:** <beobachtbares Ergebnis>
- **Darf nicht:** <verbotene Nebenwirkung, falls zutreffend>
- **Verifikation:** <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>

## Verifikationsplan

| Kriterium | Verifikationsnachweis | Status |
| --- | --- | --- |
| AC-001 | <Befehl zum Testen/Überprüfen/Review oder Nachweistyp> | Ausstehend |

Beispiele für Bestehen/Nichtbestehen

Verwenden Sie diese, um zu beurteilen, ob das Skill tatsächlich eine verifizierbare Beschreibung produziert hat, nicht Planungsprosa.

Ein nicht bestandener Akzeptanzkriterium

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 Verifikationsmethode und keine Priorität.

Ein bestandener Akzeptanzkriterium

AC-001: Authentifizierter Benutzer lädt Dashboard-Daten als CSV mit validierten Überschriften herunter
- Szenario: Der Benutzer ist angemeldet und der Dashboard-Tab zeigt mindestens eine Tabellenzeile an
- Aktion: Der Benutzer klickt auf die Schaltfläche "CSV exportieren"
- Erwartet: Der Browser lädt eine Datei mit dem Namen dashboard_export_2025-01-24.csv herunter; die Datei enthält eine Kopfzeile mit den Spalten [id, name, created_at]
- Darf nicht: Die Datei enthält keine internen Felder (z.B. Benutzer-ID, Sitzungs-Token) oder Zeilen, die zu anderen Benutzern gehören
- Verifikation: Automatisierter Integrationstest (tests/integration/test_csv_export.py) überprüft Dateiname und Spaltenüberschriften; manuelle Prüfung eines exportierten Datensatzes auf das Vorhandensein unerwarteter Felder
- Sicherheit/Einschränkungen: Der Test verwendet synthetische Daten ohne personenbezogene Informationen
- Priorität: Erforderlich

Bestehen – Szenario, Aktion, erwartetes Ergebnis, verbotene Nebenwirkung, Verifikationsmethode, Sicherheitseinschränkung und Priorität sind alle vorhanden und beobachtbar.

Abschlussboxen

• Klärung und Spezifikation
• Risikoüberprüfung und Minimierung
• Implementierung
• Verifikation und Tests
• Übergabe an einen anderen Agenten oder ein Team
• Dokumentation