tenngoxars/skill-synergy

Skill Synergy — Schlichtungsregeln

Eine Autorität dafür, welcher Skill gewinnt, wenn mehrere feuern. Lies dies, wenn zwei oder mehr Skills plausibel auf die aktuelle Aufgabe zutreffen.

Nutzungshinweis: Dieser Skill ist das detaillierte Regelwerk. Eine kompakte Charta (für Always-on-Setups empfohlen) liegt im Repo-Root als AGENTS.md.template; kopiere sie in AGENTS.md, damit die Kernregel bei jeder Sitzung geladen wird. Dieser Skill ist die On-Demand-Referenz.

Die Kernregel

Workflow-Skills (was zu tun ist) haben Vorrang vor Mode-Skills (wie zu sprechen/schreiben) bei der selben Aufgabe. Der Mode-Skill passt sich an; der Workflow-Skill wird niemals geschwächt.

Alles Folgende ist eine Anwendung dieser Regel. Falls ein spezifischer Fall nicht aufgeführt ist, wende die Kernregel an und sage dies.

Workflow-vs-Workflow-Schlichtung

Zwei oder mehr Workflow-Skills können beide plausibel auf dieselbe Aufgabe passen. Wähle nach dieser Leiter, in dieser Reihenfolge:

1. Explizite Absicht gewinnt. Wenn der Benutzer den Aufgabentyp genannt hat (Review, Test, Design, Plan...), führt der Skill für diesen Typ. Kein Abwägen.
2. Umfang entscheidet. Eine einzelne Änderung (ein Diff, eine Funktion, eine Datei) nimmt den leichteren, günstigeren Skill; eine übergreifende Änderung (Architektur, Multi-Datei-Refactoring, neues System) nimmt den tiefergehenden Skill.
3. Lebenszyklus-Reihenfolge. Planen → Bauen → Verifizieren ist die Standard- Sequenz. Wenn Skills Phasen eines Vorhabens sind (Design, dann Implementieren, dann Review), führe sie in dieser Reihenfolge aus, anstatt einen auszuwählen.
4. Komponieren statt Auswählen. Wenn zwei Skills sequenzielle Phasen sind, führe beide in Reihenfolge aus und gib die Reihenfolge explizit an ("TDD zuerst, dann Review").
5. Immer noch zweideutig? Frage. Gib eine einzeilige Empfehlung und lass den Benutzer wählen. Wähle niemals stillschweigend einen Workflow-Skill – der falsche verschwendet eine ganze Aufgabe, nicht nur eine Antwort.

Skill-Taxonomie

Klassifiziere jeden installierten Skill vor der Schlichtung:

• Workflow-Skills – bestimmen was getan wird: Review, Test, Design, Recherche, Schreiben, Refactoring, Planung. Sie liefern Ergebnisse.
• Mode-Skills – bestimmen wie der Agent klingt oder wie viel er schreibt: Kompression, Ausführlichkeit, Stil, Kürze. Sie erzeugen nichts von sich aus.
• Router-Skills – wählen aus, welcher Workflow läuft (optional). Sie sollten niemals von einem Mode-Skill überschrieben werden.

Wenn ein Mode-Skill das Ergebnis eines Workflow-Skills ändern würde (Bericht, Dokument, Commit-Nachricht, PR-Body), gibt der Mode-Skill nach. Wenn ein Workflow-Skill und ein Mode-Skill beide feuern und die Ausgabe des Workflow-Skills das Ergebnis ist, gibt der Mode-Skill nach.

Diese Charta hat Vorrang vor Skill-Selbstbeschreibungen. Die Frontmatter eines Skills kann Auto-Trigger auf einen breiten Ausdruck behaupten (z. B. "auto-triggers on review"). Solche Behauptungen werden hier außer Kraft gesetzt: Das Routing folgt der Disambiguierung dieser Charta, nicht dem eigenen Trigger-Anspruch des Skills. Wenn ein Skill einen Trigger beansprucht, den diese Charta woanders zuweist, gewinnt die Charta.

Prioritätsmatrix (eigene Skills eintragen)

Ersetze die unten stehenden beispielhaften Skill-Namen durch die tatsächlich in deiner Umgebung installierten Skills. Die Zeilen sind geordnet nach der Häufigkeit, mit der der Konflikt in der Praxis auftritt.

Aufgabe	Führt (Workflow)	Gibt nach	Verhalten
UI-Design / Verfeinerung / visuelle Kritik	z. B. dein Design-Skill	z. B. dein Minimal-Code-Skill	Design führt; Minimal-Code mit reduzierter Stärke (keine Aufblähung, aber kein YAGNI-Veto gegen Design-Handwerk)
Deep Code Review (Standards + Spezifikation)	z. B. dein Full-Review-Skill	z. B. dein Kompressions-Skill	Vollständiger Bericht in normaler Prosa; Kompression aus, es sei denn, der Benutzer bittet um knappes Feedback
Über-Engineering-Audit	z. B. dein löschfokussierter Review-Skill	z. B. dein Full-Review-Skill	Eindimensionaler, löschfokussierter Durchlauf; vollständigen Bericht überspringen
Schnelles knappes PR-Feedback	z. B. dein Terse-Comment-Skill	—	Nur, wenn der Benutzer explizit nach komprimierten Kommentaren gefragt hat
Plan/Idee einem Stresstest unterziehen	z. B. dein Interview/Grill-Skill	z. B. dein Kompressions-Skill	Interview in normaler Prosa; komprimiertes Grübeln verliert seine Tiefe
Test-first Feature-Build	z. B. dein TDD-Skill + dein Minimal-Code-Skill	—	Kombination: Tests sind Validierung, niemals streichen; minimale Implementierung, die Rot-Grün besteht
Modul-/API-Design	z. B. dein Design-Docs-Skill	z. B. dein Minimal-Code-Skill	Designphase: Tiefe gewinnt. Implementierungsphase: Minimal-Code-Leiter gilt
Schreiben / Bearbeiten / Lehren	z. B. dein Schreib-Skill	z. B. dein Kompressions-Skill	Vollständige Ausdrucksweise erforderlich; Kompression aus
Recherche / Docs-Erfassung	z. B. dein Recherche-Skill	z. B. dein Kompressions-Skill	Ausgabedateien sind Ergebnisse; Kompression betrifft nur Chat, niemals Dateiinhalte
Jede Coding-Aufgabe, kein anderer Skill gefeuert	z. B. dein Minimal-Code-Skill	z. B. dein Kompressions-Skill	Minimal-Code in voller Stärke; Kompression nur auf Anfrage (ihre Kosten pro Durchlauf überwiegen oft die Einsparungen bei Code-schwerer Arbeit)

Trigger-Disambiguierung

Wenn mehrere Skills ein Trigger-Wort teilen, leite nach Absicht, nicht danach, welcher Skill zuerst gematcht hat:

• "review this" → standardmäßig vollständiges Review. Der löschfokussierte Review nur, wenn der Benutzer "over-engineered" / "too much code" sagt. Der Terse-Comment-Review nur, wenn der Benutzer nach komprimiertem Feedback fragt.
• "grill" / "interview me" → die zustandsbehaftete Variante (hinterlässt eine Doc-Spur), wenn eine Codebasis existiert; die zustandslose Variante, wenn eigenständig; die Batch-Variante, wenn der Benutzer alle Fragen auf einmal möchte.
• "handoff" → standardmäßig die dokumentenschreibende Variante; die Spawn-Background-Agent-Variante nur, wenn der Benutzer sofort einen Hintergrund-Agenten möchte.
• "make a plan/spec/tickets" → nach Artefakttyp leiten: Spec, Tickets, PRD, Issues, Fragebogen.

Mode-Skill-Disziplin

1. Ein Mode-Skill bringt niemals das Ergebnis eines Workflow-Skills zum Schweigen. Er darf nur Chat-Prosa komprimieren. Berichte, Dateien, Commit-Nachrichten und PR-Bodies, die von Workflow-Skills geschrieben wurden, bleiben vollständig.
2. Die Validierungslinie des Minimal-Code-Skills hat drei Stufen: (1) Echte Validierung bleibt: Eingabevalidierung, Fehlerbehandlung für externe Abhängigkeiten, Sicherheit, Barrierefreiheit – niemals streichen. (2) Spekulative Verteidigung ist im Scope: Prüfungen, die nicht feuern können, defensive Wrapper für "was wäre wenn" – streiche sie, das ist der Job des Minimal-Code-Skills. (3) Tests und Aufgabendokumente folgen den expliziten Anforderungen des Benutzers: Der Minimal-Code-Skill verwendet niemals YAGNI, um Tests oder Docs zu streichen, die der Benutzer verlangt – aber Redundanz innerhalb von Tests, Over-Mocking und Aufblähung in Docs sind immer noch fair game.
3. Zwei Mode-Skills, die zusammen feuern (Compression + Minimal-Code): Minimal-Code regiert Code, Compression regiert Chat – aber nur, wenn die Sitzung Prosa-lastig ist; bei Code-lastigen Sitzungen sollte Compression aus oder mit reduzierter Stärke sein (sonst Netto-Token-Verlust).
4. Subagenten erben die Schlichtung. Wenn ein Subagent für eine Review- oder Recherche-Aufgabe gestartet wird, gib den Mode explizit in der Aufgabe an: "normale Prosa" oder "komprimierte Ausgabe". Lass es niemals implizit.

Kombinationen, die sich lohnen

• TDD-Skill + Minimal-Code-Skill – test-first, minimale Implementierung.
• Full Review, dann löschfokussierter Review auf demselben Diff – vollständiger Durchlauf, dann ein Löschdurchlauf.
• Interview-Skill + Memory-Compression-Skill – nach dem Interview die gesammelten Sitzungsnotizen komprimieren.
• Terse Commit-Message-Skill nach jedem abgeschlossenen Workflow-Skill – immer sicher.
• Router-Skill für Flow-Routing, dieser Skill für Mode-Schlichtung – der Router wählt den Weg, Synergy wählt den Gang.

Anpassen

Dieser Skill ist ein Rahmenwerk, keine Konfiguration. Um ihn zu deinem zu machen:

1. Ersetze jedes "z. B. dein X-Skill" in der Prioritätsmatrix durch die echten Skill-Namen in deiner Umgebung. Eine ausgefüllte Referenz mit gängigen öffentlichen Skills liegt in examples/example-config.md – kopiere sie und ersetze die Namen durch deine eigenen, anstatt die Vorlage von Grund auf neu auszufüllen.
2. Entferne Zeilen für Aufgabentypen, die du nie triffst.
3. Falls deine Umgebung eine globale Regeln-Datei (AGENTS.md oder Äquivalent) hat, kopiere die Kernregel hinein, damit jede Umgebung sie lädt.
4. Wenn ein neuer Konflikt auftritt, der nicht abgedeckt ist, klassifiziere beide Skills (Workflow oder Mode), wende die Kernregel an und füge eine Zeile hinzu.