openclaw/skills/gitea-analyse-architektur/SKILL.md

name, description

name	description
gitea-analyse-architektur	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 und erstellt die Grundlage für alle folgenden Phasen.

Eingang

• Gitea Issue nur mit Label KI
• Issue-Body, Kommentare, verlinkte Ressourcen

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 (Architektur, Teilaufgaben, Akzeptanzkriterien, etc.)
• Spezifikation als Kommentar ins Issue geschrieben
• Dem Issue den Tag ReadyForDev hinzufügen:

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