Workspace Surface Audit (Arbeitsflächenprüfung)
Schreibgeschützter Prüfungs-Skill zur Beantwortung der Frage: „Was kann dieser Arbeitsbereich und diese Maschine tatsächlich jetzt tun, und was sollten wir als Nächstes hinzufügen oder aktivieren?“
Dies ist die ECC-native Antwort auf Einrichtungs- und Prüfungs-Plugins. Er ändert keine Dateien, es sei denn, der Benutzer fordert ausdrücklich eine Folgeimplementierung an.
Verwendung
- Der Benutzer sagt: „Richte Claude Code ein”, „Empfehle Automatisierungen”, „Welche Plugins oder MCPs sollte ich verwenden?” oder „Was fehlt mir?“
- Prü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 Oberflächen verbundener Apps, um fehlende Workflow-Ebenen zu finden - Entscheidung, ob eine Fähigkeit als Skill, Hook, Agent, MCP oder externer Connector umgesetzt werden soll
Verbindliche Regeln
- Niemals geheime Werte ausgeben. Nur Anbieternamen, Fähigkeitsnamen, Dateipfade und ob ein Schlüssel oder eine Konfiguration existiert, anzeigen.
- ECC-native Workflows bevorzugen gegenüber generischen „installiere ein anderes Plugin“-Ratschlägen, wenn ECC die Oberfläche sinnvoll 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 in ECC nicht gut abgebildet
- nicht verfügbar und würde eine neue Integration erfordern
Prüfungseingaben
Nur die Dateien und Einstellungen prüfen, die zur guten Beantwortung der Frage erforderlich sind:
- Repository-Oberfläche
package.json, Lockfiles, Sprachmarkierungen, Framework-Konfiguration,README.md.mcp.json,.lsp.json,.claude/settings*.json,.codex/*AGENTS.md,CLAUDE.md, Installationsmanifeste, Hook-Konfigurationen
- Umgebungsoberfläche
.env*-Dateien im aktiven Repository und in angrenzenden ECC-Arbeitsbereichen- Nur Schlüsselnamen wie
STRIPE_API_KEY,TWILIO_AUTH_TOKEN,FAL_KEYanzeigen
- Oberfläche verbundener Tools
- Installierte Plugins, aktivierte Connectors, MCP-Server, LSPs und App-Integrationen
- ECC-Oberfläche
- Vorhandene Skills, Kommandos, Hooks, Agents und Installationsmodule, die den Bedarf bereits abdecken
Prüfungsprozess
Phase 1: Bestandsaufnahme des Vorhandenen
Ein kompaktes Inventar erstellen:
- Aktive Einrichtungsziele
- Installierte Plugins und verbundene Apps
- Konfigurierte MCP-Server
- Konfigurierte LSP-Server
- Durch Schlüsselnamen implizierte umgebungsbasierte Dienste
- Vorhandene ECC-Skills, die für den Arbeitsbereich relevant sind
Wenn eine Oberfläche nur als primitiv existiert, dies hervorheben. Beispiel:
- „Stripe ist über eine verbundene App verfügbar, aber es fehlt ein ECC-Skill für Abrechnungsoperationen”
- „Google Drive ist verbunden, aber es gibt keinen ECC-nativen Google Workspace Operator Workflow”
Phase 2: Benchmark gegen offizielle und installierte Oberflächen
Den Arbeitsbereich vergleichen mit:
- Offiziellen Claude-Plugins, die sich mit Einrichtung, Überprüfung, Dokumentation, Design oder Workflow-Qualität überschneiden
- Lokal in Claude oder Codex installierten Plugins
- 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 Funktionen hat
- ob ECC den Workflow vollständig vermisst
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 Nebenwirkung | Hook |
| Spezialisierte delegierte Rolle | Agent |
| Externe Tool-Brücke | MCP-Server oder Connector |
| Installations-/Bootstrapping-Anleitung | Einrichtungs- oder Prüfungs-Skill |
Standardmäßig benutzerseitige Skills bevorzugen, die vorhandene Tools orchestrieren, wenn der Bedarf operativer und nicht infrastruktureller Natur ist.
Ausgabeformat
Fünf Abschnitte in dieser Reihenfolge zurückgeben:
- Aktuelle Oberfläche
- was jetzt bereits nutzbar ist
- Parität
- wo ECC den Benchmark bereits erreicht oder übertrifft
- Nur primitive Lücken
- Tools existieren, aber ECC fehlt ein sauberer Operator-Skill
- Fehlende Integrationen
- Fähigkeit noch nicht verfügbar
- Top 3-5 nächste Schritte
- Konkrete ECC-native Ergänzungen, geordnet nach Wirkung
Empfehlungsregeln
- Maximal 1-2 der wertvollsten Ideen pro Kategorie empfehlen.
- Skills mit offensichtlichem Benutzerwillen und Geschäftswert bevorzugen:
- Einrichtungsprüfung
- Abrechnungs-/Kundenoperationen
- Issue-/Programmoperationen
- Google Workspace Operationen
- Bereitstellungs-/Betriebskontrolle
- Wenn ein Connector unternehmensspezifisch ist, ihn nur empfehlen, wenn er tatsächlich verfügbar oder für den Workflow des Benutzers klar nützlich ist.
- Wenn ECC bereits ein starkes Primitiv hat, einen Hüllen-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 besitzen sollte.
- Empfehlungen sind spezifisch genug, um ohne weiteren Erkundungsdurchlauf im Repository implementiert zu werden.
- Die endgültige Antwort ist um Workflows herum organisiert, nicht um API-Marken.