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

1. MCP-Dependency ist installiert:

.venv\Scripts\python.exe -m pip install -e ".[mcp]"

2. 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

3. Bei fehlender Tool-Verfügbarkeit zuerst MCP-Server-Konfiguration reparieren, dann erneut aufrufen.

Tool-Übersicht

1. drift_product_health(refresh=False)

• Liefert Adoption, Stability, Performance aus KPI-Snapshot.
• refresh=True nur nutzen, wenn Live-APIs wirklich nötig sind.

2. 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.

3. drift_working_tree_context()

• Liefert geänderte Bereiche, inferred commit type, getriggerte Gates, empfohlene nächste Aktion.

4. 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:

1. Entscheidung in einem Satz (GO, NO_GO, Audit fresh, Audit stale, ...)
2. Maximal 3 konkrete Gründe aus den Tool-Feldern
3. 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=<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

• scripts/mcp_product_health_server.py
• .vscode/mcp.json
• POLICY.md
• .github/instructions/drift-policy.instructions.md
• .github/instructions/drift-push-gates.instructions.md