TencentCloudBase/CloudBase-AI-Toolkit

CloudBase All-In-One

Workflow

Jeder CloudBase-Auftrag durchläuft diesen Dreischritt-Prozess:

1. Exploration  →  Das passende Skill vollständig lesen, bevor Code geschrieben wird.
                   Danach suchen, falls nötig, dann den gesamten SKILL.md-Inhalt lesen.
                   Erst mit der Implementierung beginnen, nachdem die API-Muster,
                   Fallstricke und die korrekte Verwendung aus dem Skill-Dokument verstanden wurden.
2. Implementierung
   ├── 2a. Ressourcenvorbereitung → MCP bevorzugen, um Backend-Ressourcen bereitzustellen
   │     (Auth-Anbieter aktivieren, Datenbanktabellen anlegen, Storage-Domains konfigurieren,
   │      Sicherheitsregeln einrichten – bevor Frontend-Code geschrieben wird).
   │     Falls MCP-Tools in dieser Sitzung fehlen, MCP für das nächste Mal konfigurieren und
   │     jetzt die `tcb` CLI verwenden (`./cloudbase-cli/SKILL.md`).
   └── 2b. Frontend-Implementierung → Code schreiben, Abhängigkeiten installieren, Server starten, testen
3. Abschluss  →  cloudbase-code-review ausführen, alle Fehler beheben, Fertig erklären

Wichtige Einschränkungen:

• Phase 2a (Ressourcenvorbereitung) muss vor dem Frontend-Code kommen. MCP-Tools bevorzugen; wenn sie noch nicht geladen sind (erste Sitzung / vor Neustart), auf die tcb CLI zurückfallen, nachdem MCP konfiguriert wurde. Keinen Frontend-Code schreiben, der von nicht erstellten Ressourcen (Tabellen, Auth-Anbieter, Storage-Buckets) abhängt – der Bewerter wird dies als Fehler werten.
• Phase 3 nicht überspringen. Der Abschluss erfasst bekannte Fallstricke, die Agenten während der Implementierung häufig übersehen.

Umfang

Nur Aufgaben bearbeiten, die Teil des Erstellens, Integrierens oder Wartens einer CloudBase-Anwendung sind – einschließlich UI-Design, Spezifikationsplanung und anderer Entwicklungsaktivitäten, wenn sie im Dienst einer CloudBase-App stehen. Wenn die Anfrage überhaupt keinen CloudBase-Anwendungskontext hat, anhalten und dem Benutzer mitteilen, dass dieses Skill nur CloudBase-basierte Entwicklung abdeckt.

Aktivierungsvertrag

Dieses Skill zuerst verwenden, wenn

• Die Aufgabe ein CloudBase-App-Bau, eine Integration oder eine Reparatur ist und der Arbeitsbereich bereits eine Anwendungsimplementierung enthält.
• Die Anfrage Auth, Datenbank, Storage und Frontend-Arbeit in einer einzigen CloudBase-Anwendungsaufgabe mischt.

Vor einer breiten Erkundung Folgendes tun

• Das relevante Skill lesen, bevor Code geschrieben wird. Mit searchKnowledgeBase(mode="skill", skillName=...) nach dem passenden Skill suchen, dann den zurückgegebenen Dateipfad Read, um den vollständigen SKILL.md-Inhalt zu erhalten. Nicht mit der Implementierung beginnen, die nur auf der Zusammenfassung des Suchergebnisses basiert – das vollständige Dokument enthält API-Signaturen, Parameter-Schemata und Fallstrick-Warnungen.
• Zuerst die vorhandenen Implementierungsoberflächen inspizieren:
  • src/lib/backend.*
  • src/lib/auth.*
  • src/lib/*service.*
  • Routen-Guards
  • Die an die aktiven Formular-Submit-Schaltflächen gebundenen Seiten-Handler
• Wenn diese Dateien TODOs enthalten, diese TODOs an Ort und Stelle implementieren, bevor neue Hilfsfunktionen, Beispiele oder Ersatzseiten erstellt werden.
• Nicht mit UI-Redesign oder Design-Spezifikationsausgabe beginnen, es sei denn, der Benutzer fordert explizit visuelle Änderungen an.
• Nicht mit Projektmanagement-Schleifen beginnen, wie wiederholten TaskCreate / TaskUpdate, wenn die Aufgabe eine einzelne gezielte Reparatur ist. Die aktiven Dateien lesen und direkt bearbeiten.

Schnell zu den minimal benötigten Skills navigieren

• Minimales Web + Datenbank-Demo / Lovable-ähnlicher BaaS-Schnellpfad -> ./minimal-web-baas-demo/SKILL.md (Standard für 最小前后端 Demo; BaaS-first, keine Cloud Functions)
• Web-App-Ausführung -> ./web-development/SKILL.md
• Web-Auth-Anbieter-Bereitschaft -> ./auth-tool/SKILL.md
• Web-Auth-Implementierung -> ./auth-web/SKILL.md
• CloudBase PostgreSQL / PG-App-Daten -> ./postgresql-development/SKILL.md
• WeChat Pay / Official Account OAuth über CloudBase Integration Center -> ./cloudbase-wechat-integration/SKILL.md
• Browserseitiges Dokumentdatenbank-CRUD -> ./no-sql-web-sdk/SKILL.md
• Browserseitiger Datei-Upload -> ./cloud-storage-web/SKILL.md
• Plattform-Übersicht nur, wenn die Fähigkeitenauswahl noch unklar ist -> ./cloudbase-platform/SKILL.md
• Bei Verwendung von searchKnowledgeBase(mode="skill") die Referenzverzeichnis-ID angeben, z. B. postgresql-development-cloudbase oder minimal-web-baas-demo, keinen erratenen Alias.

Hochwirksame Leitplanken

• Backend-Ressourcen vor dem Frontend-Code vorbereiten. MCP für Auth-Anbieter, Datenbanktabellen, Storage-Domänen und Sicherheitsregeln bevorzugen. Wenn MCP-Tools in dieser Sitzung fehlen, MCP für die nächste Sitzung konfigurieren und jetzt die tcb CLI verwenden – nicht auf einen Neustart warten. Frontend-Code, der gegen nicht vorhandene Ressourcen geschrieben wird, führt zu Bewerter-Fehlschlägen.
• Change-Safety-Protokoll: Vor jeder nicht-trivialen Code- oder Konfigurationsänderung muss das cloudbase-platform/references/protocols/change-safety-protocol.md strikt befolgt werden (Auswirkung deklarieren → Benutzerbestätigung einholen → nach der Änderung verifizieren → nach 3 Vorkommen desselben Symptoms zur Ursachenanalyse eskalieren).
• Deployment-Gate: Vor jedem Deployment, jeder Veröffentlichung, benutzerdefinierten Domain, CloudRun oder öffentlicher Bereitstellung müssen die Prüfungen in cloudbase-platform/references/protocols/deployment-gate.md abgeschlossen und die obligatorische Deklarationsvorlage präsentiert werden.
• Wenn derselbe Pfad 2-3 Mal fehlschlägt, nicht weiter wiederholen, sondern umleiten. Plattform-Skill, Auth-Domain, Laufzeit und Berechtigungsmodell prüfen, bevor weiterer Code bearbeitet wird.
• Bei der Initialisierung von CloudBase-Clients oder Manager-Operationen immer EnvId explizit in Code, Konfiguration und Befehlsbeispielen angeben. Nicht auf die aktuell CLI-ausgewählte Umgebung oder implizite Standardwerte verlassen.
• Wenn die Konversation nur einen Umgebungs-Alias, Spitznamen oder eine andere Kurzform liefert, mit envQuery(action=list, alias=..., aliasExact=true) auflösen und die kanonische vollständige EnvId verwenden, bevor auth.set_env aufgerufen, Konsolen-Links generiert oder Konfiguration/Code geschrieben wird. Wenn der Alias mehrdeutig oder fehlend ist, anhalten und den Benutzer um Bestätigung bitten.

Dieses Skill NICHT verwenden als

• Grund, jedes CloudBase-Skill zu lesen, bevor Code berührt wird.
• Grund, mit der Plattform-Übersicht zu beginnen, wenn der vorhandene Code bereits den Stack und die fehlenden Teile offenbart.

Arbeitsregeln

1. BaaS-first, Funktionen als letzte Option:

   • Für 最小前后端 / Lovable-ähnliche Demos zuerst zu ./minimal-web-baas-demo/SKILL.md navigieren. Reihenfolge: Connector bereit → Vorlage während des Wartens auf Anmeldedaten aufwärmen → envQuery → eine DB sperren → MCP-Schema → @cloudbase/js-sdk CRUD → Vorschau. Standard-Cloud-Function-Anzahl = 0.
   • Bevor eine Cloud Function oder ein CloudRun-Dienst geschrieben wird, fragen: Kann die korrekte JS SDK-Oberfläche dies direkt handhaben? db.collection(...).get() nur für bestätigte NoSQL-Sammlungen verwenden; app.rdb().from(...) für CloudBase PG-Tabellen; auth / storage aus dem passenden Skill.
   • Die passende JS SDK-Oberfläche direkt verwenden für: Daten-Lese-/Schreibzugriffe, Datei-Uploads, Echtzeit-Updates, einfache Abfragen einschließlich Bestenlisten, Listen, Aggregationen.
   • Nur auf Cloud Functions zurückgreifen, wenn: die Logik serverseitige Berechtigungsdurchsetzung erfordert, die nicht in Datenbankregeln/RLS ausgedrückt werden kann, Drittanbieterdienste aufruft (Zahlung, SMS, externe APIs), oder Hintergrundjobs, die nicht vom Benutzer ausgelöst werden.
   • Nur auf CloudRun zurückgreifen, wenn: persistente Verbindungen (WebSocket), langlebige Berechnungen oder benutzerdefinierte Laufzeiten wirklich erforderlich sind.

2. Vorhandene Anwendung mit TODOs:

   • Als gezielte Reparaturaufgabe behandeln, nicht als Neubau.
   • Den kürzesten Weg vom aktuellen Code zum funktionierenden Ablauf bevorzugen.

3. Auth-Aufgaben:

   • Wenn der Kontobezeichner ein einfacher Benutzername ist, wie admin, editor oder eine andere Zeichenfolge ohne @, die usernamePassword-Anmeldung als blockierende Voraussetzung behandeln.
   • Zuerst queryAppAuth(action="getLoginConfig") aufrufen.
   • Wenn loginMethods.usernamePassword !== true, sofort manageAppAuth(action="patchLoginStrategy", patch={ usernamePassword: true }) aufrufen.
   • Im Web-Anmeldecode auth.signInWithPassword({ username, password }) verwenden.
   • Nicht annehmen, dass direktes Web auth.signUp({ username, password }) für jede Umgebung oder SDK-Version verfügbar ist; zuerst sdkHints / installiertes SDK-Verhalten überprüfen. Wenn eine Benutzernamen-Registrierung erforderlich ist und die direkte Anmeldung nicht unterstützt wird, die Registrierung über einen Backend- oder Management-API-Pfad leiten, der CloudBase Auth-Benutzer erstellt, ohne geheime Schlüssel im Browser-Code offenzulegen.
   • Niemals signUpWithEmailAndPassword oder signInWithEmailAndPassword für diese Benutzernamen-basierten Kontoabläufe verwenden.
   • Sobald die Bereitschaft bestätigt ist, zum aktiven Frontend-Handler zurückkehren und den echten Anmelde-/Registrierungsablauf abschließen.

4. Datenbank- und Storage-Aufgaben:

   • Die aktuellen gemeinsamen app-, auth-, db- und Storage-Helfer wiederverwenden, anstatt parallele SDK-Wrapper zu erstellen.
   • Wenn die Aufgabe CloudBase PG, PostgreSQL, Postgres, PG-Modus, JS SDK v3 PostgreSQL, app.rdb(), queryPgDatabase, managePgDatabase, mysqldb OpenAPI oder RLS erwähnt, ./postgresql-development/SKILL.md lesen, bevor Datenbankcode berührt wird.
   • Für CloudBase PG queryPgDatabase / managePgDatabase für Schema und Verwaltung verwenden; PG-Arbeit nicht an MySQL queryMysqlDatabase / manageMysqlDatabase oder NoSQL-Sammlungs-APIs weiterleiten.
   • Für OpenAPI-Suche searchKnowledgeBase({ mode: "openapi", apiName: "mysqldb" }) direkt aufrufen. Keine erratenen action-Werte wie getApiDocs oder listEndpoints übergeben; diese gehören zu keinem unterstützten Tool-Modus.
   • Für CloudBase PG Web CRUD das JS SDK v3 app.rdb() und dokumentierte Storage app.storage.from() APIs vor rohem HTTP bevorzugen.
   • Für browserseitigen CloudBase-Storage-Upload von lokalem Vite/Preview zuerst die tatsächliche Browser-host:port in den Sicherheitsdomänen prüfen (envQuery(action="domains"), dann envDomainManagement(action="create") falls fehlend). Ein fehlgeschlagener Cover-Upload darf nicht stillschweigend den nachfolgenden PG-Artikel-Insert überspringen.

• Für CloudBase Web SDK db.collection(...).add(...) die erstellte Dokument-ID aus result._id persistieren.
• Für Schreibvorgänge das tatsächliche SDK-Ergebnis validieren, anstatt Erfolg anzunehmen.
• Legacy-API-STOP-Karte: Wenn die Aufgabe PostgreSQL, CloudBase PG, PG mode, app.rdb(), queryPgDatabase, managePgDatabase, PostgREST oder RLS sagt, keine NoSQL-Beispiele aus dem Gedächtnis schreiben. Für Web CRUD app.rdb().from(...), für Verwaltung queryPgDatabase / managePgDatabase und für Web-Auth-Guards auth.getSession() verwenden. Nicht app.database(), db.collection(...), .where(), .orderBy(), app.uploadFile(), getLoginState() oder auth.getUser() als PG/Auth-Standard verwenden.

4. Gezielte Reparaturaufgaben:
   • Funktionale Abschluss dominieren Erkundung.
   • Breite Repo-Durchsuchen, UI-Redesign und losgelösten Demo-Code vermeiden.
   • Datei-Erkundung eng halten. Direkte Lesevorgänge der bekannten aktiven Dateien gegenüber Glob / breiter Suche im gesamten Projekt bevorzugen.