cloudbase-all-in-one

name	cloudbase-all-in-one
description	Unified CloudBase execution guide for all-in-one skill installs. Use this as the first entry point for CloudBase app tasks, especially existing applications that already contain TODOs, fixed pages, and active handlers.
version	2.20.0
alwaysApply	true

CloudBase All-In-One

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

• 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
• WeChat Pay / Official Account OAuth through CloudBase Integration Center -> ./cloudbase-wechat-integration/SKILL.md
• Browser-side document database CRUD -> ./no-sql-web-sdk/SKILL.md
• Browser-side file upload -> ./cloud-storage-web/SKILL.md
• Platform overview only when capability selection is still unclear -> ./cloudbase-platform/SKILL.md

High-yield guardrails

• 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

1. BaaS-first, functions as last resort:

   • Before writing any cloud function or CloudRun service, ask: can the JS SDK handle this directly? (db.collection(...).get(), auth, storage)
   • Use the JS SDK 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, 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.

2. 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.

3. 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\").
   • If loginMethods.usernamePassword !== true, immediately call manageAppAuth(action=\"patchLoginStrategy\", patch={ usernamePassword: true }).
   • In code, use auth.signUp({ username, password }) and auth.signInWithPassword({ username, password }).
   • 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.

4. Database and storage tasks:

   • Reuse the current shared app, auth, db, and storage helpers instead of creating parallel SDK wrappers.
   • 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.

5. 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.