f94cfb41e6
- Complexity Gate: S/M/L in Phase 1, S skips QA, L needs Martin approval - Max 3 fix cycles, then pause and ask Martin - KI self-review disclaimer in Code Review - Removed Phase 7 (Deployment) entirely - Renumbered: 7 phases instead of 9 - Updated all skills with new phase numbers
142 lines
5.0 KiB
Markdown
142 lines
5.0 KiB
Markdown
---
|
||
name: gitea-issue-resolver
|
||
description: Pipeline-Orchestrator für Gitea Issues. Koordiniert die 7 Agenten-Phasen von der Analyse bis zum Closing. Use when checking or working on issues in Martin's Gitea repos (git.home.kies-media.de). Triggers on mentions of "issues", "Gitea issues", or when checking repos for open issues.
|
||
---
|
||
|
||
# Gitea Issue Resolver – Pipeline Orchestrator
|
||
|
||
Koordiniert die gesamte Issue-Pipeline. Holt Issues ab und steuert sie durch die Phasen.
|
||
|
||
## Authentication
|
||
|
||
Use git credentials from `~/.git-credentials` for API calls:
|
||
```bash
|
||
GIT_CREDS=$(grep git.home.kies-media.de ~/.git-credentials | head -1)
|
||
GIT_USER=$(echo "$GIT_CREDS" | sed -n 's|.*://\([^:]*\):.*|\1|p')
|
||
GIT_PASS=$(echo "$GIT_CREDS" | sed -n 's|.*://[^:]*:\([^@]*\)@.*|\1|p')
|
||
```
|
||
|
||
Gitea API token: `$GITEA_TOKEN` (in `.bashrc`):
|
||
```bash
|
||
GITEA_TOKEN="568841…2e34"
|
||
```
|
||
|
||
## Complexity Gate
|
||
|
||
Phase 1 bewertet die Komplexität. Das bestimmt den Pipeline-Verlauf:
|
||
|
||
| Komplexität | Pipeline |
|
||
|---|---|
|
||
| **S** (Small) | Phase 1 → 2 → 3 → 5 → 6 → 7 *(überspringt QA)* |
|
||
| **M** (Medium) | Phase 1 → 2 → 3 → 4 → 5 → 6 → 7 *(volle Pipeline)* |
|
||
| **L** (Large) | Phase 1 → **Martin-Freigabe** → 2 → 3 → 4 → 5 → 6 → 7 *(Analyse muss freigegeben werden)* |
|
||
|
||
## Pipeline – 7 Phasen
|
||
|
||
### Issue-Filter
|
||
Phase 1 (Analyse) holt Issues **nur** mit Tag `KI`:
|
||
|
||
```bash
|
||
curl -s "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues?state=open&labels=KI" \
|
||
-u "$GIT_USER:$GIT_PASS"
|
||
```
|
||
|
||
Ab Phase 2 (Implementierung) werden nur Issues mit **beiden** Tags `KI` + `ReadyForDev` weiterverarbeitet (wird von Phase 1 gesetzt).
|
||
|
||
### Phase 1: Analyse- & Architektur-Agent → `gitea-analyse-architektur`
|
||
- Complexity Gate: S / M / L bewerten
|
||
- Anforderungen analysieren, Architektur entwerfen
|
||
- Spezifikation erstellen + ins Issue schreiben
|
||
- Tag `ReadyForDev` hinzufügen (bei L: erst nach Martins Freigabe)
|
||
- Output: `memory/gitea-specs/issue-<number>.md`
|
||
|
||
### Phase 2: Implementierungs-Agent → `gitea-implementierung`
|
||
- Feature Branch erstellen
|
||
- Code schreiben
|
||
- Commits strukturieren
|
||
- Output: Code auf Feature Branch
|
||
|
||
### Phase 3: Code-Review-Agent → `gitea-code-review`
|
||
- Codequalität & Sicherheit prüfen
|
||
- Self-Review (bei kritischen Änderungen: Martin bitten)
|
||
- Review-Kommentare erstellen
|
||
- Output: APPROVED oder CHANGES_REQUESTED
|
||
|
||
### Phase 4: Test- & QA-Agent → `gitea-test-qa` *(übersprungen bei S)*
|
||
- Unit-, Integration-, E2E-Tests
|
||
- QA-Report erstellen
|
||
- Output: PASS oder FAIL
|
||
|
||
### Phase 4-fix: Fix- & Refactoring-Agent → `gitea-fix-refactoring` *(bei Bedarf, max. 3 Zyklen)*
|
||
- Review-Feedback umsetzen
|
||
- Bugs korrigieren
|
||
- Nach max. 3 Zyklen: Martin informieren
|
||
- Danach zurück zur jeweiligen Phase (Review oder QA)
|
||
|
||
### Phase 5: Merge- & Release-Agent → `gitea-merge-release`
|
||
- PR erstellen
|
||
- Release Notes & Versionierung
|
||
- **Wartet auf Martins Freigabe**
|
||
|
||
### Phase 6: Abnahme- & Validierungs-Agent → `gitea-abnahme-validierung`
|
||
- Anforderungen validieren
|
||
- Akzeptanzkriterien abhaken
|
||
- Output: ACCEPTED oder REJECTED
|
||
|
||
### Phase 7: Dokumentations- & Closing-Agent → `gitea-dokumentation-closing`
|
||
- Dokumentation erstellen
|
||
- Issue schließen
|
||
- Abschlussbericht
|
||
|
||
## Pipeline-Fluss
|
||
|
||
```
|
||
Issue (Label: KI)
|
||
│
|
||
▼
|
||
[1] Analyse & Architektur ──→ Complexity: S / M / L
|
||
│ │ │ │
|
||
│ (setzt ReadyForDev) S M L → Martin freigeben
|
||
│ │ │ │
|
||
▼ ▼ ▼ ▼
|
||
[2] Implementierung ──────────────────────────────────
|
||
│
|
||
▼
|
||
[3] Code Review ──── CHANGES_REQUESTED ──→ [fix] Fix & Refactoring ──→ [3]
|
||
│ APPROVED (max. 3 Zyklen, dann Martin fragen)
|
||
│
|
||
├─ S ──────────────────────────────────→ [5] Merge & Release
|
||
│
|
||
▼ (M, L)
|
||
[4] Test & QA ────── FAIL ──────────────→ [fix] Fix & Refactoring ──→ [4]
|
||
│ PASS
|
||
▼
|
||
[5] Merge & Release (wartet auf Martins Freigabe)
|
||
│
|
||
▼
|
||
[6] Abnahme & Validierung ── REJECTED ──→ [2] Implementierung
|
||
│ ACCEPTED
|
||
▼
|
||
[7] Dokumentation & Closing → Issue geschlossen ✅
|
||
```
|
||
|
||
## Orchestrierung
|
||
|
||
Für jedes Issue:
|
||
1. Spezifikations-Verzeichnis erstellen: `mkdir -p memory/gitea-specs`
|
||
2. Komplexität aus Phase 1 berücksichtigen für Pipeline-Verlauf
|
||
3. Fix-Zyklen zählen, bei >3 abbrechen und Martin informieren
|
||
4. Martin bei wichtigen Meilensteinen informieren:
|
||
- Spezifikation fertig + Komplexität (Phase 1)
|
||
- PR erstellt (Phase 5)
|
||
- Issue geschlossen (Phase 7)
|
||
|
||
## Regeln
|
||
- Phase 1 filtert auf **nur** `KI`
|
||
- Ab Phase 2: **nur** Issues mit `KI` + `ReadyForDev`
|
||
- **Nie** ohne Martins Freigabe mergen
|
||
- **Nie** Issue selbst schließen (nur Phase 7 darf das)
|
||
- **Nie** direkt auf `main` pushen
|
||
- **Max. 3** Fix-Zyklen, dann Martin fragen
|
||
- Bei Blockern: sofort Martin informieren
|