4514e5cef9
Dokumentiert die 3 in diesem Repo gefundenen Fehlerklassen als wiederverwendbares Prüf-Prompt für andere Repos mit ähnlichen gh-tickets PowerShell-Skripten.
103 lines
3.8 KiB
Markdown
103 lines
3.8 KiB
Markdown
---
|
||
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 |
|