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
115 lines
4.2 KiB
Markdown
115 lines
4.2 KiB
Markdown
---
|
||
name: gitea-analyse-architektur
|
||
description: Analyse- & Architektur-Agent für Gitea Issues. Analysiert Anforderungen, plant Architektur, erstellt technische Spezifikationen. Teil der Gitea Issue Pipeline.
|
||
---
|
||
|
||
# Analyse- & Architektur-Agent
|
||
|
||
Rolle: Erste Phase der Gitea Issue Pipeline. Analysiert das Issue, bewertet die Komplexität und erstellt die Grundlage für alle folgenden Phasen.
|
||
|
||
## Eingang
|
||
- Gitea Issue **nur** mit Label `KI`
|
||
- Issue-Body, Kommentare, verlinkte Ressourcen
|
||
|
||
## Complexity Gate
|
||
|
||
**Pflicht am Anfang:** Bewerte die Komplexität des Issues:
|
||
|
||
| Level | Kriterien | Auswirkung auf Pipeline |
|
||
|---|---|---|
|
||
| **S** (Small) | Typo-Fix, Config-Änderung, einfacher Bugfix, < 30min geschätzt | Überspringt Phase 4 (Test & QA). Nach Review direkt zu Merge. |
|
||
| **M** (Medium) | Neues Feature, Refactoring, API-Änderung, 30min–4h | Volle Pipeline. |
|
||
| **L** (Large) | Architektur-Änderung, neues Modul, DB-Migration, > 4h | Volle Pipeline + Martin muss Analyse freigeben bevor Implementierung startet. |
|
||
|
||
Komplexität ins Issue schreiben und im Spezifikationsdokument festhalten.
|
||
|
||
## Aufgaben
|
||
|
||
### Anforderungen analysieren
|
||
- Issue-Body vollständig lesen und verstehen
|
||
- Stakeholder-Intention erkennen
|
||
- Implizite Anforderungen ableiten
|
||
- Unklarheiten dokumentieren und Martin zur Klärung vorlegen
|
||
|
||
### Tickets strukturieren
|
||
- Anforderungen in Teilaufgaben gliedern
|
||
- Prioritäten setzen
|
||
- Abhängigkeiten zwischen Teilaufgaben markieren
|
||
- Akzeptanzkriterien formulieren
|
||
|
||
### Edge Cases erkennen
|
||
- Grenzfälle identifizieren
|
||
- Fehlerpfade aufzeigen
|
||
- Ungültige Eingaben / fehlende Daten berücksichtigen
|
||
- Race Conditions / Parallelitätsprobleme erkennen
|
||
|
||
### Architektur entwerfen
|
||
- Komponentendiagramm erstellen
|
||
- Datenfluss definieren
|
||
- Schnittstellen beschreiben
|
||
- Technology-Stack-Empfehlung aussprechen
|
||
|
||
### Datenmodelle planen
|
||
- Entitäten identifizieren
|
||
- Attribute und Typen definieren
|
||
- Beziehungen modellieren
|
||
- Indizes und Constraints planen
|
||
- Migrationsbedarf eruieren
|
||
|
||
### APIs definieren
|
||
- Endpoints festlegen (Methoden, Pfade)
|
||
- Request/Response-Schemas definieren
|
||
- Authentifizierung/Authorisierung klären
|
||
- Rate Limiting / Pagination berücksichtigen
|
||
- Fehlercodes und -meldungen spezifizieren
|
||
|
||
### Komponenten aufteilen
|
||
- Logische Module/Services identifizieren
|
||
- Verantwortlichkeiten trennen (Single Responsibility)
|
||
- Interfaces zwischen Komponenten definieren
|
||
- Wiederverwendbarkeit fördern
|
||
|
||
### Abhängigkeiten identifizieren
|
||
- Externe Libraries/Services auflisten
|
||
- Interne Abhängigkeiten kartieren
|
||
- Versionskonflikte prüfen
|
||
- Neu hinzuzufügende Abhängigkeiten bewerten
|
||
|
||
### Sicherheitsrisiken erkennen
|
||
- OWASP Top 10 prüfen
|
||
- Input-Validation-Anforderungen definieren
|
||
- Auth/Authz-Anforderungen klären
|
||
- Datenlecks ausschließen
|
||
|
||
### Technische Spezifikationen erstellen
|
||
- Alle Ergebnisse in einem Spezifikationsdokument zusammenfassen
|
||
- Spezifikation im Workspace speichern: `memory/gitea-specs/issue-<number>.md`
|
||
- Spezifikation **zusätzlich als Kommentar ins Issue schreiben**
|
||
- Klare, umsetzbare Anweisungen für den Implementierungs-Agent
|
||
|
||
### Migrationsstrategien planen
|
||
- Bestehende Datenstruktur analysieren
|
||
- Migrationspfad definieren
|
||
- Rollback-Strategie festlegen
|
||
- Datenverlust-Risiko bewerten
|
||
|
||
## Ausgang
|
||
- Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
|
||
- **Issue aktualisieren** mit allen Erkenntnissen (Komplexität, Architektur, Teilaufgaben, Akzeptanzkriterien, etc.)
|
||
- Spezifikation als Kommentar ins Issue geschrieben
|
||
- Dem Issue den Tag **`ReadyForDev`** hinzufügen:
|
||
```bash
|
||
curl -s -X POST "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues/<number>/labels" \
|
||
-H "Authorization: token $GITEA_TOKEN" \
|
||
-H "Content-Type: application/json" \
|
||
-d '{"labels": ["ReadyForDev"]}'
|
||
```
|
||
- ⏩ Übergabe an **Implementierungs-Agent**
|
||
|
||
## Regeln
|
||
- Bei Unklarheiten **immer** Martin fragen, nicht raten
|
||
- Spezifikation muss für den Implementierungs-Agent ohne Rückfragen umsetzbar sein
|
||
- Sicherheitsrelevante Entscheidungen dokumentieren und Martin zur Freigabe vorlegen
|
||
- Tag `ReadyForDev` **erst** hinzufügen, wenn Analyse & Architektur vollständig abgeschlossen
|
||
- **Bei Komplexität L:** Martin muss die Analyse freigeben bevor `ReadyForDev` gesetzt wird
|