Files
Projektwissen/.agents/skills/sn-aufgabe-bearbeiten/SKILL.md
T
DanielandClaude Opus 5.5 31131cc5c3 Prozessbibliothek als eigenes Repository auslagern (#9)
- ADR 0004 ersetzt ADR 0003: Die Prozessmodelle liegen im Repository
  AG_Prozesse/Prozessbibliothek, geklont nach Prozessbibliothek/ (neuer
  Eintrag in workspace.toml, .gitignore). prozesse/ ist entfernt; das
  Ablageformat (Ordner je Prozess, drei Dateien, Status) bleibt.
- pruefe_prozesse.py prüft den Klon (Ort über setup_workspace.repos_root),
  lässt Punkt-Ordner wie .git aus und erlaubt in der Wurzel nur die
  Repo-Dateien. Fehlt der Klon, gibt es einen Hinweis statt eines Befunds;
  pytest warnt dann.
- einlesen.py sucht den Bestand in der Bibliothek und nennt Treffer als
  Prozessbibliothek/<name>/, auch wenn der Klon woanders liegt.
- Regeln aus prozesse/README.md nach docs/leitfaden/08_prozessbibliothek.md,
  inklusive Ablauf bei Konverteränderungen (zwei Pull Requests).
- Verweise in AGENTS.md, README, Skills, Leitfäden, Vorlagen, Fallstricken
  und STATUS nachgezogen.
- Tests: python -m pytest -q -> 88 bestanden, 1 xfail (#8), 1 Warnung
  (Bibliothek noch nicht geklont).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-25 09:40:52 +02:00

3.8 KiB
Raw Blame History

name, description
name description
sn-aufgabe-bearbeiten Standardablauf für eine Aufgabe im Projektwissen der AG Prozesse (Konverter md_to_bpmn.py, Skills, Skripte, Doku, Prozessmodelle) von Gitea-Issue über Branch, Umsetzung und Tests bis zum vorbereiteten Pull Request mit Übergabenotiz. Verwenden bei "bearbeite Issue", "setze um", "Bugfix", "neue Funktion".

Aufgabe bearbeiten

Für das reine Modellieren eines Prozesses gilt der Skill sn-bpmn. Dieser Ablauf gilt, wenn etwas im Repository geändert und per Pull Request zurückgeführt wird.

0. Stand holen (nicht überspringen)

python scripts/hallo.py

Holt den Serverstand und aktualisiert main per Fast-Forward, wo das gefahrlos geht. Ohne diesen Schritt wird womöglich etwas behoben, das längst behoben ist.

1. Auftrag verstehen (nicht überspringen)

  • Issue mit Kommentaren lesen – Skill sn-ticket, python scripts/gitea.py ticket Projektwissen <nr>. Label Diskussion = noch kein Konsens: Annahmen im PR kennzeichnen.
  • Ziel, Abnahmekriterien und Grenzen in drei Sätzen zurückspiegeln, bevor etwas geändert wird. Fehlt ein Abnahmekriterium, ist das die erste Rückfrage – nicht der erste Commit.

2. Kontext laden – gezielt

  • docs/status/STATUS.md (wer arbeitet woran), bei Überraschungen docs/wissen/fallstricke.md.
  • Am Konverter: grep -n "def \|class " .agents/skills/sn-bpmn/md_to_bpmn.py für die Struktur, dann nur die betroffenen Abschnitte lesen. Die Datei hat über 1000 Zeilen.
  • Fachliche Regeln: .agents/skills/sn-bpmn/Modellierregeln.md, Elementkatalog.md, Anleitung.md.

3. Branch

Immer von main. Vollständig: docs/leitfaden/05_git_arbeitsweise.md. Kein feature/- oder bugfix/-Branch ohne Issue-Nummer. Gibt es kein Issue, zuerst einen Entwurf vorbereiten (Skill sn-ticket) und warten, bis der Mensch es angelegt hat. Nur doku/… kommt ohne Issue aus.

git switch main && git pull --ff-only
git switch -c feature/<issue-nr>-<kurzname>   # oder bugfix/… ; klein, ASCII, mit Nummer

4. Umsetzen

  • Kleine Schritte, jeder für sich prüfbar. Nach jedem Schritt python -m pytest -q.
  • Regeln aus AGENTS.md: nur Standardbibliothek, kein Umbau nebenbei, Stil der Datei beibehalten, Deutsch mit echten Umlauten.
  • Neue Logik bekommt einen Test – Konverter in .agents/skills/sn-bpmn/test_md_to_bpmn.py, Skripte in tests/test_<skript>.py. pytest, ohne Netzwerk, ein Test je Verhalten. Bei einem Bugfix zuerst den Test schreiben, der den Fehler zeigt.
  • Jeder neue oder geänderte Test bekommt einen deutschen Docstring, erste Zeile """Prüft, dass …""".
  • Ändert sich die Markdown-Syntax oder ein Element: Anleitung.md bzw. Elementkatalog.md mitziehen. Syntax und Ablageformat sind Verträge (AGENTS.md): vorher alle Modelle der Prozessbibliothek prüfen, danach python scripts/pruefe_prozesse.py --erzeugen und die neu erzeugten .bpmn als eigenen Pull Request in der Bibliothek vorbereiten (docs/leitfaden/08_prozessbibliothek.md, „Wenn sich der Konverter ändert“).

5. Nachweis

  • python -m pytest -q → alles grün.
  • python scripts/pruefe_umlaute.py → keine Funde.
  • Ändert sich die erzeugte BPMN-Datei: ein Beispiel erzeugen und in PICTURE importieren. Kannst du das nicht selbst, im PR als offenen Punkt eintragen. Nicht als erledigt ausgeben.

6. Abschluss

  • Commit-Nachrichten deutsch, Präsens, erste Zeile ≤ 72 Zeichen, Issue-Nummer am Ende.
  • Pull-Request-Text vollständig nach docs/vorlagen/pull_request.md vorbereiten: jeder Abschnitt, auch „Änderungen an Syntax und Ablageformat“ (notfalls „keine“) und die Checkliste mit ehrlich gesetzten Haken. Übergabenotiz mit Skill sn-uebergabe.
  • Hier ist Schluss. Push, Pull Request, Merge und alles auf Gitea macht der Mensch.