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>
Notiz und Status setzen ist in Ordnung, assigned_to_id nicht anfassen —
das entscheidet der User selbst.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Zwei Ergaenzungen zu den Posting-Regeln: keine Icons, Emoji oder
dekorativen Symbole im Ticket-Text, und als Norm zwei bis drei Saetze
ohne Commit-Hashes, Dateinamen oder Messwerte. Der Kunde hat nicht
gefragt, wie etwas geloest wurde, sondern ob.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Small, generic skill for reading/updating a self-hosted Redmine over its
REST API from the CLI: API-key-in-header auth (never inline the secret),
issues/journals/attachments endpoints, editing a journal note in place,
the collection-ticket pattern, Textile (not Markdown) formatting +
localized statuses, and the team posting-style rules (minimal
customer-visible notes — strike through or "erledigt", never the bug's
cause; don't post unless asked). Distilled from the IVV Redmine notes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
melnicenkoandClaude Opus 5