"outputs": ["dist/**", ".env.production"] kopiert Ihre Produktions-Secrets in jedes Cache-Artefakt, und ein Deploy-Task ohne "cache": false kann aus dem Cache wiedergegeben werden, statt ausgeführt zu werden: Turborepo gibt die alten Logs aus und meldet Erfolg, obwohl nichts deployt wurde. Dieser Skill findet diese und die weiteren unten aufgeführten Monorepo-Cache-Fehler vor Ihrem nächsten Build und zeigt Ihnen, wie Sie jeden davon beheben.

Ihr Agent führt einen Scan durch auf turbo.json und turbo.jsonc, nx.json, project.json, package.json-Dateien, die turbo, nx oder lerna verwenden (scripts, dependencies und nx-Targets), CI-Workflows und Dockerfiles, die turbo oder nx ausführen, sowie den JavaScript- und TypeScript-Code eines Turborepo-Workspaces (Build-Output wird übersprungen). Er liest JSON mit Kommentaren, kennt die aktuellen Standardwerte (Turborepo cacht jeden Task und läuft im strict env mode; Nx cacht nur Targets, die mit "cache": true markiert sind), führt Package-turbo.json-Dateien mit der darüber liegenden Root-Datei zusammen, kennt die Variablen, die Turborepo an jeden Task übergibt, und die Framework-Präfixe, die es ableitet, unterscheidet rein lesende Tasks wie lint:migrations oder release:notes von echten Deployments und behandelt CI-Secret-Referenzen und kommentierte Platzhalter als das, was sie sind. Er führt niemals turbo, nx oder Ihren Code aus. Er gibt BLOCK, REVIEW oder NOT FLAGGED zurück, mit Datei, Zeile, Begründung und einem sichereren Ansatz. Secrets werden niemals ausgegeben.

Was geprüft wird

BLOCK (vor dem Deployment beheben)

• M01: .env-Dateien und andere Secret-Dateien (.pem, .key, .npmrc, SSH-Keys) in Task-Outputs, wo dann jede Cache-Kopie und jeder Remote-Cache-Upload sie enthält
• M02: Deploy-, Publish-, Release- und Migrate-Tasks, die aus dem Cache bedient werden können (kein "cache": false in Turborepo, "cache": true oder cacheableOperations in Nx); rein lesende Tasks wie lint:migrations, migrations:check oder release:notes werden nicht gemeldet
• M03: TURBO_TOKEN, Nx-Cloud-Tokens, der Remote-Cache-Signaturschlüssel oder der Nx-S3-Cache-Secret-Key, geschrieben in aktiven Zeilen von CI-Dateien, Dockerfiles, package.json-Scripts oder nx.json

REVIEW (vor dem Release prüfen)

• M11: Build-Tasks in der Root-turbo.json ohne outputs
• M12: Umgebungsvariablen, die der Code liest (auch innerhalb von Template-Literalen) und die keine turbo.json deklariert, ein Fund pro Variable
• M13: loser Environment-Modus
• M14: ein selbst gehosteter Turborepo-Remote-Cache (remoteCache.apiUrl, TURBO_API) ohne Signaturprüfung; der Vercel Remote Cache, so eingerichtet wie in der Turborepo-Dokumentation gezeigt, wird nicht gemeldet
• M15: der Turborepo-1.x-pipeline-Schlüssel
• M16: Task-Inputs ohne $TURBO_DEFAULT$
• M17: ein Nx-Cloud-Zugriffstoken in nx.json
• M18: die veralteten Nx-S3-, GCS-, Azure- und Shared-FS-Caches (CVE-2025-36852)
• M19: ein echt wirkendes Cache-Token in einer auskommentierten CI- oder Dockerfile-Zeile (Platzhalter wie your-token sind unbedenklich)

Was enthalten ist

• Der Scanner (Python 3.9+, nur Standardbibliothek)
• Ein Regelwerk mit der Begründung, dem sichereren Ansatz und der offiziellen Quelle für jede Regel
• Riskante und sichere Beispiel-Repositories (ein Turborepo-2-Shop, eine Turborepo-1.x-App und eine Nx-Plattform) und der echte Bericht, den der Scanner für die riskanten Beispiele erstellt

Grenzen

Er liest jede Datei so, wie sie geschrieben ist: Tasks, die Nx-Plugins ableiten, Einstellungen in den Nx-Cloud- oder Vercel-Dashboards (Token-Scopes, Workspace-Zugriffsebenen) und der Remote-Cache, den Vercel für seine eigenen Builds aktiviert, werden nicht erfasst. Umgebungsvariablen werden über alle turbo.json-Dateien des Scans hinweg abgeglichen, nicht pro Task, Env-Zugriff über Hilfsfunktionen wird nicht nachverfolgt, Build-Output in Ordnern, auf die kein outputs-Glob, main-Feld oder bekannter Name verweist, wird wie Quellcode gelesen, und eine .env-Datei, die nur von einem breiten Output-Glob wie ** erfasst wird, wird nicht gemeldet. NOT FLAGGED ist keine Garantie.

Inhalt

Eine ZIP-Datei mit 29 Dateien: SKILL.md, der Scanner in scripts/ (6 Python-Dateien), references/rules.md (jede Regel mit Begründung und sicherem Ansatz) und examples/ (20 Beispieldateien plus report.md, die echte Scanner-Ausgabe für das riskante Beispiel).

So verwenden Sie es: Dies ist ein Agent-Skill: ein Ordner mit einer SKILL.md-Datei und Python-Skripten, die ein KI-Coding-Agent wie Claude Code, Cursor oder Codex CLI ausführen kann. Entpacken Sie ihn in den Skills-Ordner Ihres Agents (für Claude Code: ~/.claude/skills/) und bitten Sie Ihren Agenten dann, Ihr Projekt zu prüfen. Die Skripte laufen auch eigenständig mit Python 3.9 oder neuer, ohne dass etwas installiert werden muss. Sie lesen nur Ihre Dateien: kein Netzwerkzugriff, und nichts wird irgendwohin gesendet.