drift-analyzer 2.9.2__tar.gz → 2.9.4__tar.gz

{drift_analyzer-2.9.2 → drift_analyzer-2.9.4}/.githooks/pre-push

@@ -29,6 +29,9 @@ if [ -z "$PYTHON_CMD" ]; then
 	exit 1
 fi
 
+GIT_DIR_PATH=$(git rev-parse --git-dir 2>/dev/null || echo ".git")
+LAST_SUCCESS_SHA_FILE="$GIT_DIR_PATH/.drift-prepush-last-success"
+
 # Escape hatches (export VAR=1 to skip a specific gate):
 # DRIFT_SKIP_CHANGELOG, DRIFT_SKIP_VERSION_BUMP,
 # DRIFT_SKIP_LOCKFILE, DRIFT_SKIP_DOCSTRING, DRIFT_SKIP_RISK_AUDIT
@@ -454,6 +457,37 @@ else
 	enforce_risk_audit_gate
 fi
 
+can_reuse_previous_local_ci_success=0
+current_head_sha=$(git rev-parse HEAD 2>/dev/null || true)
+if [ -n "$current_head_sha" ] && [ -f "$LAST_SUCCESS_SHA_FILE" ]; then
+	last_success_sha=$(cat "$LAST_SUCCESS_SHA_FILE" | tr -d '\r\n')
+	if [ "$last_success_sha" = "$current_head_sha" ]; then
+		all_updates_match_head=1
+		while IFS='|' read -r local_sha remote_sha; do
+			if [ -z "$local_sha" ] || [ -z "$remote_sha" ]; then
+				continue
+			fi
+			if [ "$local_sha" != "$current_head_sha" ]; then
+				all_updates_match_head=0
+				break
+			fi
+		done <<EOF
+$push_ref_updates
+EOF
+
+		if [ "$all_updates_match_head" -eq 1 ]; then
+			can_reuse_previous_local_ci_success=1
+		fi
+	fi
+fi
+
+if [ "$can_reuse_previous_local_ci_success" -eq 1 ]; then
+	echo ">>> [pre-push] Reusing successful local CI checks for unchanged commit $current_head_sha."
+	echo ">>> [pre-push] Gates were re-evaluated; expensive checks are skipped for this retry."
+	echo ">>> [pre-push] Push continues."
+	exit 0
+fi
+
 echo ">>> [pre-push] Starting local CI checks..."
 
 # Unset git context variables that git injects when running hooks.
@@ -499,4 +533,8 @@ fi
 echo ">>> [5/6] Running self-analysis..."
 drift analyze --repo . --format json --exit-zero > /dev/null
 
+if [ -n "$current_head_sha" ]; then
+	printf "%s\n" "$current_head_sha" > "$LAST_SUCCESS_SHA_FILE"
+fi
+
 echo ">>> [pre-push] All checks passed. Push continues."

{drift_analyzer-2.9.2 → drift_analyzer-2.9.4}/.github/labels.yml

@@ -10,6 +10,10 @@
   color: "0e8a16"
   description: Extra attention is needed
 
+- name: claimed
+  color: "0E8A16"
+  description: Issue is reserved for one confirmed contributor
+
 - name: needs reproduction
   color: "fbca04"
   description: A minimal reproducing case is needed before work can start

drift_analyzer-2.9.4/.github/prompts/drift-30-day-roi-plan.prompt.md

@@ -0,0 +1,178 @@
+---
+name: "Drift 30-Day ROI Plan"
+description: "Erstellt eine belastbare, priorisierte Liste von Drift-Verbesserungen mit maximalem ROI innerhalb von 30 Tagen. Fokus auf First-Run-Value, Adoption, Vertrauen und Handlungsfähigkeit."
+---
+
+# Drift 30-Day ROI Plan
+
+Du erstellst eine belastbare Priorisierung der Drift-Verbesserungen mit dem größten kombinierten Effekt auf First-Run-Value, Adoption, Vertrauen und Handlungsfähigkeit innerhalb von 30 Tagen.
+
+> **Pflicht:** Vor Ausführung dieses Prompts das Drift Policy Gate durchlaufen
+> (siehe `.github/prompts/_partials/konventionen.md` und `.github/instructions/drift-policy.instructions.md`).
+
+## Relevante Referenzen
+
+- **Instruction:** `.github/instructions/drift-policy.instructions.md`
+- **Bewertungssystem:** `.github/prompts/_partials/bewertungs-taxonomie.md`
+- **Issue-Filing:** `.github/prompts/_partials/issue-filing.md`
+- **Verwandte Prompts:** Alle anderen Drift-Review-Prompts (`drift-first-run-dropoffs.prompt.md`, `drift-actionability-review.prompt.md`, `drift-shareability-review.prompt.md`, `drift-positioning-review.prompt.md`, `drift-trust-review.prompt.md`, `drift-signal-clarity.prompt.md`, `drift-integration-priorities.prompt.md`, `drift-repo-segment-fit.prompt.md`, `drift-role-based-review.prompt.md`)
+- **Roadmap:** `ROADMAP.md`
+- **Backlog:** `.internal/BACKLOG.md`
+
+## Arbeitsmodus
+
+- Bewerte Maßnahmen nach Impact, Aufwand, Risiko, Abhängigkeiten und Zeit bis Wirkung.
+- Bevorzuge wenige hochwirksame Hebel statt vieler kleiner Optimierungen.
+- Keine Wunschliste — ein realistischer, umsetzbarer Plan.
+- Berücksichtige bestehende Roadmap und Backlog.
+
+## Ziel
+
+Liefere einen konkreten 30-Tage-Umsetzungsplan für Drift, der die wirksamsten Verbesserungen in der richtigen Reihenfolge priorisiert.
+
+## Erfolgskriterien
+
+Die Aufgabe ist erst abgeschlossen, wenn du beantworten kannst:
+- Welche Maßnahme hätte den höchsten Gesamthebel?
+- Welche Maßnahme wäre der beste kleine Einstieg?
+- Welche Maßnahme würde am meisten Vertrauen schaffen?
+- Welche Maßnahme würde Adoption am stärksten erhöhen?
+- Welche Maßnahme wäre verführerisch, aber aktuell falsch priorisiert?
+
+## Arbeitsregeln
+
+- Konsolidiere relevante Schwächen über Produkt, Output, Doku, Workflow, Vertrauen und Adoption.
+- Jede Maßnahme muss realistisch in 30 Tagen umsetzbar sein.
+- Falls Artefakte von Schwester-Prompts existieren, nutze sie als Input.
+- Keine allgemeinen Strategieempfehlungen — nur umsetzbare Drift-Maßnahmen.
+- Unsicherheiten explizit benennen.
+
+## Reasoning-Anforderungen
+
+### Spannungsfelder
+
+Navigiere aktiv folgende Spannungen — mache deine Abwägung transparent:
+
+- **Kurzfristiger Quick Win vs. langfristiger Strukturhebel:** Ein Quick Win zeigt sofort Wirkung, baut aber keine Substanz auf. Ein Strukturhebel braucht Zeit, wirkt aber nachhaltiger. Priorisiere bewusst.
+- **Vertrauen vs. Adoption:** Vertrauens-Maßnahmen (weniger FP, bessere Erklärungen) können Adoption verlangsamen (weniger aggressive Findings). Wie gehst du damit um?
+- **Sichtbare vs. fundamentale Verbesserung:** Nutzer bemerken UI-Improvements sofort, aber Backend-Fixes können langfristig wichtiger sein. Wie balancierst du wahrgenommenen vs. realen Fortschritt?
+
+### Vor-Schlussfolgerungs-Checks
+
+Bevor du eine Maßnahme in den 30-Tage-Plan aufnimmst:
+- Ist sie wirklich in 30 Tagen umsetzbar — oder sagst du dir „bestimmt machbar“ ohne echte Aufwandsschätzung?
+- Welche versteckten Abhängigkeiten oder Vorarbeit erfordert die Maßnahme?
+- Ist die erwartete Wirkung ein messbares Ergebnis oder nur ein gutes Gefühl?
+
+### Konfidenz-Kalibrierung
+
+Gib für den Gesamtplan an:
+- **Plan-Konfidenz:** hoch / mittel / niedrig — dass der Plan als Ganzes umsetzbar und wirksam ist
+- **Schwächstes Glied:** Welche einzelne Maßnahme hat die niedrigste Konfidenz und warum?
+- **Plan B:** Was wäre der Kern-3-Maßnahmen-Plan, falls die Hälfte der Maßnahmen scheitert?
+
+### Fehlerschluss-Wächter
+
+Prüfe aktiv gegen:
+- **Planungs-Optimismus:** Du planst als KI ohne Kontextwechsel, Meetings, Debugging und Unvorhergesehenes. Puffere realistisch.
+- **Impact-Überschätzung:** „Verbessert Adoption um X%“ ist nicht messbar. Formuliere konkrete, beobachtbare Erfolgskriterien.
+- **Vollständigkeits-Bias:** Ein 30-Tage-Plan mit 15 Maßnahmen ist kein Plan, sondern eine Überforderung. Weniger Maßnahmen, dafür tiefer durchdacht.
+- **Recency Bias:** Priorisiere nicht nur, was dir gerade einfällt, sondern prüfe gegen die existierende Roadmap und den Backlog.
+
+## Bewertungs-Labels
+
+Verwende ausschließlich Labels aus `.github/prompts/_partials/bewertungs-taxonomie.md`:
+
+- **Ergebnis-Bewertung:** `pass` / `review` / `fail`
+- **Risiko-Level:** `low` / `medium` / `high` / `critical`
+
+## Artefakte
+
+Erstelle Artefakte unter `work_artifacts/roi_30_day_plan_<YYYY-MM-DD>/`:
+
+1. `summary.md` — Gesamtbewertung
+2. `ranked_initiatives.md` — Bewertete und geordnete Maßnahmen
+3. `30_day_plan.md` — Konkreter Umsetzungsplan
+
+## Workflow
+
+### Phase 1: Schwächen konsolidieren
+
+Sammle Drift-Verbesserungspotenziale aus:
+- eigener Analyse von Produkt, CLI, Output, Doku, MCP
+- vorhandenen `work_artifacts/` von Schwester-Prompts (falls verfügbar)
+- `ROADMAP.md` und `.internal/BACKLOG.md`
+- eigener Nutzungserfahrung
+
+### Phase 2: Maßnahmen definieren
+
+Erstelle eine Liste von 10 bis 15 realistischen Maßnahmen.
+
+Für jede Maßnahme:
+- Beschreibung
+- Zielgröße: First-Run-Value / Adoption / Vertrauen / Handlungsfähigkeit
+- Art: Produktarbeit / CLI / Output / MCP / Doku / Integration / Distribution
+
+### Phase 3: Scoring
+
+Bewerte jede Maßnahme in `ranked_initiatives.md`:
+
+| Maßnahme | Zielgröße | Impact (1–5) | Aufwand (1–5) | Risiko (1–5) | Abhängigkeiten | Zeit bis Wirkung | Score | Kategorie |
+|----------|----------|-------------|--------------|-------------|---------------|-----------------|-------|-----------|
+| | | | | | | | | Quick Win / Mittelfristiger Hebel / Strategische Wette |
+
+Score-Formel: `(Impact × 2) / (Aufwand + Risiko)`
+
+### Phase 4: Reihenfolge und Abhängigkeiten
+
+Ordne die Maßnahmen in eine realistische 30-Tage-Reihenfolge:
+- Woche 1: Quick Wins mit sofortiger Wirkung
+- Woche 2: Mittelfristige Hebel aufsetzen
+- Woche 3: Größere Verbesserungen umsetzen
+- Woche 4: Verfeinern, validieren, abschließen
+
+Dokumentiere Abhängigkeiten zwischen Maßnahmen.
+
+### Phase 5: 30-Tage-Plan
+
+Erstelle `30_day_plan.md`:
+
+```
+## Woche 1: [Fokus]
+- [ ] Maßnahme A — [Kurzbeschreibung]
+- [ ] Maßnahme B — [Kurzbeschreibung]
+
+## Woche 2: [Fokus]
+- [ ] Maßnahme C — [Kurzbeschreibung]
+...
+
+## Woche 3: [Fokus]
+...
+
+## Woche 4: [Fokus]
+...
+```
+
+### Phase 6: Negativfilter
+
+Dokumentiere explizit:
+- Maßnahmen, die verführerisch, aber aktuell falsch priorisiert wären
+- Maßnahmen, die mehr Aufwand als Wirkung erzeugen
+- Maßnahmen, die Drift komplexer machen, ohne Kernwert zu steigern
+
+## Abschlussentscheidung
+
+Liefere:
+- den besten Quick Win
+- den stärksten Vertrauenshebel
+- den stärksten Adoptionshebel
+- die verführerische, aber aktuell falsche Priorität
+
+Zusätzlich:
+1. **Steelman der Nicht-Handlung:** Formuliere das stärkste Argument dafür, in den nächsten 30 Tagen überhaupt nichts an den hier identifizierten Punkten zu ändern und stattdessen nur Kernentwicklung zu betreiben.
+2. **Falsifikation:** Was wäre nach 30 Tagen beobachtbar, wenn der Plan gescheitert ist? Definiere konkrete Failure-Kriterien.
+3. **Sequenz-Sensitivität:** Wie stark ändert sich das Gesamtergebnis, wenn du die Reihenfolge der Maßnahmen umkehrst? Sind Reihenfolge-Abhängigkeiten real oder kosmetisch?
+4. **Konfidenz-Statement:** Wie sicher bist du, dass deine Top-3-Maßnahmen die richtigen sind? Was fehlt dir an Information?
+
+Beantworte abschließend:
+Wenn Drift in den nächsten 30 Tagen nur 3 Dinge umsetzen dürfte, welche wären das und warum?

{drift_analyzer-2.9.2 → drift_analyzer-2.9.4}/.github/prompts/drift-actionability-review.prompt.md

@@ -45,6 +45,37 @@ Die Aufgabe ist erst abgeschlossen, wenn du beantworten kannst:
 - Analysiere echte Finding-Texte auf Klarheit, Priorisierung und Next-Step-Qualität.
 - Keine allgemeinen Schreibtipps — nur Drift-spezifische Output-Verbesserungen.
 
+## Reasoning-Anforderungen
+
+### Spannungsfelder
+
+Navigiere aktiv folgende Spannungen — mache deine Abwägung transparent:
+
+- **Diagnosetiefe vs. Handlungsdruck:** Je tiefer die Analyse, desto weniger klar oft der nächste Schritt. Wo endet Diagnose und wo beginnt Handlungsfähigkeit?
+- **Allgemeingültigkeit vs. Kontextspezifik:** Eine universelle Empfehlung trifft nie ganz. Eine kontextspezifische ist nicht portabel. Wo ist der Optimalpunkt?
+- **Automatisierbarkeit vs. Urteilsbedarf:** Manche Findings brauchen menschliches Urteil. Ist das ein Mängel des Findings oder ein Merkmal des Problems?
+
+### Vor-Schlussfolgerungs-Checks
+
+Bevor du ein Finding als „nicht handlungsfähig“ klassifizierst:
+- Liegt es am Finding-Text oder an der Natur des Problems? (Nicht jedes Problem hat eine einfache nächste Aktion.)
+- Wäre das Finding für eine andere Rolle (Staff Engineer vs. Junior Dev) doch handlungsfähig?
+- Verwechselst du „handlungsfähig“ mit „sofort automatisierbar“?
+
+### Konfidenz-Kalibrierung
+
+Gib für jede Actionability-Lücke an:
+- **Konfidenz:** hoch / mittel / niedrig — dass die Lücke real ist
+- **Evidenz:** Woran machst du fest, dass ein Maintainer hier nicht handeln würde?
+- **Entkräftung:** In welchem Kontext wäre dieses Finding doch ausreichend handlungsfähig?
+
+### Fehlerschluss-Wächter
+
+Prüfe aktiv gegen:
+- **Illusion of Actionability:** Ein Finding klingt operativ („refactor X“), führt aber zu keiner klaren, scoped Aktion. Prüfe ob „handlungsfähig“ wirklich „durchführbar“ bedeutet.
+- **Metric Fixation:** Actionability-Score als Selbstzweck statt als Proxy für reales Handeln.
+- **Expert Bias:** Du bewertest als KI mit Vollzugriff auf den Code. Ein Maintainer hat 5 Minuten. Kalibriere darauf.
+
 ## Bewertungs-Labels
 
 Verwende ausschließlich Labels aus `.github/prompts/_partials/bewertungs-taxonomie.md`:
@@ -108,4 +139,8 @@ Für jede Empfehlung:
 
 ## Abschlussentscheidung
 
-Formuliere die 5 stärksten Änderungen, mit denen Drift-Findings deutlich operativer und priorisierbarer würden.
+1. Formuliere die 5 stärksten Änderungen, mit denen Drift-Findings deutlich operativer und priorisierbarer würden.
+2. **Gegenposition:** Für welche deiner Top-5-Empfehlungen gibt es ein starkes Gegenargument? Formuliere es.
+3. **Grenzfall:** Nenne ein Finding, bei dem du unsicher bist, ob mangelnde Actionability ein Bug oder ein Feature ist.
+4. **Falsifikation:** Wie könnte man empirisch testen, ob deine Empfehlungen tatsächlich zu mehr Handlung führen?
+5. **Was du nicht beurteilen kannst:** Welche Aspekte der Handlungsfähigkeit liegen außerhalb deiner Beurteilungsfähigkeit (z.B. Team-Dynamik, Organisationskultur)?

{drift_analyzer-2.9.2 → drift_analyzer-2.9.4}/.github/prompts/drift-first-run-dropoffs.prompt.md

@@ -46,6 +46,37 @@ Die Aufgabe ist erst abgeschlossen, wenn du beantworten kannst:
 - Keine allgemeinen UX-Ratschläge — nur Drift-spezifische Beobachtungen.
 - Unsicherheiten explizit benennen.
 
+## Reasoning-Anforderungen
+
+### Spannungsfelder
+
+Navigiere aktiv folgende Spannungen — löse sie nicht vorschnell auf, sondern mache deine Abwägung transparent:
+
+- **Einfachheit vs. Vollständigkeit:** Ein einfacher Quickstart lässt Features aus. Ein vollständiger Einstieg überfordert. Wo liegt der Optimalpunkt für Drift?
+- **Kürze vs. Überzeugungskraft:** Schneller erster Output ≠ überzeugender erster Output. Was braucht der Nutzer zuerst — Speed oder Aha-Moment?
+- **Selbsterklärender Output vs. Dokumentationsbedarf:** Wenn der Output Erklärung braucht, ist er dann schlecht oder ist das Feature komplex?
+
+### Vor-Schlussfolgerungs-Checks
+
+Bevor du eine Empfehlung finalisierst, prüfe:
+- Welche Abbruchpunkte könntest du systematisch übersehen, weil du Drift bereits kennst?
+- Gibt es Abbruchpunkte, die nur bei bestimmten Repo-Typen oder Nutzergruppen auftreten?
+- Verwechselst du persönliche Irritation mit einem realen Nutzerproblem?
+
+### Konfidenz-Kalibrierung
+
+Gib für jeden identifizierten Abbruchpunkt an:
+- **Konfidenz:** hoch / mittel / niedrig — dass er real ist (nicht nur theoretisch)
+- **Evidenz:** Woraus leitest du ab, dass hier Nutzer tatsächlich abspringen?
+- **Entkräftung:** Was müsste wahr sein, damit dieser Punkt kein echtes Problem ist?
+
+### Fehlerschluss-Wächter
+
+Prüfe aktiv gegen:
+- **Curse of Knowledge:** Du kennst Drift. Erstnutzer nicht. Prüfe bei jeder Bewertung: Wüsste jemand ohne Vorwissen, was gemeint ist?
+- **Survivorship Bias:** Du beobachtest nur die Punkte, die du selbst erlebst. Welche Stellen könnten Nutzer zum stillen Abbruch bringen, bevor sie überhaupt klicken?
+- **Solutionism:** Schlage keine Lösung vor, bevor du das Problem vollständig artikuliert hast.
+
 ## Bewertungs-Labels
 
 Verwende ausschließlich Labels aus `.github/prompts/_partials/bewertungs-taxonomie.md`:
@@ -127,4 +158,9 @@ Für jeden Fix:
 ## Abschlussentscheidung
 
 Beantworte abschließend:
-Wenn Drift in den nächsten 30 Tagen nur 3 Abbruchpunkte beseitigen dürfte, welche wären das und warum?
+
+1. Wenn Drift nur 3 Abbruchpunkte beseitigen dürfte, welche wären das und warum?
+2. **Gegenposition:** Argumentiere, warum der von dir am höchsten priorisierte Abbruchpunkt möglicherweise gar keiner ist. Was spricht dagegen?
+3. **Falsifikation:** Was müsste beobachtbar sein, um deine Empfehlung zu widerlegen?
+4. **Konfidenz-Statement:** Wie sicher bist du dir bei deinem Ranking? Was fehlt dir an Information, um sicherer zu sein?
+5. **Blinder Fleck:** Welche Art von Abbruchpunkt könntest du mit deiner Methodik prinzipiell nicht entdecken?

drift_analyzer-2.9.4/.github/prompts/drift-integration-priorities.prompt.md

@@ -0,0 +1,142 @@
+---
+name: "Drift Integration Priorities"
+description: "Bewertet Integrationen nach realem Adoptionseffekt statt nach Vollständigkeit. Liefert eine priorisierte Matrix der 3 wirksamsten Integrationen für Drift."
+---
+
+# Drift Integration Priorities
+
+Du analysierst, welche Integrationen Drift am stärksten von „interessant" zu „regelmäßig genutzt" bewegen würden.
+
+> **Pflicht:** Vor Ausführung dieses Prompts das Drift Policy Gate durchlaufen
+> (siehe `.github/prompts/_partials/konventionen.md` und `.github/instructions/drift-policy.instructions.md`).
+
+## Relevante Referenzen
+
+- **Instruction:** `.github/instructions/drift-policy.instructions.md`
+- **Bewertungssystem:** `.github/prompts/_partials/bewertungs-taxonomie.md`
+- **Issue-Filing:** `.github/prompts/_partials/issue-filing.md`
+- **Verwandte Prompts:** `drift-ci-gate.prompt.md`, `drift-shareability-review.prompt.md`
+- **Aktuelle Integrationen:** `action.yml`, `src/drift/output/`, `src/drift/mcp_server.py`
+
+## Arbeitsmodus
+
+- Bewerte jede Integration nach Adoptionseffekt, Aufwand, Team-Fit und Anschlussfähigkeit.
+- Bevorzuge wenige starke Hebel statt breiter Wunschliste.
+- Trenne zwischen Demo-Attraktivität und realer täglicher Nutzung.
+- Sammle nicht möglichst viele Integrationen, sondern priorisiere die wenigen mit echtem Wirkungspotenzial.
+
+## Ziel
+
+Identifiziere die Integrationen, die Drift am stärksten in tägliche Entwickler-Workflows verankern würden, und liefere eine belastbare Priorisierung.
+
+## Erfolgskriterien
+
+Die Aufgabe ist erst abgeschlossen, wenn du beantworten kannst:
+- Welche Integrationen würden Drift am ehesten in tägliche Abläufe bringen?
+- Welche Integrationen sind attraktiv, aber überschätzt?
+- Welche verbessern First-Run-Value kaum, aber langfristige Adoption stark?
+- Welche helfen Teams beim Weiterleiten, Diskutieren und Handeln?
+- Welche 3 haben das beste Verhältnis aus Wirkung zu Aufwand?
+
+## Arbeitsregeln
+
+- Bewerte bestehende und denkbare Integrationen.
+- Prüfe den aktuellen Stand: `action.yml`, SARIF-Output, MCP-Server, JSON-Output, Badge.
+- Keine allgemeinen Integrations-Empfehlungen — nur Drift-spezifische Bewertungen.
+- Unsicherheiten explizit benennen.
+
+## Reasoning-Anforderungen
+
+### Spannungsfelder
+
+Navigiere aktiv folgende Spannungen — mache deine Abwägung transparent:
+
+- **Breite Erreichbarkeit vs. Tiefe in wenigen Workflows:** Viele leichte Integrationen vs. wenige tiefe. Was bewegt Adoption stärker?
+- **Demo-Attraktivität vs. täglicher Nutzen:** Manche Integrationen sehen in Demos spektakulär aus, werden aber selten genutzt. Prüfe für jede Empfehlung: Würde sie nach der Demo-Phase weiterleben?
+- **Build vs. Leverage:** Eigene Integration vs. Andocken an bestehende Ökosysteme (z.B. GitHub Actions Marketplace, IDE-Plugins). Wo hat Drift einen Own-Build-Vorteil?
+
+### Vor-Schlussfolgerungs-Checks
+
+Bevor du eine Integration priorisierst:
+- Hast du das Second-Order-Problem bedacht? (Eine CI-Integration erfordert auch: Dokumentation, Defaults, Error-Handling, Edge Cases.)
+- Hast du geprüft, ob die Integration ein Pull-Mechanismus ist (Nutzer wollen es) oder ein Push-Mechanismus (wir glauben, sie sollten es wollen)?
+- Gibt es eine bestehende Integration, die ausgebaut werden könnte statt eine neue zu bauen?
+
+### Konfidenz-Kalibrierung
+
+Gib für jede Integrations-Empfehlung an:
+- **Konfidenz:** hoch / mittel / niedrig — dass sie tatsächlich Adoption steigert
+- **Evidenz:** Woraus schließt du auf Nachfrage? (Feature-Requests, Vergleichstools, Workflow-Analyse?)
+- **Entkräftung:** Was müsste wahr sein, damit diese Integration keinen Adoptionseffekt hat?
+
+### Fehlerschluss-Wächter
+
+Prüfe aktiv gegen:
+- **Integration Laundry List:** Viele Integrationen auflisten ≠ die richtige priorisieren. Weniger ist meistens mehr.
+- **Supply-Side-Thinking:** „Wir können das bauen, also sollten wir“ ist kein Priorisierungsgrund.
+- **Survivorship Bias bei Vergleichs-Tools:** Nur weil SonarQube eine IDE-Integration hat, heißt das nicht, dass Drift eine braucht. Prüfe ob die Zielgruppen vergleichbar sind.
+
+## Bewertungs-Labels
+
+Verwende ausschließlich Labels aus `.github/prompts/_partials/bewertungs-taxonomie.md`:
+
+- **Ergebnis-Bewertung:** `pass` / `review` / `fail`
+- **Risiko-Level:** `low` / `medium` / `high` / `critical`
+
+## Artefakte
+
+Erstelle Artefakte unter `work_artifacts/integration_priorities_<YYYY-MM-DD>/`:
+
+1. `summary.md` — Gesamtbewertung
+2. `integration_matrix.md` — Bewertete Matrix aller relevanten Integrationen
+3. `top_3_integrations.md` — Die 3 priorisierten Empfehlungen
+
+## Workflow
+
+### Phase 1: Bestandsaufnahme
+
+Dokumentiere bestehende Integrationen:
+- GitHub Action (`action.yml`)
+- SARIF-Output
+- JSON-Output
+- MCP-Server
+- Badge-Generierung
+- CLI-Automation
+
+### Phase 2: Kandidaten-Analyse
+
+Untersuche zusätzlich denkbare Integrationen:
+- PR-Kommentierung
+- CI-Gating mit Schwellwerten
+- GitHub Checks API
+- Slack- oder Webhook-Integration
+- IDE-Integration
+- Dashboard oder Trend-Report
+- Package-Vergleich oder Dependency-Kontext
+
+### Phase 3: Integrations-Matrix
+
+Erstelle `integration_matrix.md`:
+
+| Integration | Status | Zielnutzer | Zielworkflow | Adoptionseffekt | Aufwand | Team-Fit | Risiko | Priorität |
+|-------------|--------|-----------|-------------|----------------|---------|---------|--------|----------|
+
+### Phase 4: Top 3 Empfehlungen
+
+Erstelle `top_3_integrations.md`:
+
+Für jede der 3 Empfehlungen:
+- Integration
+- Warum gerade diese
+- erwarteter Adoptionseffekt
+- Aufwand
+- Risiken
+- empfohlener erster Schritt
+
+## Abschlussentscheidung
+
+1. Empfiehl genau 3 Integrationen, die Drift jetzt priorisieren sollte. Begründe jede mit Wirkung, Aufwand und Risiko.
+2. **Anti-Empfehlung:** Nenne 1 Integration, die verlockendes Potenzial hat, aber aktuell falsch priorisiert wäre. Erkläre warum und wann der richtige Zeitpunkt wäre.
+3. **Steelman Nicht-Bauen:** Formuliere das stärkste Argument dafür, gar keine neue Integration zu bauen und stattdessen die bestehenden zu vertiefen.
+4. **Sequenzierung:** In welcher Reihenfolge sollten die 3 Empfehlungen umgesetzt werden und warum? Gibt es Abhängigkeiten?
+5. **Prüfbares Kriterium:** Woran erkennt man nach 4 Wochen, ob die priorisierte Integration den erwarteten Adoptionseffekt hat?

{drift_analyzer-2.9.2 → drift_analyzer-2.9.4}/.github/prompts/drift-positioning-review.prompt.md

@@ -45,6 +45,37 @@ Die Aufgabe ist erst abgeschlossen, wenn du beantworten kannst:
 - Keine allgemeinen Marketing-Tipps — nur Drift-spezifische Produktkommunikation.
 - Unsicherheiten explizit benennen.
 
+## Reasoning-Anforderungen
+
+### Spannungsfelder
+
+Navigiere aktiv folgende Spannungen — mache deine Abwägung transparent:
+
+- **Technische Präzision vs. Zugänglichkeit:** „Architektonische Kohärenzerosion“ ist präzise, aber schreckt ab. „Code-Gesundheits-Check“ ist zugänglich, aber unscharf. Wo liegt der Drift-Optimalpunkt?
+- **Differenzierung vs. Vergleichbarkeit:** Zu einzigartig = schwer einzuordnen („Is this like SonarQube?“). Zu vergleichbar = austauschbar. Finde die Balance.
+- **Nische vs. Breitenwirkung:** Präzise Positionierung für eine Zielgruppe vs. breitere Ansprache für Wachstum. Was braucht Drift jetzt?
+
+### Vor-Schlussfolgerungs-Checks
+
+Bevor du eine Positionierung empfiehlst:
+- Funktioniert sie für jemanden, der Drift noch nie gesehen hat? Teste mental mit einem konkreten Leserprofil.
+- Ist deine Empfehlung eine echte Repositionierung oder nur bessere Formulierung des Status Quo?
+- Verwechselst du „ich verstehe, was gemeint ist“ mit „ein Erstleser versteht, was gemeint ist“?
+
+### Konfidenz-Kalibrierung
+
+Gib für jede Kommunikations-Empfehlung an:
+- **Konfidenz:** hoch / mittel / niedrig — dass sie First-Run-Konversion erhöht
+- **Evidenz:** Woraus leitest du die Überlegenheit deiner Formulierung ab?
+- **Entkräftung:** Für welche Zielgruppe könnte die aktuelle Positionierung besser funktionieren als dein Vorschlag?
+
+### Fehlerschluss-Wächter
+
+Prüfe aktiv gegen:
+- **Narrative Bias:** Eine schöne Geschichte ≠ wahre Positionierung. Prüfe ob deine Empfehlung das reale Produkt ehrlich repräsentiert.
+- **Benchmarking-Falle:** Andere Tools kopieren ist kein Positionierungs-Ansatz. Was ist Drifts eigene, ungewöhnliche Stärke?
+- **Über-Vereinfachung:** Wenn du Drift in einem Satz erklären kannst, hast du möglicherweise das Wesentliche verloren. Prüfe, ob Einfachheit auf Kosten der Richtigkeit geht.
+
 ## Bewertungs-Labels
 
 Verwende ausschließlich Labels aus `.github/prompts/_partials/bewertungs-taxonomie.md`:
@@ -110,4 +141,8 @@ Erstelle `rewritten_positioning.md`:
 
 ## Abschlussentscheidung
 
-Schreibe die empfohlene Kurzpositionierung für Drift in 5 Sätzen und nenne die 3 wichtigsten README-Änderungen.
+1. Schreibe die empfohlene Kurzpositionierung für Drift in 5 Sätzen und nenne die 3 wichtigsten README-Änderungen.
+2. **Steelman der aktuellen Positionierung:** Formuliere das stärkste Argument, warum die aktuelle Positionierung besser sein könnte als dein Vorschlag.
+3. **Zielgruppen-Spannungstest:** Würde deine Empfehlung bei allen drei primären Zielgruppen (Individual Maintainer, Tech Lead, OSS-Newcomer) gleich gut funktionieren? Falls nein: Welche Zielgruppe opferst du und warum?
+4. **Risiko-Assessment:** Was geht verloren, wenn Drift deiner Empfehlung folgt? Was geht verloren, wenn nicht?
+5. **Prüfbares Kriterium:** Woran erkennt man in 8 Wochen, ob die Repositionierung funktioniert hat?

drift_analyzer-2.9.4/.github/prompts/drift-repo-segment-fit.prompt.md

@@ -0,0 +1,139 @@
+---
+name: "Drift Repo Segment Fit"
+description: "Analysiert, für welche Repository-Typen Drift heute stark wirkt und welche Segmente priorisiert werden sollten. Liefert eine Segment-Matrix und Positionierungsempfehlungen."
+---
+
+# Drift Repo Segment Fit
+
+Du analysierst, für welche Repository-Typen Drift heute bereits stark ist und für welche Segmente der Fit noch schwach oder unscharf wirkt.
+
+> **Pflicht:** Vor Ausführung dieses Prompts das Drift Policy Gate durchlaufen
+> (siehe `.github/prompts/_partials/konventionen.md` und `.github/instructions/drift-policy.instructions.md`).
+
+## Relevante Referenzen
+
+- **Instruction:** `.github/instructions/drift-policy.instructions.md`
+- **Bewertungssystem:** `.github/prompts/_partials/bewertungs-taxonomie.md`
+- **Issue-Filing:** `.github/prompts/_partials/issue-filing.md`
+- **Verwandte Prompts:** `drift-positioning-review.prompt.md`, `drift-first-run-dropoffs.prompt.md`
+- **Benchmark-Daten:** `benchmark_results/`, `benchmarks/oracle_repos.json`
+
+## Arbeitsmodus
+
+- Beurteile Segment-Fit nach Nutzenklarheit, First-Run-Value, Handlungskraft der Findings und realistischer Adoption.
+- Trenne zwischen gut analysierbar und gut positionierbar.
+- Keine universelle Positionierung für alle denkbaren Repos.
+- Verwende reale oder gut simulierte Repo-Profile.
+
+## Ziel
+
+Schaffe Klarheit darüber, wo Drift bereits überzeugend ist, wo das Produktversprechen schwächer wird und welche Zielsegmente Drift aktiv priorisieren sollte.
+
+## Erfolgskriterien
+
+Die Aufgabe ist erst abgeschlossen, wenn du beantworten kannst:
+- Für welche Repo-Typen ist Drift heute am überzeugendsten?
+- Wo ist der Nutzen schwerer nachweisbar?
+- Wo müssten Positionierung, Defaults oder Output angepasst werden?
+- Welche Segmente sollten aktiv priorisiert werden?
+- Welche Segmente sollten eher nicht im Vordergrund stehen?
+
+## Arbeitsregeln
+
+- Bewerte mindestens 8 verschiedene Repo-Typen.
+- Nutze wenn möglich echte Drift-Analysen oder Benchmark-Daten.
+- Keine bloße Aufzählung — jede Bewertung braucht Begründung.
+- Unsicherheiten explizit benennen.
+
+## Reasoning-Anforderungen
+
+### Spannungsfelder
+
+Navigiere aktiv folgende Spannungen — mache deine Abwägung transparent:
+
+- **Derzeitige Stärken optimieren vs. neue Segmente erschließen:** Drift bei aktuellen Kernnutzern verbessern vs. neue Zielgruppen adressieren. Was bringt mehr Adoption pro Aufwand?
+- **Breite Positionierung vs. Nischenfokus:** „Funktioniert überall“ ist nichts wert als Positionierung. „Nur für X“ schränkt ein. Wo ist der Sweet Spot?
+- **Segment-Fit vs. Segment-Nachfrage:** Drift passt möglicherweise gut zu Segment X, aber Segment X hat keinen Bedarf (oder weiß noch nichts davon). Trenne Fit von Marktpotenzial.
+
+### Vor-Schlussfolgerungs-Checks
+
+Bevor du ein Segment als „stark“ oder „schwach“ bewertest:
+- Basiert dein Urteil auf einer echten oder einer imaginären Drift-Analyse für diesen Repo-Typ?
+- Könnte ein Segment nur deswegen schwach wirken, weil die Defaults für diesen Typ falsch konfiguriert sind? (Kein Fitness-Problem, sondern ein Config-Problem.)
+- Hast du zwischen „Drift liefert hier wenig Findings“ und „Drift liefert hier irrelevante Findings“ unterschieden?
+
+### Konfidenz-Kalibrierung
+
+Gib für jede Segment-Bewertung an:
+- **Konfidenz:** hoch / mittel / niedrig — basierend auf realer Evidenz
+- **Evidenzquelle:** echte Drift-Analyse / Benchmark-Daten / Hypothese?
+- **Entkräftung:** Was müsste wahr sein, damit deine Bewertung dieses Segments falsch ist?
+
+### Fehlerschluss-Wächter
+
+Prüfe aktiv gegen:
+- **Availability Bias:** Du kennst bestimmte Repo-Typen besser als andere. Kompensiere durch explizite Unsicherheitsmarker.
+- **Segment-Romantik:** Ein Segment klingt attraktiv („AI-Agent-Repos!“), aber Drift hat dort möglicherweise keinen echten Hebel. Prüfe nüchtern.
+- **False Generalization:** Ein positives Ergebnis bei einem Repo ≠ guter Fit für das gesamte Segment.
+
+## Bewertungs-Labels
+
+Verwende ausschließlich Labels aus `.github/prompts/_partials/bewertungs-taxonomie.md`:
+
+- **Ergebnis-Bewertung:** `pass` / `review` / `fail`
+- **Risiko-Level:** `low` / `medium` / `high` / `critical`
+
+## Artefakte
+
+Erstelle Artefakte unter `work_artifacts/repo_segment_fit_<YYYY-MM-DD>/`:
+
+1. `summary.md` — Gesamtbewertung
+2. `segment_matrix.md` — Bewertete Matrix pro Segment
+3. `priority_segments.md` — Priorisierte Segmente mit Empfehlungen
+
+## Workflow
+
+### Phase 1: Segment-Definition
+
+Definiere mindestens diese Repo-Typen:
+- kleines Python-Tool (< 5 000 LOC)
+- Python-Bibliothek
+- Framework
+- Monorepo
+- AI-Agent-Repo
+- CLI-Tool
+- Infra- oder Plattform-Repo
+- Security-nahes Repo
+- stark wachsendes OSS-Projekt
+
+### Phase 2: Segment-Bewertung
+
+Bewerte Drift für jedes Segment:
+
+| Segment | Nutzenklarheit | First-Run-Value | Handlungskraft der Findings | Signal-Relevanz | Adoptions-Wahrscheinlichkeit | Gesamtfit |
+|---------|---------------|----------------|---------------------------|----------------|----------------------------|----------|
+
+### Phase 3: Stärken und Schwächen
+
+Für jedes Segment:
+- Was funktioniert gut?
+- Was funktioniert schlecht?
+- Welche Signale sind besonders relevant?
+- Welche Signale sind irrelevant oder störend?
+- Welche Defaults müssten angepasst werden?
+
+### Phase 4: Positionierungsempfehlungen
+
+Erstelle `priority_segments.md`:
+- Die 3 attraktivsten Zielsegmente mit Begründung
+- Empfohlene Narrative pro Segment
+- Empfohlene Default-Anpassungen pro Segment
+- Segmente, die bewusst nicht priorisiert werden sollten
+
+## Abschlussentscheidung
+
+1. Nenne die 3 Repo-Typen, für die Drift zuerst in Kommunikation und Produktarbeit optimiert werden sollte. Begründe die Reihenfolge.
+2. **Gegenposition:** Formuliere das stärkste Argument für eine völlig andere Segment-Priorisierung als deine Empfehlung.
+3. **Fit vs. Nachfrage:** Für welches deiner Top-Segmente ist der Drift-Fit stark, aber die Marktnachfrage unklar? Wie würde man die Nachfrage validieren?
+4. **Mutigster Vorschlag:** Welches Segment würde niemand erwarten, könnte aber der stärkste Wachstumshebel sein? Begründe, selbst wenn die Konfidenz niedrig ist.
+5. **Expliziter Verzicht:** Welche 2 Segmente sollte Drift bewusst nicht priorisieren und warum?