Prompt file imported from mick-gsk/drift (.github/prompts/drift-agent-ux.prompt.md). Copyright stays with the author.

Drift Agent UX

Name: Drift Agent UX
Author: mick-gsk

Du evaluierst die Drift-CLI aus der Perspektive eines Agent-Users. Dein Fokus liegt auf Auffindbarkeit, Latenz, Fehlernachrichten und konsistentem Verhalten über Kommandos hinweg.

Pflicht: Vor Ausführung dieses Prompts das Drift Policy Gate durchlaufen (siehe .github/prompts/_partials/konventionen.md und .github/instructions/drift-policy.instructions.md).

Relevante Referenzen

Instruction: .github/instructions/drift-policy.instructions.md
Bewertungssystem: .github/prompts/_partials/bewertungs-taxonomie.md
Issue-Filing: .github/prompts/_partials/issue-filing.md
Verwandte Prompts: drift-agent-workflow-test.prompt.md (CI-Realism), drift-ci-gate.prompt.md (Gate-Perspektive)
CLI-Implementierung: src/drift/commands/ (Click-CLI-Subcommands)

Arbeitsmodus

Interagiere als Agent: systematisch, breadth-first, exit-code-gesteuert.
Beobachte und dokumentiere statt sofort zu bewerten.
Erkläre die Kognition hinter jedem Urteil (z.B. „ein Mensch würde X tun, ein Agent bräuchte Y").
Wenn ein Workflow abbricht, bestimme die günstigste Abbruchursache, nicht die schlimmste.
Unterscheide Agent-UX-Probleme von allgemeinen CLI-Bugs.

Ziel

Bestimme, ob ein Coding-Agent Drift installieren, erkunden, nutzen und auf Ergebnisse reagieren kann — ohne Vorwissen, ohne Dokumentationslektüre, mit reinen CLI-Signalen.

Erfolgskriterien

Die Aufgabe ist erst abgeschlossen, wenn du beantworten kannst:

Konnte der Agent alle relevanten Kommandos und Optionen entdecken (--help-Auffindbarkeit)?
Sind Fehlermeldungen informativ genug, um autonomes Recovery zu leiten?
Ist die CLI-Latenz akzeptabel für interaktive Agent-Schleifen?
Sind Output-Formate über Kommandos und Läufe hinweg konsistent?

Arbeitsregeln

Dokumentiere jedes Kommando mit Exit-Code und Antwortzeit.
Behandle Latenz > 15 Sekunden als agent-disruptiv; errechne Recovery-Möglichkeit (Timeout + Retry vs. Abbruch).
Verwende --help als primäre Auffindbarkeitsquelle — nicht Dokumentation.
Prüfe Output-Metadaten auf Konsistenz über Formate.
Bewerte Fehlermeldungen auf Actionability für autonomes Recovery.
Falls --help Optionen beschreibt, die im realen Output nicht sichtbar sind: dokumentiere die Diskrepanz.

Bewertungs-Labels

Verwende ausschließlich Labels aus .github/prompts/_partials/bewertungs-taxonomie.md:

Ergebnis-Bewertung: pass / review / fail
Risiko-Level: low / medium / high / critical
Auffindbarkeits-Skala: self-explanatory / documented / hidden / misleading
Actionability-Score: 1 automated / 2 guided / 3 human-review / 4 blocked

Artefakte

Erstelle Artefakte unter work_artifacts/agent_ux_<YYYY-MM-DD>/:

discovery_log.md
latency_matrix.md
error_catalog.md
consistency_audit.md
agent_ux_report.md

Workflow

Phase 0: Auffindbarkeit

Erkunde die CLI als Zero-Knowledge-Agent.

Dev-Version sicherstellen (siehe _partials/konventionen.md → Versions-Freshness):

pip install -e .   # Dev-Version aus Workspace
drift --help
drift --version    # Muss mit pyproject.toml übereinstimmen

Für jedes Top-Level-Kommando:

drift <command> --help

Auffindbarkeits-Bewertung pro Kommando:

Kommando	Sichtbar in `--help`?	Beschreibung verständlich ohne Kontext?	Optionen vollständig?	Auffindbarkeit
				`self-explanatory` / `documented` / `hidden` / `misleading`

Subcommand-Konventionen-Check:

Verwenden alle Kommandos konsistente Benennung? (z.B. kebab-case vs. snake_case)
Haben gemeinsame Optionen (z.B. --repo, --format) konsistente Defaults?
Gibt es Aliases oder undokumentierte Kurzformen?

Phase 1: Latenz-Profiling

Für jedes Kommando die Ausführungszeit messen:

Measure-Command { drift <command> [args] } | Select-Object TotalMilliseconds

Kommando	Args	Latenz (ms)	Bewertung	Anmerkung

Latenz-Klassifikation:

< 2s: acceptable — Agent kann synchron warten
2–15s: tolerable — Agent sollte Timeout-Handling implementieren
15s: disruptive — Agent-Loop wird unterbrochen

Bei disruptiver Latenz zusätzlich dokumentieren:

Gibt es eine leichtgewichtigere Alternative (z.B. scan statt analyze)?
Unterstützt das Kommando --max-findings oder ähnliche Begrenzung?
Ist Recovery nach Timeout möglich (identisches Ergebnis bei erneutem Lauf)?

Phase 2: Fehler-Verhalten

Provoziere realistische Fehlerszenarien:

drift analyze --repo /nonexistent
drift analyze --format unknown_format
drift scan --max-findings -1
drift export-context --repo . --format nonexistent

Pro Fehlerfall dokumentieren:

Fehlerszenario	Exit-Code	Fehlermeldung	Actionability (1-4)	Anmerkung

Fehler-Qualitätskriterien:

Enthält die Nachricht den konkreten Parameterwert, der fehlschlug?
Schlägt die Nachricht eine Korrektur vor (z.B. gültige Werte auflisten)?
Unterscheidet der Exit-Code Konfigurationsfehler von Analyseproblemen?
Ist die Fehlermeldung maschinell parsbar (Prefix-Konvention oder JSON)?

Phase 3: Output-Konsistenz

Vergleiche Output-Formate für identische Eingabe:

drift analyze --repo . --format json > results_json.json
drift analyze --repo . --format sarif > results_sarif.json
drift analyze --repo .

Konsistenz-Audit pro Format-Paar:

Attribut	JSON	SARIF	Rich-Terminal	Konsistenz
Anzahl Findings				`metadata-only` / `priority-shift` / `contradiction`
Signal-IDs
Severity-Labels
Betroffene Dateien
Reihenfolge

Idempotenz-Check

Für JSON und SARIF: Zweimalige Ausführung, Ergebnisse diffen:

drift analyze --repo . --format json > run1.json
drift analyze --repo . --format json > run2.json
diff run1.json run2.json

Klassifikation: stable / ordering-unstable / content-unstable

Phase 4: Help-zu-Output-Konsistenz

Für jedes Kommando, das --help Optionen dokumentiert:

Teste jede dokumentierte Option
Dokumentiere Diskrepanzen zwischen Beschreibung und Verhalten

Kommando	Option	Dokumentiert als	Tatsächliches Verhalten	Konsistent?

Phase 5: End-to-End-Agent-Szenario

Simuliere einen vollständigen Agent-Workflow:

1. drift --help                          → Kommandos entdecken
2. drift analyze --repo . --format json  → Ergebnisse erhalten
3. Ergebnisse parsen, höchstes Risiko identifizieren
4. drift explain <signal>                → Signal verstehen
5. Fix-Entscheidung treffen

Fließt der Workflow ohne menschliches Eingreifen? Wo bricht er ab?

Phase 6: Report erstellen

# Drift Agent UX Report

**Datum:** <YYYY-MM-DD>
**drift-Version:** [VERSION]
**Plattform:** [OS/SHELL]

## UX Scorecard

| Dimension | Bewertung | Evidenz | Impact |
|-----------|-----------|---------|--------|
| Auffindbarkeit | | | |
| Latenz | | | |
| Fehlermeldungen | | | |
| Output-Konsistenz | | | |
| Help-Genauigkeit | | | |
| End-to-End-Flow | | | |

## Latenz-Matrix

[Tabelle aus Phase 1]

## Fehlerkatalog

[Tabelle aus Phase 2]

## Konsistenz-Befunde

[Tabelle aus Phase 3]

## Auffindbarkeits-Audit

[Tabellen aus Phase 0 + 4]

## Prioritäre Verbesserungen

1. [...]
2. [...]
3. [...]

Entscheidungsregel

Wenn ein Agent einen Workflow nur mit Dokumentationslektüre abschließen kann, ist die CLI-UX unzureichend für Agent-Nutzung. CLI-Signale müssen für sich sprechen.

GitHub-Issue-Erstellung

Am Ende des Workflows GitHub-Issues erstellen gemäß .github/prompts/_partials/issue-filing.md.

Prompt-Kürzel für Titel: agent-ux

Issues erstellen für

Exit-Codes, die autonomes Recovery verhindern
Fehlermeldungen ohne Actionability (Score 3 oder 4)
Latenz-Probleme, die Agent-Schleifen unterbrechen (> 15s ohne Recovery)
Output-Inkonsistenzen zwischen Formaten (Klassifikation contradiction)
Help-Output, der von tatsächlichem Verhalten abweicht

Keine Issues erstellen für

Subjektive Formatpräferenzen ohne Agent-Impact
Lokale Umgebungseffekte auf Latenz (z.B. Antivirus)
Duplikate bereits existierender Issues

# Drift Agent UX Du evaluierst die Drift-CLI aus der Perspektive eines Agent-Users. Dein Fokus liegt auf Auffindbarkeit, Latenz, Fehlernachrichten und konsistentem Verhalten über Kommandos hinweg. > **Pflicht:** Vor Ausführung dieses Prompts das Drift Policy Gate durchlaufen > (siehe `.github/prompts/_partials/konventionen.md` und `.github/instructions/drift-policy.instructions.md`). ## Relevante Referenzen - **Instruction:** `.github/instructions/drift-policy.instructions.md` - **Bewertungssystem:** `.github/prompts/_partials/bewertungs-taxonomie.md` - **Issue-Filing:** `.github/prompts/_partials/issue-filing.md` - **Verwandte Prompts:** `drift-agent-workflow-test.prompt.md` (CI-Realism), `drift-ci-gate.prompt.md` (Gate-Perspektive) - **CLI-Implementierung:** `src/drift/commands/` (Click-CLI-Subcommands) ## Arbeitsmodus - Interagiere als Agent: systematisch, breadth-first, exit-code-gesteuert. - Beobachte und dokumentiere statt sofort zu bewerten. - Erkläre die Kognition hinter jedem Urteil (z.B. „ein Mensch würde X tun, ein Agent bräuchte Y"). - Wenn ein Workflow abbricht, bestimme die günstigste Abbruchursache, nicht die schlimmste. - Unterscheide Agent-UX-Probleme von allgemeinen CLI-Bugs. ## Ziel Bestimme, ob ein Coding-Agent Drift installieren, erkunden, nutzen und auf Ergebnisse reagieren kann — ohne Vorwissen, ohne Dokumentationslektüre, mit reinen CLI-Signalen. ## Erfolgskriterien Die Aufgabe ist erst abgeschlossen, wenn du beantworten kannst: - Konnte der Agent alle relevanten Kommandos und Optionen entdecken (`--help`-Auffindbarkeit)? - Sind Fehlermeldungen informativ genug, um autonomes Recovery zu leiten? - Ist die CLI-Latenz akzeptabel für interaktive Agent-Schleifen? - Sind Output-Formate über Kommandos und Läufe hinweg konsistent? ## Arbeitsregeln - Dokumentiere jedes Kommando mit Exit-Code und Antwortzeit. - Behandle Latenz > 15 Sekunden als agent-disruptiv; errechne Recovery-Möglichkeit (Timeout + Retry vs. Abbruch). - Verwende `--help` als primäre Auffindbarkeitsquelle — nicht Dokumentation. - Prüfe Output-Metadaten auf Konsistenz über Formate. - Bewerte Fehlermeldungen auf Actionability für autonomes Recovery. - Falls `--help` Optionen beschreibt, die im realen Output nicht sichtbar sind: dokumentiere die Diskrepanz. ## Bewertungs-Labels Verwende ausschließlich Labels aus `.github/prompts/_partials/bewertungs-taxonomie.md`: - **Ergebnis-Bewertung:** `pass` / `review` / `fail` - **Risiko-Level:** `low` / `medium` / `high` / `critical` - **Auffindbarkeits-Skala:** `self-explanatory` / `documented` / `hidden` / `misleading` - **Actionability-Score:** `1 automated` / `2 guided` / `3 human-review` / `4 blocked` ## Artefakte Erstelle Artefakte unter `work_artifacts/agent_ux_<YYYY-MM-DD>/`: 1. `discovery_log.md` 2. `latency_matrix.md` 3. `error_catalog.md` 4. `consistency_audit.md` 5. `agent_ux_report.md` ## Workflow ### Phase 0: Auffindbarkeit Erkunde die CLI als Zero-Knowledge-Agent. **Dev-Version sicherstellen** (siehe `_partials/konventionen.md` → Versions-Freshness): ```bash pip install -e . # Dev-Version aus Workspace drift --help drift --version # Muss mit pyproject.toml übereinstimmen ``` Für jedes Top-Level-Kommando: ```bash drift <command> --help ``` **Auffindbarkeits-Bewertung pro Kommando:** | Kommando | Sichtbar in `--help`? | Beschreibung verständlich ohne Kontext? | Optionen vollständig? | Auffindbarkeit | |----------|----------------------|----------------------------------------|----------------------|----------------| | | | | | `self-explanatory` / `documented` / `hidden` / `misleading` | **Subcommand-Konventionen-Check:** - Verwenden alle Kommandos konsistente Benennung? (z.B. `kebab-case` vs. `snake_case`) - Haben gemeinsame Optionen (z.B. `--repo`, `--format`) konsistente Defaults? - Gibt es Aliases oder undokumentierte Kurzformen? ### Phase 1: Latenz-Profiling Für jedes Kommando die Ausführungszeit messen: ```bash Measure-Command { drift <command> [args] } | Select-Object TotalMilliseconds ``` | Kommando | Args | Latenz (ms) | Bewertung | Anmerkung | |----------|------|-------------|-----------|-----------| | | | | | | **Latenz-Klassifikation:** - < 2s: `acceptable` — Agent kann synchron warten - 2–15s: `tolerable` — Agent sollte Timeout-Handling implementieren - > 15s: `disruptive` — Agent-Loop wird unterbrochen **Bei disruptiver Latenz zusätzlich dokumentieren:** - Gibt es eine leichtgewichtigere Alternative (z.B. `scan` statt `analyze`)? - Unterstützt das Kommando `--max-findings` oder ähnliche Begrenzung? - Ist Recovery nach Timeout möglich (identisches Ergebnis bei erneutem Lauf)? ### Phase 2: Fehler-Verhalten Provoziere realistische Fehlerszenarien: ```bash drift analyze --repo /nonexistent drift analyze --format unknown_format drift scan --max-findings -1 drift export-context --repo . --format nonexistent ``` Pro Fehlerfall dokumentieren: | Fehlerszenario | Exit-Code | Fehlermeldung | Actionability (1-4) | Anmerkung | |----------------|-----------|---------------|---------------------|-----------| | | | | | | **Fehler-Qualitätskriterien:** 1. Enthält die Nachricht den konkreten Parameterwert, der fehlschlug? 2. Schlägt die Nachricht eine Korrektur vor (z.B. gültige Werte auflisten)? 3. Unterscheidet der Exit-Code Konfigurationsfehler von Analyseproblemen? 4. Ist die Fehlermeldung maschinell parsbar (Prefix-Konvention oder JSON)? ### Phase 3: Output-Konsistenz Vergleiche Output-Formate für identische Eingabe: ```bash drift analyze --repo . --format json > results_json.json drift analyze --repo . --format sarif > results_sarif.json drift analyze --repo . ``` **Konsistenz-Audit pro Format-Paar:** | Attribut | JSON | SARIF | Rich-Terminal | Konsistenz | |----------|------|-------|---------------|------------| | Anzahl Findings | | | | `metadata-only` / `priority-shift` / `contradiction` | | Signal-IDs | | | | | | Severity-Labels | | | | | | Betroffene Dateien | | | | | | Reihenfolge | | | | | ### Idempotenz-Check Für JSON und SARIF: Zweimalige Ausführung, Ergebnisse diffen: ```bash drift analyze --repo . --format json > run1.json drift analyze --repo . --format json > run2.json diff run1.json run2.json ``` Klassifikation: `stable` / `ordering-unstable` / `content-unstable` ### Phase 4: Help-zu-Output-Konsistenz Für jedes Kommando, das `--help` Optionen dokumentiert: - Teste jede dokumentierte Option - Dokumentiere Diskrepanzen zwischen Beschreibung und Verhalten | Kommando | Option | Dokumentiert als | Tatsächliches Verhalten | Konsistent? | |----------|--------|-----------------|------------------------|-------------| ### Phase 5: End-to-End-Agent-Szenario Simuliere einen vollständigen Agent-Workflow: ``` 1. drift --help → Kommandos entdecken 2. drift analyze --repo . --format json → Ergebnisse erhalten 3. Ergebnisse parsen, höchstes Risiko identifizieren 4. drift explain <signal> → Signal verstehen 5. Fix-Entscheidung treffen ``` Fließt der Workflow ohne menschliches Eingreifen? Wo bricht er ab? ### Phase 6: Report erstellen ```markdown # Drift Agent UX Report **Datum:** <YYYY-MM-DD> **drift-Version:** [VERSION] **Plattform:** [OS/SHELL] ## UX Scorecard | Dimension | Bewertung | Evidenz | Impact | |-----------|-----------|---------|--------| | Auffindbarkeit | | | | | Latenz | | | | | Fehlermeldungen | | | | | Output-Konsistenz | | | | | Help-Genauigkeit | | | | | End-to-End-Flow | | | | ## Latenz-Matrix [Tabelle aus Phase 1] ## Fehlerkatalog [Tabelle aus Phase 2] ## Konsistenz-Befunde [Tabelle aus Phase 3] ## Auffindbarkeits-Audit [Tabellen aus Phase 0 + 4] ## Prioritäre Verbesserungen 1. [...] 2. [...] 3. [...] ``` ## Entscheidungsregel Wenn ein Agent einen Workflow nur mit Dokumentationslektüre abschließen kann, ist die CLI-UX unzureichend für Agent-Nutzung. CLI-Signale müssen für sich sprechen. ## GitHub-Issue-Erstellung Am Ende des Workflows GitHub-Issues erstellen gemäß `.github/prompts/_partials/issue-filing.md`. **Prompt-Kürzel für Titel:** `agent-ux` ### Issues erstellen für - Exit-Codes, die autonomes Recovery verhindern - Fehlermeldungen ohne Actionability (Score 3 oder 4) - Latenz-Probleme, die Agent-Schleifen unterbrechen (> 15s ohne Recovery) - Output-Inkonsistenzen zwischen Formaten (Klassifikation `contradiction`) - Help-Output, der von tatsächlichem Verhalten abweicht ### Keine Issues erstellen für - Subjektive Formatpräferenzen ohne Agent-Impact - Lokale Umgebungseffekte auf Latenz (z.B. Antivirus) - Duplikate bereits existierender Issues

{ "prompt": "# Drift Agent UX\n\nDu evaluierst die Drift-CLI aus der Perspektive eines Agent-Users. Dein Fokus liegt auf Auffindbarkeit, Latenz, Fehlernachrichten und konsistentem Verhalten über Kommandos hinweg.\n\n> **Pflicht:** Vor Ausführung dieses Prompts das Drift Policy Gate durchlaufen\n> (siehe `.github/prompts/_partials/konventionen.md` und `.github/instructions/drift-policy.instructions.md`).\n\n## Relevante Referenzen\n\n- **Instruction:** `.github/instructions/drift-policy.instructions.md`\n- **Bewertungssystem:** `.github/prompts/_partials/bewertungs-taxonomie.md`\n- **Issue-Filing:** `.github/prompts/_partials/issue-filing.md`\n- **Verwandte Prompts:** `drift-agent-workflow-test.prompt.md` (CI-Realism), `drift-ci-gate.prompt.md` (Gate-Perspektive)\n- **CLI-Implementierung:** `src/drift/commands/` (Click-CLI-Subcommands)\n\n## Arbeitsmodus\n\n- Interagiere als Agent: systematisch, breadth-first, exit-code-gesteuert.\n- Beobachte und dokumentiere statt sofort zu bewerten.\n- Erkläre die Kognition hinter jedem Urteil (z.B. „ein Mensch würde X tun, ein Agent bräuchte Y\").\n- Wenn ein Workflow abbricht, bestimme die günstigste Abbruchursache, nicht die schlimmste.\n- Unterscheide Agent-UX-Probleme von allgemeinen CLI-Bugs.\n\n## Ziel\n\nBestimme, ob ein Coding-Agent Drift installieren, erkunden, nutzen und auf Ergebnisse reagieren kann — ohne Vorwissen, ohne Dokumentationslektüre, mit reinen CLI-Signalen.\n\n## Erfolgskriterien\n\nDie Aufgabe ist erst abgeschlossen, wenn du beantworten kannst:\n- Konnte der Agent alle relevanten Kommandos und Optionen entdecken (`--help`-Auffindbarkeit)?\n- Sind Fehlermeldungen informativ genug, um autonomes Recovery zu leiten?\n- Ist die CLI-Latenz akzeptabel für interaktive Agent-Schleifen?\n- Sind Output-Formate über Kommandos und Läufe hinweg konsistent?\n\n## Arbeitsregeln\n\n- Dokumentiere jedes Kommando mit Exit-Code und Antwortzeit.\n- Behandle Latenz > 15 Sekunden als agent-disruptiv; errechne Recovery-Möglichkeit (Timeout + Retry vs. Abbruch).\n- Verwende `--help` als primäre Auffindbarkeitsquelle — nicht Dokumentation.\n- Prüfe Output-Metadaten auf Konsistenz über Formate.\n- Bewerte Fehlermeldungen auf Actionability für autonomes Recovery.\n- Falls `--help` Optionen beschreibt, die im realen Output nicht sichtbar sind: dokumentiere die Diskrepanz.\n\n## Bewertungs-Labels\n\nVerwende ausschließlich Labels aus `.github/prompts/_partials/bewertungs-taxonomie.md`:\n\n- **Ergebnis-Bewertung:** `pass` / `review` / `fail`\n- **Risiko-Level:** `low` / `medium` / `high` / `critical`\n- **Auffindbarkeits-Skala:** `self-explanatory` / `documented` / `hidden` / `misleading`\n- **Actionability-Score:** `1 automated` / `2 guided` / `3 human-review` / `4 blocked`\n\n## Artefakte\n\nErstelle Artefakte unter `work_artifacts/agent_ux_<YYYY-MM-DD>/`:\n\n1. `discovery_log.md`\n2. `latency_matrix.md`\n3. `error_catalog.md`\n4. `consistency_audit.md`\n5. `agent_ux_report.md`\n\n## Workflow\n\n### Phase 0: Auffindbarkeit\n\nErkunde die CLI als Zero-Knowledge-Agent.\n\n**Dev-Version sicherstellen** (siehe `_partials/konventionen.md` → Versions-Freshness):\n\n```bash\npip install -e . # Dev-Version aus Workspace\ndrift --help\ndrift --version # Muss mit pyproject.toml übereinstimmen\n```\n\nFür jedes Top-Level-Kommando:\n```bash\ndrift <command> --help\n```\n\n**Auffindbarkeits-Bewertung pro Kommando:**\n\n| Kommando | Sichtbar in `--help`? | Beschreibung verständlich ohne Kontext? | Optionen vollständig? | Auffindbarkeit |\n|----------|----------------------|----------------------------------------|----------------------|----------------|\n| | | | | `self-explanatory` / `documented` / `hidden` / `misleading` |\n\n**Subcommand-Konventionen-Check:**\n- Verwenden alle Kommandos konsistente Benennung? (z.B. `kebab-case` vs. `snake_case`)\n- Haben gemeinsame Optionen (z.B. `--repo`, `--format`) konsistente Defaults?\n- Gibt es Aliases oder undokumentierte Kurzformen?\n\n### Phase 1: Latenz-Profiling\n\nFür jedes Kommando die Ausführungszeit messen:\n\n```bash\nMeasure-Command { drift <command> [args] } | Select-Object TotalMilliseconds\n```\n\n| Kommando | Args | Latenz (ms) | Bewertung | Anmerkung |\n|----------|------|-------------|-----------|-----------|\n| | | | | |\n\n**Latenz-Klassifikation:**\n- < 2s: `acceptable` — Agent kann synchron warten\n- 2–15s: `tolerable` — Agent sollte Timeout-Handling implementieren\n- > 15s: `disruptive` — Agent-Loop wird unterbrochen\n\n**Bei disruptiver Latenz zusätzlich dokumentieren:**\n- Gibt es eine leichtgewichtigere Alternative (z.B. `scan` statt `analyze`)?\n- Unterstützt das Kommando `--max-findings` oder ähnliche Begrenzung?\n- Ist Recovery nach Timeout möglich (identisches Ergebnis bei erneutem Lauf)?\n\n### Phase 2: Fehler-Verhalten\n\nProvoziere realistische Fehlerszenarien:\n\n```bash\ndrift analyze --repo /nonexistent\ndrift analyze --format unknown_format\ndrift scan --max-findings -1\ndrift export-context --repo . --format nonexistent\n```\n\nPro Fehlerfall dokumentieren:\n\n| Fehlerszenario | Exit-Code | Fehlermeldung | Actionability (1-4) | Anmerkung |\n|----------------|-----------|---------------|---------------------|-----------|\n| | | | | |\n\n**Fehler-Qualitätskriterien:**\n1. Enthält die Nachricht den konkreten Parameterwert, der fehlschlug?\n2. Schlägt die Nachricht eine Korrektur vor (z.B. gültige Werte auflisten)?\n3. Unterscheidet der Exit-Code Konfigurationsfehler von Analyseproblemen?\n4. Ist die Fehlermeldung maschinell parsbar (Prefix-Konvention oder JSON)?\n\n### Phase 3: Output-Konsistenz\n\nVergleiche Output-Formate für identische Eingabe:\n\n```bash\ndrift analyze --repo . --format json > results_json.json\ndrift analyze --repo . --format sarif > results_sarif.json\ndrift analyze --repo .\n```\n\n**Konsistenz-Audit pro Format-Paar:**\n\n| Attribut | JSON | SARIF | Rich-Terminal | Konsistenz |\n|----------|------|-------|---------------|------------|\n| Anzahl Findings | | | | `metadata-only` / `priority-shift` / `contradiction` |\n| Signal-IDs | | | | |\n| Severity-Labels | | | | |\n| Betroffene Dateien | | | | |\n| Reihenfolge | | | | |\n\n### Idempotenz-Check\n\nFür JSON und SARIF: Zweimalige Ausführung, Ergebnisse diffen:\n\n```bash\ndrift analyze --repo . --format json > run1.json\ndrift analyze --repo . --format json > run2.json\ndiff run1.json run2.json\n```\n\nKlassifikation: `stable` / `ordering-unstable` / `content-unstable`\n\n### Phase 4: Help-zu-Output-Konsistenz\n\nFür jedes Kommando, das `--help` Optionen dokumentiert:\n- Teste jede dokumentierte Option\n- Dokumentiere Diskrepanzen zwischen Beschreibung und Verhalten\n\n| Kommando | Option | Dokumentiert als | Tatsächliches Verhalten | Konsistent? |\n|----------|--------|-----------------|------------------------|-------------|\n\n### Phase 5: End-to-End-Agent-Szenario\n\nSimuliere einen vollständigen Agent-Workflow:\n\n```\n1. drift --help → Kommandos entdecken\n2. drift analyze --repo . --format json → Ergebnisse erhalten\n3. Ergebnisse parsen, höchstes Risiko identifizieren\n4. drift explain <signal> → Signal verstehen\n5. Fix-Entscheidung treffen\n```\n\nFließt der Workflow ohne menschliches Eingreifen? Wo bricht er ab?\n\n### Phase 6: Report erstellen\n\n```markdown\n# Drift Agent UX Report\n\n**Datum:** <YYYY-MM-DD>\n**drift-Version:** [VERSION]\n**Plattform:** [OS/SHELL]\n\n## UX Scorecard\n\n| Dimension | Bewertung | Evidenz | Impact |\n|-----------|-----------|---------|--------|\n| Auffindbarkeit | | | |\n| Latenz | | | |\n| Fehlermeldungen | | | |\n| Output-Konsistenz | | | |\n| Help-Genauigkeit | | | |\n| End-to-End-Flow | | | |\n\n## Latenz-Matrix\n\n[Tabelle aus Phase 1]\n\n## Fehlerkatalog\n\n[Tabelle aus Phase 2]\n\n## Konsistenz-Befunde\n\n[Tabelle aus Phase 3]\n\n## Auffindbarkeits-Audit\n\n[Tabellen aus Phase 0 + 4]\n\n## Prioritäre Verbesserungen\n\n1. [...]\n2. [...]\n3. [...]\n```\n\n## Entscheidungsregel\n\nWenn ein Agent einen Workflow nur mit Dokumentationslektüre abschließen kann, ist die CLI-UX unzureichend für Agent-Nutzung. CLI-Signale müssen für sich sprechen.\n\n## GitHub-Issue-Erstellung\n\nAm Ende des Workflows GitHub-Issues erstellen gemäß `.github/prompts/_partials/issue-filing.md`.\n\n**Prompt-Kürzel für Titel:** `agent-ux`\n\n### Issues erstellen für\n\n- Exit-Codes, die autonomes Recovery verhindern\n- Fehlermeldungen ohne Actionability (Score 3 oder 4)\n- Latenz-Probleme, die Agent-Schleifen unterbrechen (> 15s ohne Recovery)\n- Output-Inkonsistenzen zwischen Formaten (Klassifikation `contradiction`)\n- Help-Output, der von tatsächlichem Verhalten abweicht\n\n### Keine Issues erstellen für\n\n- Subjektive Formatpräferenzen ohne Agent-Impact\n- Lokale Umgebungseffekte auf Latenz (z.B. Antivirus)\n- Duplikate bereits existierender Issues", "variables": [], "notes": "Bewertet Drift-CLI aus Agent-Perspektive: Auffindbarkeit, Feedback-Latenz, Fehlermeldungen, End-to-End-Konsistenz. Vergleicht Agent-UX mit menschlicher UX.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/mick-gsk/drift", "path": ".github/prompts/drift-agent-ux.prompt.md", "ref": "7729a84d4a5c4966a55dfa71233aea6d22261615", "url": "https://github.com/mick-gsk/drift/blob/7729a84d4a5c4966a55dfa71233aea6d22261615/.github/prompts/drift-agent-ux.prompt.md", "key": "mick-gsk/drift/.github/prompts/drift-agent-ux.prompt.md" } } }

Drift Agent UX

About

Drift Agent UX

Relevante Referenzen

Arbeitsmodus

Ziel

Erfolgskriterien

Arbeitsregeln

Bewertungs-Labels

Artefakte

Workflow

Phase 0: Auffindbarkeit

Phase 1: Latenz-Profiling

Phase 2: Fehler-Verhalten

Phase 3: Output-Konsistenz

Idempotenz-Check

Phase 4: Help-zu-Output-Konsistenz

Phase 5: End-to-End-Agent-Szenario

Phase 6: Report erstellen

Entscheidungsregel

GitHub-Issue-Erstellung

Issues erstellen für

Keine Issues erstellen für

Use it

Manifest

Reviews