f-reiser
OrganizationArbeitsweise fuer alle Softwareprojekte als Claude-Plugin (Marketplace reiser-skills)
Categories
Indexed Skills (7)
erklaeren-mit-mass
Prüft jede Erklärung darauf, ob sie ihren Platz verdient — in Code-Kommentaren, Commit-Meldungen, Pull-Request-Texten, Issue-Kommentaren, README- und Doku-Dateien. Grundsatz: WARUM statt WAS, und so wenig wie möglich, weil jede Zeile Dokumentation gelesen und gepflegt werden muss. Nutze diesen Skill, bevor du einen Kommentar, eine Commit-Meldung, einen PR-Text, ein Issue oder einen Doku-Abschnitt schreibst oder überarbeitest, und wenn zu entscheiden ist, ob etwas überhaupt dokumentiert gehört. Ebenso, wenn Text gekürzt, aufgeräumt oder von Füllmaterial befreit werden soll.
fremde-gegenlese
Lässt Tests und weitreichende Auslegungen von Anforderungen durch einen unabhängigen Agenten gegenprüfen, der weder den Code noch die eigenen Überlegungen kennt — er legt die Anforderung selbst aus und meldet nur, statt zu ändern. Deckt Interpretationsfehler und wiederholte falsche Annahmen auf, die kein eigener Test findet, weil Test und Code aus derselben Auslegung stammen. Nutze diesen Skill immer, wenn ein Test, ein Check oder eine Sie läuft NUR auf Anforderung des Nutzers: wenn ein Vorgang das Label `Gegenlese` trägt oder er im Gespräch nach Gegenlese, Vier-Augen-Prinzip, externer Prüfung oder einem zweiten Agenten fragt. Nutze diesen Skill in genau diesen Fällen — und sonst nicht, auch nicht bei einem neuen Test oder einem großen Pull Request. Gilt für jedes Softwareprojekt.
git-branch-strategie
Verbindlicher Feature-Branch-Workflow für alle Softwareprojekte: von main abzweigen und nach main zurück, Aktualisieren ausnahmslos per Rebase, Sonderfall blockierter Issues, ein gemeinsamer Branch für hierarchische Issues, Aufräumen der Historie vor dem Pull Request, Rebase-Merge gegen Merge-Commit, eigenständiges Lösen von Merge-Konflikten — und mit welchem GitHub-Konto gearbeitet wird. Nutze diesen Skill, bevor du einen Branch anlegst, committest, pushst, einen Pull Request erstellst oder mergst; wenn zu klären ist, wie ein Pull Request nach main kommt; wenn ein Branch länger offen ist; bei jedem Merge-Konflikt; und immer, wenn zwei Änderungen voneinander abhängen. Ebenso bei Fragen nach Branch-Namen, Merge-Reihenfolge, Commit-Identität oder dem zu verwendenden GitHub-Konto.
github-issue-workflow
Arbeitet GitHub-Issues eigenständig ab und hält die technische Kommunikation im Issue statt im Chat: Reihenfolge nach Abhängigkeit und Priorität, Umsetzung im Feature-Branch, Dokumentation im Issue, Pull Request — gemergt wird ausschließlich vom Nutzer. Offene Fragen werden zu Labels „Rückfrage" oder „Entscheidung". Nutze diesen Skill, sobald Issues abgearbeitet werden sollen („arbeite die Einarbeiten-Issues ab", „nimm dir Issue 12 vor", „schau ob was zu tun ist"), wenn nach dem Stand offener Issues gefragt wird, wenn ein Issue in Code umgesetzt oder ein Bug untersucht werden soll, und wenn zu klären ist, welches Label, welcher Issue-Typ oder welche Priorität richtig ist. Ebenso, wenn neue Anforderungen erfasst werden — die laufen in diesen Projekten über Issues, nicht über den Chat. Gilt für jedes Softwareprojekt mit GitHub-Anbindung.
repo-hygiene
Entscheidet, was in ein Git-Repository gehört und was nicht, über eine Whitelist-.gitignore statt einer Blacklist — plus die Kontrollen vor dem ersten Commit (Zugangsdaten, personenbezogene Daten in Binärdateien, Zeilenenden) und das Vorgehen, wenn schon etwas Falsches im Repository gelandet ist. Nutze diesen Skill unbedingt, sobald es um `git init`, den ersten Commit, eine `.gitignore` oder `.gitattributes` oder das Veröffentlichen eines bestehenden lokalen Ordners auf GitHub/GitLab geht — und auch dann, wenn nur beiläufig gefragt wird, ob eine Datei, ein Ordner, eine Excel-/Word-Datei oder ein Testbericht „mit ins Repo soll". Ebenso bei jedem Commit, der Binärdateien, Office-Dokumente, Exporte oder Diagnoseausgaben enthält; wenn eine Datei entgegen der Erwartung nicht im Repository landet oder ignoriert wird; und dringend, wenn Zugangsdaten, Schlüssel oder personenbezogene Daten bereits committet oder gepusht wurden.
semver-und-releases
Versionsnummern nach Semantic Versioning und das Bauen von GitHub-Releases mit annotierten Tags und Download-Dateien. Regelt, wann MAJOR, MINOR oder PATCH steigt, wer das darf, wo die Version im Projekt steht und wie ein Release entsteht. Nutze diesen Skill, wenn der Nutzer „Release bauen" sagt oder ein Release, einen Tag, eine neue Version oder Release Notes verlangt; wenn zu entscheiden ist, ob eine Änderung MINOR oder PATCH ist; wenn eine Versionsnummer irgendwo im Projekt hochgezählt werden soll; und wenn ein Projekt noch gar keine Versionierung hat. Gilt für alle Softwareprojekte.
test-driven-development
Testgetriebenes Vorgehen als Voreinstellung für alle Softwareprojekte dieses Nutzers: erst den Test bauen und ihn rot nachweisen, dann die Funktionalität — immer zwei Runden, nie eine. Auch dann, wenn der Test in der eigenen Umgebung gar nicht ausgeführt werden kann; dann wird der Rot-Nachweis ausdrücklich angefordert. Enthält außerdem, wie eine bestehende Testsuite per Mutationstest auf ihre Wirksamkeit geprüft wird und wie man Tests baut, die nicht denselben blinden Fleck haben wie der Code. Nutze diesen Skill bei jeder neuen Funktion, bei jedem gemeldeten Fehler, bevor du eine Zeile Produktivcode schreibst, und wenn zu klären ist, ob ein bestehender Test überhaupt etwas prüft.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.