---
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 <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 <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 <N> --owner <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 |
