greggy/openclaw
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f94cfb41e6b66ba2b45db6e2c44f838a2a1a348a
openclaw/skills/gitea-analyse-architektur/SKILL.md
OpenClaw f94cfb41e6 feat: pipeline improvements + remove deployment phase 
- 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
2026-05-10 20:37:13 +00:00

4.2 KiB
Raw Blame History

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, 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:
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