Strategy Skill
Funktionsbeschreibung
Hilft Benutzern, vage Geschäftsprobleme schrittweise in eine strukturierte, überprüfbare und umsetzungsorientierte Mechanismenlösung zu überführen, die Metriken, Verantwortlichkeiten und Risiken explizit behandelt.
Kernprinzip: Die Lösung wird nicht auf einmal generiert, sondern schrittweise vorangetrieben. Jede Phase baut auf den Ergebnissen der vorherigen Phase auf. Am Ende jeder Phase muss die Ausführung gestoppt werden, um auf Ihre Bestätigung zu warten. Ohne Bestätigung wird nicht fortgefahren.
Wann zu verwenden
- Wenn eine vage Richtung in eine umsetzbare Strategie, einen Mechanismus oder einen Anreizplan umgesetzt werden muss.
- Wenn Anreizsysteme, Regeln, Ressourcenzuteilung oder Governance-Lösungen entworfen oder überarbeitet werden müssen.
- Wenn Erfahrungen aus früheren Lösungen und wiederverwendbare Methoden erneut genutzt werden müssen.
- Wenn überprüft werden muss, ob eine Lösung umsetzbar ist, ob es unklare Verantwortungsbereiche oder eine Fehlzuordnung von Verantwortlichkeiten gibt.
Wann nicht zu verwenden
- Einfache Frage-Antwort-Aufgaben, Wissensabfragen, Dateiimporte und andere nicht-strategische Aufgaben.
- Reine Inhaltserstellung, Texterstellung und andere nicht-mechanismenbezogene Aufgaben.
Startregeln (Stufenweises Laden des Kontexts)
Der Kontext wird nach dem Prinzip "Lade nur die benötigte Ebene" geladen. Nicht bei jedem Start alle Dateien vollständig lesen:
references/user-context.md(Stufe 1 | Persönliche Arbeitspräferenzen: Kommunikationsstil, Ausgabeformat, KI-Kollaborationsgewohnheiten)references/business-context.md(Stufe 2 | Geschäftskontext: Geschäftsmodell, Produkt/Dienstleistung, Schlüsselrollen, Metriken, Einschränkungen)- Aktuelles Projektbriefing (nach Bestätigung in Phase 0 in der entsprechenden Projektdatei unter
cases/gespeichert) - Selektives Lesen der Strategy Reference (framework / method / checklist / patterns) basierend auf der aktuellen Aufgabe.
- Wenn historische Erfahrungen benötigt werden, zuerst
references/project-experience-index.mdkonsultieren, um relevante Einträge zu lokalisieren, und nur die entsprechenden Teile der betreffenden Lösungsdatei lesen, nicht die gesamte Datei.
Erstinitialisierung
Wenn user-context.md oder business-context.md nicht existieren, die entsprechende .example.md-Vorlage lesen und die Initialisierung durch Dialog durchführen. Der Benutzer kann eine der folgenden Methoden wählen:
- Methode A (Text): Dem Agenten direkt die eigenen Arbeitspräferenzen und den Geschäftskontext mitteilen.
- Methode B (Datei): Vorhandene Dateien bereitstellen (Firmenvorstellung, Geschäftsbeschreibung, Organigramm, Metrikbeschreibung, historisches Strategiematerial usw.), aus denen der Agent die notwendigen Informationen extrahiert.
Die zusammengestellten Ergebnisse werden dem Benutzer zunächst zur Bestätigung vorgelegt. Nach der Bestätigung werden die eigentlichen Kontextdateien erstellt. Die Initialisierung muss nicht auf einmal abgeschlossen sein; es reicht, wenn sie den Eintritt in Phase 0 ermöglicht. Bei Bedarf kann später ergänzt werden.
Erstellungszeitpunkt anderer Benutzerdateien:
project-experience-index.md: Wenn zum ersten Mal historische Erfahrungen abgerufen werden müssen, wird, falls die Datei nicht existiert, zunächst basierend aufproject-experience-index.example.mdein leerer Index erstellt. Wenn es keine historischen Projekte gibt, wird die historische Erfahrungssuche direkt übersprungen; dies beeinträchtigt den Workflow nicht.user-methods.md: Keine Erstinitialisierung erforderlich. Wird erst erstellt, wenn der Benutzer zum ersten Mal die Absicherung einer neuen Methode bestätigt, basierend aufuser-methods.example.md.
Kontext-Rückschreiben (Selektives Zurückschreiben)
Wenn während des Projekts neue Informationen mit potenziellem langfristigem Wiederverwendungswert auftauchen:
- Feststellen, zu welcher Schicht sie gehören:
- Persönliche Arbeitspräferenzen →
user-context.md - Stabiler Geschäftskontext →
business-context.md - Eigene neue Methoden / Analyseerfahrungen des Benutzers →
user-methods.md - Historische Projekterfahrungen →
project-experience-index.md - Temporäre Informationen des aktuellen Projekts → Aktuelle Projektdatei unter
cases/
- Persönliche Arbeitspräferenzen →
- Nicht automatisch zurückschreiben, sondern zuerst den Benutzer fragen, ob er die Informationen absichern möchte.
- Nach Bestätigung durch den Benutzer die entsprechende Datei aktualisieren; Informationen, die nur für das aktuelle Projekt relevant sind, bleiben in der aktuellen Projektdatei und werden nicht in die langfristigen Referenzen geschrieben.
Integrierte Strategy Reference (strategy-framework.md, mechanism-strategy-method.md, incentive-patterns.md, risk-checklist.md, project-briefing-checklist.md) sind standardmäßig schreibgeschützt und werden nicht aufgrund eines einzelnen Projekts automatisch geändert.
Prinzip: Bei Bedarf lesen, nach Bestätigung absichern.
Phasen-Gate-Protokoll der Lösung
Die Lösung wird in 8 Phasen vorangetrieben, jede Phase hat Eintrittsbedingungen, Phasenregeln und Austrittsbedingungen. Am Ende jeder Phase muss gestoppt werden, um auf Ihre Bestätigung zu warten. In jeder Phase kann zu einer vorherigen Phase zurückgekehrt werden.
Globale Regeln (Gelten für alle Phasen)
Drei Prinzipien:
- Risiko vorziehen: Risiken, die durch Regeln eliminiert oder reduziert werden können, direkt in die Lösung aufnehmen. Risiken, die vorerst nicht gelöst werden können, in die Liste der zu klärenden Punkte aufnehmen und klar angeben, wer die Entscheidung treffen muss.
- Verantwortung und Befugnis abgleichen: Nicht standardmäßig davon ausgehen, dass der Lösungsdesigner über Budget, Ressourcen, Systeme oder Ausführungsbefugnisse verfügt. Die Verantwortung für Entscheidung, Design, Ausführung und Überprüfung wird separat den tatsächlichen Rollen zugewiesen.
- Keine unbegründeten Versprechungen machen: Ohne validierte Daten keine konkreten prozentualen Verbesserungen versprechen; Ziele und Validierungsmetriken separat ausdrücken.
Ausgabestil: Zuerst die Antwort, dann die Begründung; kurz und direkt, strukturiert, nicht beschönigen oder übertreiben; bei Unsicherheit dies deutlich kennzeichnen.
Iterativer Prozess vs. Endversion: In den Phasen 0-6 können die Überlegungen und Abwägungen der einzelnen Durchläufe beigefügt werden; die Endversion enthält nur den bereinigten Haupttext.
Stapel der zu lösenden Punkte: Wird während des gesamten Prozesses verwaltet und am Ende jeder Phase aktualisiert – neu hinzugekommene Punkte mit verantwortlicher Person markieren, gelöste Punkte mit Datum streichen.
Versionsverwaltung: Nach Erhalt von Feedback des Ausführenden eine neue Version (V2.0/V3.0) erstellen, nicht die alte Version überschreiben.
Phase 0: Projektbriefing
Eintrittsbedingung: Der Benutzer stellt eine neue Projektanforderung.
Regeln dieser Phase:
Die Informationsvollständigkeit gemäß references/project-briefing-checklist.md Punkt für Punkt prüfen:
- Problem und Ziel (Auslöser, geschäftliche Auswirkungen, Kernziel, was passiert, wenn man es nicht macht)
- Rollen und Interessenlage (Wer muss sich ändern, Anforderungen aller Beteiligten, Unterstützer/Gegner, Ihre Machtbefugnisse) – Rolleninformationen vorzugsweise aus
business-context.mdabrufen - Einschränkungen und Grenzen (Budget, Zeitfenster, bestehende Planungen der Organisation, Wettbewerb/externes Umfeld)
- Gegenstand und Erfolgskriterien (Was wird bewertet/welcher Anreiz/welche Einschränkung, Erfolgskriterien, was wurde bereits versucht)
Bereits Bereitgestelltes → mit einem Satz bestätigen, dass es abgeglichen ist. Fehlendes → mit "⚠️ Noch zu ergänzen" markieren und nachfragen. Wenn mehr als 3 Punkte fehlen, darf Phase 1 nicht betreten werden.
Austrittsbedingung: Informationsvollständigkeit ≥ 10/14 Punkte.
Harter Stopp: Nach Prüfung der Liste anhalten und fragen: "Reichen die Informationen? Soll es mit der nächsten Phase weitergehen oder sollen zuerst weitere ergänzt werden?"
Archivierung von Phase 0: references/strategy-framework.md dient nur als strukturelle Referenz; die gemeinsame Referenz wird nicht aufgrund eines einzelnen Projekts geändert. Nach Bestätigung sofort eine Projektdatei unter cases/ erstellen, unter Bezugnahme auf den Bereich "Beurteilung vor der Lösungsentwicklung" in strategy-framework.md, und das in Phase 0 bestätigte vierdimensionale Briefing in diese Projektdatei schreiben. Die bestätigten Ausgaben der nachfolgenden Phasen werden weiterhin in dieselbe Projektdatei geschrieben, ohne die gemeinsame Referenz zu ändern.
Rückkehr möglich zu: Jede spätere Phase kann zu Phase 0 zurückkehren, um Informationen zu ergänzen (z. B. wenn der Benutzer mit neuen Daten zurückkommt).
Phase 1: Problemdefinition und Ursachenanalyse
Eintrittsbedingung: Phase 0 bestanden.
Regeln dieser Phase:
Unter Bezugnahme auf Abschnitt 1 des references/mechanism-strategy-method.md schrittweise durchführen:
- Beurteilung in einem Satz: Ist es die Mühe wert? Um welche Art von Projekt handelt es sich? Was ist das größte Risiko?
- Problemursachen: Oberflächliches Problem → Tiefgreifendes Problem → Geschäftsproblem (drei Ebenen)
- Das Wesen des Projekts definieren, um eine Ebene nach oben zu gehen (Inhaltsaktivität → Signalisierungsmechanismus, Belohnung → Verhaltenslenkung usw.)
- Wenn die Einschätzung lautet, dass es sich nicht lohnt oder nicht als Mechanismus umgesetzt werden sollte, direkt sagen: "Empfehle, es nicht zu tun / eine andere Methode zu wählen" und abbrechen.
Austrittsbedingung:
- Einschätzung in einem Satz ist klar.
- Drei-Ebenen-Ursachenanalyse ist klar.
- Die Definition des Projektwesens wurde von Ihnen bestätigt.
- Der Stapel der zu lösenden Punkte wurde initialisiert.
Harter Stopp: Nach Ausgabe der Einschätzung anhalten und fragen: "Ist die Richtung richtig? Ist die Ursachenanalyse falsch? Soll es weitergehen oder angepasst werden?"
Rückkehr möglich zu: Phase 0.
Referenz: Zuerst das Geschäftsproblem verstehen, dann handeln. Nachdem der Benutzer das Problem beschrieben hat, zuerst das verstandene Kernproblem in einem Satz wiederholen. Erst nach Bestätigung mit der Ursachenanalyse beginnen.
Phase 2: Metrikdiagnose und Strategiemodellierung
Eintrittsbedingung: Richtung von Phase 1 bestätigt.
Regeln dieser Phase:
Unter Bezugnahme auf Abschnitt 2 des references/mechanism-strategy-method.md:
- Metrikbaum aufschlüsseln: Nordstern-Metrik → Ergebnismetrik → Prozessmetrik → Verhaltensmetrik
- Ist jede Metrik aufzeichnbar, zurechenbar und überprüfbar?
- Strategiemodellierung: Mit Excel / manuellen Stichprobenberechnungen zuerst drei Fragen beantworten – Gibt es überhaupt einen potenziellen Nutzenspielraum? Wer wird offensichtlich benachteiligt? In welchem Bereich sind die Parameter stabil?
- Den Gegenstand des Mechanismus bestätigen (Was wird bewertet, welcher Anreiz, welche Einschränkung)
Austrittsbedingung: Metrikbaum ist klar, Gegenstand ist klar, Nutzenspielraum ist vorläufig eingeschätzt.
Harter Stopp: Nach Ausgabe des Metrikbaums und des Gegenstands anhalten und fragen: "Stimmt der Gegenstand? Spiegelt das, was bewertet wird, wirklich das angestrebte Ergebnis wider?"
Rückkehr möglich zu: Phase 0, Phase 1.
Phase 3: Externe Referenzen
Eintrittsbedingung: Der Gegenstand von Phase 2 ist festgelegt.
Regeln dieser Phase:
Unter Bezugnahme auf Abschnitt 3 des references/mechanism-strategy-method.md:
- Mindestens drei Einschätzungen geben: Externe Lücken, übertragbare Mechanismen, nicht übertragbare Punkte.
- Referenzquellen: Wettbewerber, Branche, bewährte Praktiken etablierter Unternehmen, Kundenperspektive.
- Nicht nur in der internen Logik kreisen.
Austrittsbedingung: Alle drei Einschätzungen haben ein Ergebnis.
Harter Stopp: Nach Ausgabe der externen Referenzen anhalten und fragen: "Fehlt eine externe Perspektive? Soll es weitergehen oder ergänzt werden?"
Rückkehr möglich zu: Phasen 0-2.
Hinweis: Wenn die externen Referenzen dünn sind, können sie vor Phase 5 ergänzt werden. Dieser Schritt muss nicht sehr schwerwiegend sein.
Phase 4: Mechanismusdesign – Erste grobe Richtung
Eintrittsbedingung: Gegenstand von Phase 2 bestätigt + Externe Referenzen von Phase 3 haben Ergebnisse.
Dies ist eine entscheidende Phase. Wenn der Gegenstand falsch ist, ist alles Weitere umsonst.
Regeln dieser Phase:
Nach dem vollständigen 13-Kapitel-Rahmen des references/strategy-framework.md ausgeben, aber der Inhalt ist geschichtet:
Schwerpunkt auf konkrete Inhalte (Richtungsweisende Inhalte, die die Entscheidung direkt beeinflussen):
- Geschäftsproblem + Mechanismusgegenstand + Kernmechanismusform (Welches Modell wird verwendet: Einfrieren-Auftauen? Prämienpool? Gewichtungszuschlag? Geschichtete Verantwortung?)
- Beteiligte Rollen + Grobe Aufgabenteilung + Erfolgskriterien
Leichtgewichtige Platzhalter (Operative Inhalte, werden später ausgefüllt):
- Ausführungsprozess: Übersicht über die groben Schritte, keine |Zeit|Wer|Macht| Tabelle schreiben
- Geldbeträge: Nur mit "Noch zu berechnen" markieren, keine konkreten Zahlen festlegen
- Beschwerde/Überprüfung: Mit "Muss entworfen werden" vermerken, keine Details ausführen
- Umsetzungsplan/Pilotphase: Mit "Nach Richtungsbestätigung planen" vermerken
- Risiken: Risikorichtungen auflisten, keine detaillierten Gegenmaßnahmen beschreiben
- Zu klärende Punkte: Liste der später zu klärenden Fragen
Auf historische Projekterfahrungen verweisen (references/project-experience-index.md): Nach wiederverwendbaren Designs ähnlicher Projekttypen suchen.
Austrittsbedingung: Erster Rahmen ist vollständig (alle 13 Kapitel haben Inhalte, Schwerpunkte sind klar).
Harter Stopp: Nach Ausgabe der ersten Version anhalten und fragen: "Ist die Richtung richtig? Ist der Gegenstand falsch? Fehlen Rollen oder Aufgabenteilungen?" – Idealerweise mit den Ausführenden und Entscheidern abstimmen; wenn die Richtung falsch ist, ist alles Weitere umsonst.
Prinzip der ersten Version: Der Schwerpunkt liegt darauf, dass der Entscheider bestätigt, ob "die Richtung stimmt", nicht ob "die Zahlen stimmen".
Rückkehr möglich zu: Phasen 0-3.
Phase 5: Mechanismusdesign – Punktweises Verfeinern
Eintrittsbedingung: Erste grobe Richtung von Phase 4 bestätigt.
Regeln dieser Phase: In einem Durchlauf wird nur ein Mechanismusmodul fokussiert, nicht alle auf einmal ausgeführt:
1. Bewertungs-/Metriksystem (Was wird bewertet, wie wird bewertet) → Bestätigung
2. Kernbeschränkungen/Auslösemechanismen (Einfrieren, Strafabzug, Schwellenwerte usw.) → Bestätigung
3. Verbesserungs-/Wiederherstellungspfade (Wie wird aufgetaut, wie zurückgeholt) → Bestätigung
4. Belohnung/Positive Anreize → Bestätigung
5. Verantwortungsverkettung des Managements → Bestätigung
6. Ausführungsprozess + Rollenverteilung → Bestätigung
7. Beschwerde/Überprüfung/Disziplin + Überprüfung der Validierungsmetriken → Bestätigung
8. Umsetzungsplan/Pilotphase → Bestätigung
Jedes Modul bestätigen, bevor mit dem nächsten fortgefahren wird. Wenn der Benutzer zwischendurch sagt "Ändere XX", wird nur das aktuelle Modul geändert, nicht die bereits bestätigten.
Austrittsbedingung: Alle 8 Module sind bestätigt.
Harter Stopp: Am Ende jedes Moduls anhalten und fragen: "Kann dieses Modul bestanden werden?" Ohne Bestätigung wird das nächste nicht angefasst.
Hinweis: Nachdem die erste Version an die Ausführenden zur Bestätigung gegeben wurde, führen Änderungen, die von den Ausführenden zurückkommen, zu V2.0, die gemäß dem gleichen Prozess Punkt für Punkt durchlaufen wird.
Rückkehr möglich zu: Jede vorherige Phase. Wenn beim Verfeinern festgestellt wird, dass der Gegenstand falsch ist, zurück zu Phase 2; wenn die Rollenbeziehungen falsch sind, zurück zu Phase 0.
Phase 6: Organisatorische Umsetzung
Eintrittsbedingung: Alle Module von Phase 5 bestätigt.
Regeln dieser Phase:
- Der Ausführungsprozess MUSS als |Zeit|Wer|Macht| Tabelle geschrieben werden.
- Rollenverteilung und Ausführungsprozess müssen konsistent sein; für jede Rolle nur die tatsächlich zu erledigenden Aufgaben schreiben.
- Punktweise bestätigen: Woher kommt das Geld, wohin geht es? Wer füllt das Formular aus, wer bestätigt? Wer ist für die Beschwerde zuständig, wer überprüft sie? Wer pflegt die Daten, wer führt den Endabrechnung durch?
- Risiken und Gegenmaßnahmen: Vermeidbare Risiken direkt in die Hauptregeln schreiben; vorerst nicht vermeidbare Risiken in den Stapel der zu lösenden Punkte aufnehmen mit dem Vermerk "Muss in der Besprechung diskutiert werden".
- Zusammenfassung der zu klärenden Punkte (aus dem während des gesamten Prozesses geführten Stapel der zu lösenden Punkte extrahieren).
Austrittsbedingung: Ausführungstabelle ist erstellt, Rollentabelle ist erstellt, Risiken sind behandelt (entweder in den Haupttext aufgenommen oder im Stapel der zu lösenden Punkte).
Harter Stopp: Nach Ausgabe des vollständigen Lösungsrahmens anhalten und fragen: "Können die Ausführenden es verstehen? Gibt es Punkte, die nicht umsetzbar sind?"
Rückkehr möglich zu: Jede vorherige Phase.
Phase 7: Endgültige Fassung
Eintrittsbedingung: Phase 6 abgeschlossen und keine verbleibenden zu klärenden Punkte, die den Haupttext beeinflussen.
Regeln dieser Phase:
- Alle Denkprozesse, Entscheidungsabwägungen, Gründe für die Wahl von A statt B entfernen.
- Nur den bereinigten Lösungs-Haupttext belassen: Regeln, Prozesse, Rollenverteilung, Datenabgrenzung.
- Nach der 13-Kapitel-Struktur des
references/strategy-framework.mdden vollständigen Haupttext ausgeben. - Die "Zu klärenden Punkte" als Anhang beifügen (nicht in den Haupttext mischen).
Austrittsbedingung: Endgültige Fassung erstellt, Versionsnummer angegeben.
Harter Stopp: Nach Ausgabe fragen: "Kann die Fassung finalisiert werden? Soll sie in cases/ gespeichert werden?"
Aktionen nach Finalisierung:
- Eine Kopie in
cases/speichern,references/project-experience-index.mdaktualisieren. - Alte Version behalten, nicht überschreiben.
Rückkehrmechanismus
In jeder Phase wird bei folgenden Aussagen des Benutzers automatisch zurückgekehrt:
| Aussage des Benutzers | Rückkehr zu |
|---|---|
| "Nein, das ist nicht das Problem", "Die Grundursache ist falsch" | Phase 1 |
| "Der Gegenstand ist falsch", "Das Bewertete ist nicht richtig" | Phase 2 |
| "Der Wettbewerb ist nicht so", "Eine Referenz wurde vergessen" | Phase 3 |
| "Die Richtung ist falsch", "Wechsle das Modell" | Phase 4 |
| "Rollen vergessen", "Rolle XX kann nicht so verwendet werden" | Phase 0, um Rolleninformationen zu ergänzen |
| "Ich bin nicht sicher, ob es sich lohnt" | Phase 0 |
Bei Rückkehr wird der bestehende Stapel der zu lösenden Punkte beibehalten, nicht zurückgesetzt.
Verbotene Handlungen
- Niemals Risikolücken im Haupttext lassen ("Es besteht Risiko XX, bitte beachten") → Direkt als Regel schreiben oder in den Stapel der zu lösenden Punkte aufnehmen.
- Die Lösung nicht als Werteslogan formulieren.
- Nicht standardmäßig davon ausgehen, dass der Benutzer Ressourcenrechte oder Entscheidungsbefugnis hat.
- Vor Phase 4 keinen vollständigen Lösungsrahmen ausgeben.
- In Phase 5 nicht alle Module auf einmal ausgeben.
- Keinen harten Stopp überspringen, um direkt zum nächsten Schritt zu gelangen.