--- description: Audit der gh-tickets PowerShell-Skripte auf bekannte Fehlerklassen. Kopiere dieses Prompt in ein anderes Repo, das ähnliche Skripte verwendet. agent: agent model: Claude Sonnet 4.6 (copilot) tools: [read, edit, search, execute] --- # Audit: gh-tickets PowerShell-Skripte Dieses Prompt prüft die PowerShell-Skripte eines `gh-tickets`-Skills (oder ähnlicher GitHub-CLI-Skripte) auf bekannte Fehlerklassen und repariert gefundene Probleme. --- ## Schritt 1 – Skripte lokalisieren Suche alle `.ps1`-Dateien im Skill-Verzeichnis (typisch: `.github/skills/gh-tickets/`). Lies jede Datei vollständig. --- ## Schritt 2 – Prüfliste Prüfe **jedes Skript** auf folgende Muster: ### 2a) `gh` CLI – `--json`-Flag mit Leerzeichen nach Kommas **Fehlermuster:** ```powershell gh issue view $N --repo $repo --json number, title, labels ``` **Problem:** `gh` interpretiert `number,`, `title,` und `labels` als drei separate Positionsargumente → Fehler `accepts 1 arg(s), received 3`. **Korrektur:** Keine Leerzeichen nach Kommas: ```powershell gh issue view $N --repo $repo --json number,title,labels ``` --- ### 2b) `gh project item-list` ohne `--limit` **Fehlermuster:** ```powershell gh project item-list 2 --owner --format json | ConvertFrom-Json ``` **Problem:** Standard-Limit ist 20 Items. Bei >20 Items im Board werden Tickets stillschweigend nicht zurückgegeben – keine Fehlermeldung, falsches Ergebnis. **Korrektur:** ```powershell gh project item-list 2 --owner --format json --limit 200 | ConvertFrom-Json ``` Prüfe alle Stellen im Skript, nicht nur die erste – manche Skripte rufen `item-list` mehrfach auf (z. B. einmal zum Suchen, einmal zum Lesen des Minimum-Order-Werts). --- ### 2c) Type-Label-Validierung unvollständig **Fehlermuster:** Validierung prüft nur einen Teil der gültigen Type-Labels: ```powershell $hasType = ($labelList -contains "migration") -or ($labelList -contains "tech-decision") -or ($labelList -contains "infrastructure") ``` **Problem:** Weitere gültige Typen (`block-planning`, `feature`, `refactoring`, `planning`, `test`) werden als ungültig abgelehnt → Issues mit diesen Labels können nicht erstellt werden. **Korrektur:** Vollständige Liste verwenden und dynamisch prüfen: ```powershell $validTypes = @("migration","tech-decision","infrastructure","block-planning","feature","refactoring","planning","test") $hasType = ($labelList | Where-Object { $validTypes -contains $_ }).Count -gt 0 if (-not $hasType) { Write-Error "Mindestens ein Type-Label erforderlich: $($validTypes -join ', ')" exit 1 } ``` Passe `$validTypes` an die im jeweiligen Repo tatsächlich verwendeten Labels an (SKILL.md oder ähnliche Konventionsdatei lesen). --- ### 2d) Weitere Plausibilitätsprüfungen - **`$LASTEXITCODE` nach Pipeline:** Bei `external_cmd 2>&1 | Out-Null` – prüfe, ob `$LASTEXITCODE` danach korrekt ausgewertet wird. In PowerShell 5.1 ist das zuverlässig; in PS 7 kann `-ErrorAction` nötig sein. - **Fehlende Null-Checks:** Wenn `$item` aus einer `Where-Object`-Abfrage kommen kann, prüfe ob `if (-not $item)` vorhanden ist. - **Hardcodierte IDs:** Project-ID, Field-IDs und Option-IDs sind oft hartcodiert. Prüfe ob sie noch mit dem tatsächlichen Board übereinstimmen (`gh project field-list --owner --format json`). --- ## Schritt 3 – Fixes anwenden Für jeden gefundenen Bug: 1. Datei bearbeiten und Fix anwenden 2. Fix direkt im Terminal testen (Skript aufrufen, Ausgabe prüfen) 3. Kurze Zusammenfassung: welcher Bug, welches Skript, wie gefixt --- ## Schritt 4 – Ergebnis berichten Erstelle am Ende eine kompakte Tabelle: | Skript | Bug | Status | |--------|-----|--------| | `next-ticket.ps1` | `--json`-Leerzeichen | ✅ gefixt | | … | … | … / ✅ nicht betroffen |