Unified CloudBase execution guide for all-in-one skill installs. Use this first for CloudBase app tasks, especially existing apps with TODOs, fixed pages, or active handlers. Routes PostgreSQL / CloudBase PG / app.rdb() / queryPgDatabase / managePgDatabase work away from legacy NoSQL and old auth patterns.
Unified CloudBase execution guide for all-in-one skill installs. Use this first for CloudBase app tasks, especially existing apps with TODOs, fixed pages, or active handlers. Routes PostgreSQL / CloudBase PG / app.rdb() / queryPgDatabase / managePgDatabase work away from legacy NoSQL and old auth patterns.
version
2.21.1
alwaysApply
true
CloudBase All-In-One
Workflow
Every CloudBase task follows this three-stage process:
1. Exploration → Read the matching skill completely before writing any code.
Search for it if needed, then Read the full SKILL.md content.
Only start implementing after understanding the API patterns,
pitfalls, and correct usage from the skill document.
2. Implementation
├── 2a. Resource preparation → Use MCP tools to prepare backend resources
│ (enable auth providers, create database tables, configure storage domains,
│ set up security rules — before writing frontend code)
└── 2b. Frontend implementation → Write code, install deps, start server, test
3. Close-out → Run cloudbase-code-review, fix all errors, declare done
Key constraints:
Stage 2a (resource preparation) must come before frontend code. Always use MCP tools to prepare backend resources first. Don't write frontend code that depends on uncreated resources (tables, auth providers, storage buckets) — the grader will fail.
Do not skip Stage 3. The close-out catches known pitfalls that agents commonly miss during implementation.
Scope
Only handle tasks that are part of building, integrating, or maintaining a CloudBase application — including UI design, spec planning, and other development activities when they are in service of a CloudBase app. If the request has no CloudBase application context at all, stop and tell the user this skill only covers CloudBase-based development.
Activation Contract
Use this first when
The task is a CloudBase app build, integration, or repair and the workspace already contains an application implementation.
The request mixes auth, database, storage, and frontend work in one CloudBase application task.
Do this before broad exploration
Read the relevant skill before writing any code. Search for the matching skill with searchKnowledgeBase(mode="skill", skillName=...), then Read the returned file path to get the full SKILL.md content. Do not start implementing based only on the search result summary — the full document contains API signatures, parameter schemas, and pitfall warnings.
Inspect the existing implementation surfaces first:
src/lib/backend.*
src/lib/auth.*
src/lib/*service.*
route guards
the page handlers bound to the active form submit buttons
If these files contain TODOs, implement those TODOs in place before creating new helpers, examples, or replacement pages.
Do not start with UI redesign or design-spec output unless the user explicitly asks for visual changes.
Do not start with project-management loops such as repeated TaskCreate / TaskUpdate when the task is a single targeted repair. Read the active files and edit them directly.
Route quickly to the minimum needed skills
Web app execution -> ./web-development/SKILL.md
Web auth provider readiness -> ./auth-tool/SKILL.md
Web auth implementation -> ./auth-web/SKILL.md
CloudBase PostgreSQL / PG app data -> ./postgresql-development/SKILL.md
WeChat Pay / Official Account OAuth through CloudBase Integration Center -> ./cloudbase-wechat-integration/SKILL.md
Platform overview only when capability selection is still unclear -> ./cloudbase-platform/SKILL.md
If using searchKnowledgeBase(mode="skill"), pass the reference directory id such as postgresql-development, not the frontmatter name value such as postgresql-development-cloudbase.
High-yield guardrails
Prepare backend resources via MCP before writing frontend code. Auth providers, database tables, storage domains, and security rules must be set up through MCP tools before writing any frontend code that depends on them. Frontend code written against non-existent resources will cause grader failures.
Change Safety Protocol: Before any non-trivial code or configuration change, you must strictly follow cloudbase-platform/references/protocols/change-safety-protocol.md (declare impact → obtain user confirmation → verify after change → escalate to root cause analysis after 3 occurrences of the same symptom).
Deployment Gate: Before any deployment, publish, custom domain, CloudRun, or public exposure work, you must complete the checks in cloudbase-platform/references/protocols/deployment-gate.md and present the mandatory declaration template.
If the same path fails 2-3 times, stop retrying and reroute. Check platform skill, auth domain, runtime, and permission model before editing more code.
Always specify EnvId explicitly in code, configuration, and command examples when initializing CloudBase clients or manager operations. Do not rely on the current CLI-selected environment or implicit defaults.
If the conversation only provides an environment alias, nickname, or other shorthand, resolve it with envQuery(action=list, alias=..., aliasExact=true) and use the returned canonical full EnvId before calling auth.set_env, generating console links, or writing config/code. If the alias is ambiguous or missing, stop and ask the user to confirm.
Do NOT use this as
A reason to read every CloudBase skill before touching code.
A reason to start from platform overview when the existing code already reveals the stack and the missing pieces.
Working rules
BaaS-first, functions as last resort:
Before writing any cloud function or CloudRun service, ask: can the correct JS SDK surface handle this directly? Use db.collection(...).get() only for confirmed NoSQL collections; use app.rdb().from(...) for CloudBase PG tables; use auth / storage from the matching skill.
Use the matching JS SDK surface directly for: data reads/writes, file uploads, real-time updates, simple queries including leaderboards, lists, aggregations.
Only drop down to cloud functions when: the logic requires server-side permission enforcement that cannot be expressed in database rules/RLS, calling third-party services (payment, SMS, external APIs), or background jobs not triggered by the user.
Only drop down to CloudRun when: persistent connections (WebSocket), long-running compute, or custom runtimes are genuinely required.
Existing application with TODOs:
Treat it as a targeted repair task, not a greenfield build.
Prefer the shortest path from current code to working flow.
Auth tasks:
If the account identifier is a plain username such as admin, editor, or another string without @, treat usernamePassword login as a blocking prerequisite.
First call queryAppAuth(action=\"getLoginConfig\").
In Web login code, use auth.signInWithPassword({ username, password }).
Do not assume direct Web auth.signUp({ username, password }) is available for every environment or SDK version; verify sdkHints / installed SDK behavior first. If username registration is required and direct signup is unsupported, route registration through a backend or management API path that creates CloudBase Auth users, without exposing secret keys in browser code.
Never use signUpWithEmailAndPassword or signInWithEmailAndPassword for these username-style account flows.
Once readiness is confirmed, return to the active frontend handler and finish the real login/register flow.
Database and storage tasks:
Reuse the current shared app, auth, db, and storage helpers instead of creating parallel SDK wrappers.
If the task mentions CloudBase PG, PostgreSQL, Postgres, PG mode, JS SDK v3 PostgreSQL, app.rdb(), queryPgDatabase, managePgDatabase, mysqldb OpenAPI, or RLS, read ./postgresql-development/SKILL.md before touching database code.
For CloudBase PG, use queryPgDatabase / managePgDatabase for schema and management; do not route PG work to MySQL querySqlDatabase / manageSqlDatabase or NoSQL collection APIs.
For OpenAPI lookup, call searchKnowledgeBase({ mode: "openapi", apiName: "mysqldb" }) directly. Do not pass guessed action values such as getApiDocs or listEndpoints; those belong to no supported tool mode.
For CloudBase PG Web CRUD, prefer JS SDK v3 app.rdb() and documented storage app.storage.from() APIs before raw HTTP.
For browser-side CloudBase storage upload from local Vite/preview, check the actual browser host:port in security domains first (envQuery(action="domains"), then envDomainManagement(action="create") if missing). A failed cover upload must not silently skip the subsequent PG article insert.
For CloudBase Web SDK db.collection(...).add(...), persist the created document ID from result._id.
For writes, validate the actual SDK result instead of assuming success.
Legacy API STOP card: If the task says PostgreSQL, CloudBase PG, PG mode, app.rdb(), queryPgDatabase, managePgDatabase, PostgREST, or RLS, do not write NoSQL examples from memory. Use app.rdb().from(...) for Web CRUD, queryPgDatabase / managePgDatabase for management, and auth.getSession() for Web auth guards. Do not use app.database(), db.collection(...), .where(), .orderBy(), app.uploadFile(), getLoginState(), or auth.getUser() as the PG/auth default.
Targeted repair tasks:
Functional closure beats exploration.
Avoid broad repo sweeps, UI redesign, and detached demo code.
Keep file discovery narrow. Prefer direct reads of the known active files over Glob / broad search across the whole project.
