Audit der Arbeitsflächen-Oberfläche
Lese-Audit-Skill zur Beantwortung der Frage „Was kann dieser Workspace und diese Maschine jetzt tatsächlich, und was sollten wir als Nächstes hinzufügen oder aktivieren?“
Dies ist die ECC-native Antwort auf Setup-Audit-Plugins. Es verändert keine Dateien, es sei denn, der Benutzer fordert explizit eine Folgeimplementierung an.
Wann verwenden
- Benutzer sagt „Claude Code einrichten“, „Automatisierungen empfehlen“, „welche Plugins oder MCPs sollte ich verwenden?“ oder „was fehlt mir?“
- Überprüfung einer Maschine oder eines Repositorys vor der Installation weiterer Skills, Hooks oder Connectors
- Vergleich offizieller Marktplatz-Plugins mit ECC-nativer Abdeckung
- Überprüfung von
.env,.mcp.json, Plugin-Einstellungen oder verbundenen App-Oberflächen, um fehlende Workflow-Ebenen zu finden - Entscheidung, ob eine Fähigkeit als Skill, Hook, Agent, MCP oder externer Connector umgesetzt werden soll
Unverhandelbare Regeln
- Niemals geheime Werte ausgeben. Nur Anbieternamen, Fähigkeitsnamen, Dateipfade und ob ein Schlüssel oder eine Konfiguration existiert, anzeigen.
- ECC-native Workflows gegenüber generischen „installiere ein weiteres Plugin“-Ratschlägen bevorzugen, wenn ECC die Oberfläche vernünftig abdecken kann.
- Externe Plugins als Benchmarks und Inspiration behandeln, nicht als maßgebliche Produktgrenzen.
- Drei Dinge klar trennen:
- bereits jetzt verfügbar
- verfügbar, aber nicht gut in ECC eingebunden
- nicht verfügbar und würde eine neue Integration erfordern
Audit-Eingaben
Nur die Dateien und Einstellungen überprüfen, die nötig sind, um die Frage gut zu beantworten:
- Repo-Oberfläche
package.json, Lockfiles, Sprachmarkierungen, Framework-Konfigurationen,README.md.mcp.json,.lsp.json,.claude/settings*.json,.codex/*AGENTS.md,CLAUDE.md, Installationsmanifeste, Hook-Konfigurationen
- Umgebungsoberfläche
.env*-Dateien im aktiven Repo und offensichtlichen benachbarten ECC-Workspaces- Nur Schlüsselnamen anzeigen, z. B.
STRIPE_API_KEY,TWILIO_AUTH_TOKEN,FAL_KEY
- Verbundene Tool-Oberfläche
- Installierte Plugins, aktivierte Connectors, MCP-Server, LSPs und App-Integrationen
- ECC-Oberfläche
- Vorhandene Skills, Befehle, Hooks, Agents und Installationsmodule, die die Anforderung bereits abdecken
Audit-Prozess
Phase 1: Bestandsaufnahme des Vorhandenen
Eine kompakte Bestandsaufnahme erstellen:
- aktive Harness-Ziele
- installierte Plugins und verbundene Apps
- konfigurierte MCP-Server
- konfigurierte LSP-Server
- durch Schlüsselnamen implizierte, durch Umgebungsvariablen gestützte Dienste
- vorhandene ECC-Skills, die für den Workspace bereits relevant sind
Wenn eine Oberfläche nur als primitiv existiert, dies hervorheben. Beispiel:
- „Stripe ist über eine verbundene App verfügbar, aber ECC hat keinen Abrechnungs-Operator-Skill“
- „Google Drive ist verbunden, aber es gibt keinen ECC-nativen Google Workspace-Operator-Workflow“
Phase 2: Benchmarking gegen offizielle und installierte Oberflächen
Den Workspace vergleichen mit:
- offiziellen Claude-Plugins, die sich mit Einrichtung, Überprüfung, Dokumentation, Design oder Workflow-Qualität überschneiden
- lokal installierten Plugins in Claude oder Codex
- den derzeit verbundenen App-Oberflächen des Benutzers
Nicht nur Namen auflisten. Für jeden Vergleich beantworten:
- was sie tatsächlich tun
- ob ECC bereits Parität hat
- ob ECC nur Primitive hat
- ob ECC den Workflow vollständig vermissen lässt
Phase 3: Lücken in ECC-Entscheidungen umwandeln
Für jede echte Lücke die korrekte ECC-native Form empfehlen:
| Lückentyp | Bevorzugte ECC-Form |
|---|---|
| Wiederholbarer Operator-Workflow | Skill |
| Automatische Durchsetzung oder Nebeneffekt | Hook |
| Spezialisierte delegierte Rolle | Agent |
| Externe Tool-Brücke | MCP-Server oder Connector |
| Installations-/Bootstrap-Anleitung | Setup- oder Audit-Skill |
Standardmäßig benutzerorientierte Skills empfehlen, die vorhandene Tools orchestrieren, wenn der Bedarf eher operativ als infrastrukturell ist.
Ausgabeformat
Fünf Abschnitte in dieser Reihenfolge zurückgeben:
- Aktuelle Oberfläche
- was bereits jetzt nutzbar ist
- Parität
- wo ECC den Benchmark bereits erreicht oder übertrifft
- Nur-Primitive-Lücken
- Tools existieren, aber ECC hat keinen sauberen Operator-Skill
- Fehlende Integrationen
- Fähigkeit noch nicht verfügbar
- Top 3-5 nächste Schritte
- konkrete ECC-native Ergänzungen, geordnet nach Auswirkung
Empfehlungsregeln
- Pro Kategorie höchstens 1-2 Ideen mit dem höchsten Wert empfehlen.
- Skills mit offensichtlicher Benutzerabsicht und Geschäftswert bevorzugen:
- Setup-Audit
- Abrechnungs-/Kundenbetrieb
- Issue-/Programmbetrieb
- Google Workspace-Betrieb
- Deployment-/Ops-Steuerung
- Wenn ein Connector unternehmensspezifisch ist, ihn nur empfehlen, wenn er tatsächlich verfügbar oder für den Workflow des Benutzers eindeutig nützlich ist.
- Wenn ECC bereits ein starkes Primitiv hat, einen Wrapper-Skill vorschlagen, anstatt ein brandneues Subsystem zu erfinden.
Gute Ergebnisse
- Der Benutzer kann sofort sehen, was verbunden ist, was fehlt und was ECC als Nächstes übernehmen sollte.
- Die Empfehlungen sind spezifisch genug, um ohne weiteren Erkundungsdurchlauf im Repo implementiert zu werden.
- Die endgültige Antwort ist um Workflows organisiert, nicht um API-Marken.