| name | drift-mcp-repo-ops-usage |
| description | Operationaler Workflow für den internen MCP-Server aus scripts/mcp_product_health_server.py. Immer verwenden, wenn Agenten Produktstatus, Release-Gates, Working-Tree-Gates oder Audit-Freshness direkt per MCP abrufen sollen statt manuelle Git-/Script-Aufrufe zu bauen. Keywords: drift_product_health, drift_release_readiness, drift_working_tree_context, drift_audit_freshness, mcp server, pre-push gates, blast report, audit freshness. |
| argument-hint | Beschreibe, welche Entscheidung du treffen willst (Health-Check, Release-Go/No-Go, Push-Vorbereitung, Audit-Freshness). |
Drift MCP Repo Ops Usage
Nutze diesen Skill, um den internen MCP-Server in scripts/mcp_product_health_server.py konsistent zu verwenden.
Ziel: Agenten sollen wiederkehrende Repo-Operations direkt per MCP-Tool auslesen, statt dieselben Prüfungen manuell per Terminal zu rekonstruieren.
Wann verwenden
- User fragt nach Produktgesundheit oder Adoption/Performance/Stability-Status.
- User will eine schnelle Release-Entscheidung (GO/NO_GO) vor Push.
- User will wissen, welche Pre-Push-Gates durch den aktuellen Working Tree ausgelöst werden.
- User will prüfen, ob §18-Audit-Artefakte gegenüber Signal-Änderungen veraltet sind.
Wann nicht verwenden
- Für normale Drift-Codeanalyse im Ziel-Repo: dafür die Drift-MCP-Tools (
drift_scan, drift_diff, drift_nudge, ...) verwenden.
- Für Azure-, Foundry- oder Cloud-Operations.
- Wenn der interne Server nicht registriert ist und der User explizit nur CLI-Workflow möchte.
Vorbedingungen
- MCP-Dependency ist installiert:
.venv\Scripts\python.exe -m pip install -e ".[mcp]"
- Der Server ist in .vscode/mcp.json registriert und zeigt auf:
- command:
.venv/Scripts/python.exe (oder passender Python-Pfad)
- args:
scripts/mcp_product_health_server.py
- Bei fehlender Tool-Verfügbarkeit zuerst MCP-Server-Konfiguration reparieren, dann erneut aufrufen.
Tool-Übersicht
drift_product_health(refresh=False)
- Liefert Adoption, Stability, Performance aus KPI-Snapshot.
refresh=True nur nutzen, wenn Live-APIs wirklich nötig sind.
drift_release_readiness()
- Liefert
status: GO|NO_GO, blockers, warnings, agent_instruction.
- Prüft u. a. Version-Sync (
pyproject.toml, CHANGELOG.md, SECURITY.md, llms.txt) und Blast-Report-Erwartung.
drift_working_tree_context()
- Liefert geänderte Bereiche, inferred commit type, getriggerte Gates, empfohlene nächste Aktion.
drift_audit_freshness()
- Liefert Freshness der Audit-Artefakte relativ zum letzten
src/drift/signals/-Commit.
Standard-Workflow
1. Zielentscheidung klären
Ordne die Anfrage einer Entscheidung zu:
- Produktstatus:
drift_product_health
- Release-Go/No-Go:
drift_release_readiness
- Push-Vorbereitung/Gate-Prognose:
drift_working_tree_context
- Audit-Pflicht/Freshness:
drift_audit_freshness
2. Minimal notwendige Tool-Reihenfolge wählen
- Release vor Push:
drift_working_tree_context -> drift_release_readiness
- Signal-nahe Änderung:
drift_working_tree_context -> drift_audit_freshness
- Weekly Health:
drift_product_health(refresh=False)
Erst weitere Tools aufrufen, wenn die erste Antwort eine Unklarheit offen lässt.
3. Ergebnis in Entscheidungssprache übersetzen
Nutze immer dieses Antwortmuster:
- Entscheidung in einem Satz (
GO, NO_GO, Audit fresh, Audit stale, ...)
- Maximal 3 konkrete Gründe aus den Tool-Feldern
- Nächste Aktion als einzelner Befehl oder klarer Schritt
Antwortvorlagen
Release readiness
- GO-Fall: "Release ist GO. Keine Blocker, Push kann erfolgen."
- NO_GO-Fall: "Release ist NO_GO. Behebe zuerst diese Blocker: ..."
Working tree context
- "Es sind N Dateien geändert, Commit-Typ wird als X inferiert, diese Gates feuern: ..."
- "Nächster Schritt: make gate-check COMMIT_TYPE="
Audit freshness
- Fresh: "Alle §18-Audit-Artefakte sind aktuell."
- Stale: "Diese Artefakte sind veraltet: ..."
Product health
- "Produktstatus: HEALTHY/WARNING/ALARM mit Fokus auf Delta, Bugs, Budget-Headroom."
Guardrails
- Keine Aussagen über GO/NO_GO ohne Tool-Output.
- Keine erfundenen Gate-Regeln: nur Felder aus Tool-JSON verwenden.
refresh=True bei drift_product_health sparsam einsetzen (externe API-Last).- Bei
NO_GO immer blocker-first kommunizieren, nicht mit Nebeninfos beginnen.
- Dieser Skill ist intern für das Drift-Repo, nicht für das veröffentlichte Paket.
Kurzer Smoke-Check (optional)
Wenn der User den Server selbst testen will:
.venv\Scripts\python.exe -c "import asyncio, importlib.util; spec=importlib.util.spec_from_file_location('srv','scripts/mcp_product_health_server.py'); m=importlib.util.module_from_spec(spec); spec.loader.exec_module(m); print(asyncio.run(m.drift_release_readiness()))"
Referenzen
