Redmine-Skill: Rollen im Team und was sie fuer die Zustaendigkeit bedeuten

Der Bearbeiter eines Tickets sagt, um welche ART von Arbeit es geht.
Die Rollen sind ueber alle TYPO3-Projekte hinweg dieselben, deshalb
gehoeren sie in die Skill und nicht in ein Projektgedaechtnis, das nur
fuer ein Projekt geladen wird.

Festgehalten: Ilja und Sven entwickeln, Corinna macht Design und den
Grossteil der redaktionellen Arbeit, Eva fuehrt das Projekt und aendert
redaktionell im Kleinen. Daraus folgen zwei Regeln, die sich in der
Praxis bewaehrt haben: ein redaktionelles Ticket nicht stillschweigend
selbst erledigen, aber CSS und Code auch dann uebernehmen, wenn das
Ticket jemand anderem zugewiesen ist - Tickets mischen beides oft, also
nach der Natur der einzelnen Punkte aufteilen und sagen, welche Haelfte
man liegen laesst.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

redmine-issue-workflow/SKILL.md

@@ -3,7 +3,7 @@ name: redmine-issue-workflow
 description: "Read and update issues on a self-hosted Redmine via its REST API from the CLI — list/read tickets, add notes, change status, edit an existing journal note in place, and download attachments. Use when a project tracks its work/bugs in Redmine and you need to look up 'the next fixes', check a ticket's details, mark work done, or maintain a collection ('Sammelticket') ticket. Covers: API-key auth via header (never inline the secret), the issues/journals/attachments endpoints, Textile (NOT Markdown) formatting, localized statuses, and the posting-style rules (keep customer-visible notes minimal — strike through or 'erledigt', don't write the bug's cause; don't post unless asked)."
 metadata:
   author: Wappler
-  version: "1.2"
+  version: "1.3"
 ---
 
 # Redmine issue workflow (REST API, CLI)
@@ -68,6 +68,26 @@ Redmine renders **Textile** by default. Consequences:
 - Before posting a status change, prefer to draft the (short, German if the project is German) note and
   confirm the target status with the user.
 
+## Who does what — the same team across all TYPO3 projects
+The assignee tells you what KIND of work a ticket is. These roles hold across projects, so read them
+before deciding whether a ticket is yours to act on.
+
+- **Ilja** (the user) and **Sven** — the **developers**. Code, templates, SCSS, TypoScript,
+  deployments. Sven maintains the shared WapplerSystems extensions, so coordinate with him before
+  cutting a tag on one of those.
+- **Corinna** — **design and the bulk of editorial work**. Content tickets (texts, images, page
+  structure) are hers.
+- **Eva** — **project management**, plus light editorial changes. Typically the one who maintains a
+  Sammelticket's item list and re-assigns tickets.
+
+Consequences:
+- **A ticket assigned to Corinna or Eva is editorial — don't silently do the work.** Report what you
+  found if it helps, but leave the change to them.
+- **CSS and code are yours even when the ticket is assigned to someone else.** Tickets often mix the
+  two: split them by the NATURE of each item, not by the assignee, do the technical half, and say
+  plainly which half you left alone and why.
+- This is also why the assignee must never be changed by you (above): it encodes the routing.
+
 ## Attachments
 `GET /attachments/download/<id>/<name>` needs the **exact** filename (a placeholder → 404 HTML). Reliable:
 `GET /attachments/<id>.json` → read `content_url` → `curl -L` THAT with the API-key header. Attached