TencentCloudBase/CloudBase-AI-Toolkit

CloudBase All-In-One

ワークフロー

すべてのCloudBaseタスクは以下の3段階で進めます。

1. 調査  →  コードを書く前に、該当するスキルを完全に読む。
             必要に応じて検索し、SKILL.md全体をReadする。
             APIパターン、落とし穴、正しい使い方をスキルドキュメントで理解してから実装を開始する。
2. 実装
   ├── 2a. リソース準備 → MCPを使ってバックエンドリソースを準備することを推奨
   │     （認証プロバイダーの有効化、データベーステーブルの作成、ストレージドメインの設定、
   │      セキュリティルールの設定 — フロントエンドコードを書く前に行う）。
   │     このセッションでMCPツールが利用できない場合は、MCPを次回のために設定し、
   │     今は`tcb` CLIを使う（`./cloudbase-cli/SKILL.md`）。
   └── 2b. フロントエンド実装 → コードを書き、依存関係をインストールし、サーバーを起動し、テストする。
3. クローズアウト  →  cloudbase-code-reviewを実行し、すべてのエラーを修正し、完了を宣言する。

重要な制約:

• ステージ2a（リソース準備）はフロントエンドコードより先に行うこと。 MCPツールを優先する。まだロードされていない場合（初回セッション、再起動前）は、MCPを設定した上でtcb CLIにフォールバックする。作成されていないリソース（テーブル、認証プロバイダー、ストレージバケット）に依存するフロントエンドコードは書かないこと — 採点者は不合格にする。
• ステージ3をスキップしないこと。 クローズアウトでは、エージェントが実装中に見落としがちな既知の落とし穴をキャッチする。

スコープ

CloudBaseアプリケーションの構築、統合、メンテナンスの一部であるタスクのみを扱う。UIデザイン、仕様計画、その他の開発活動も、CloudBaseアプリケーションのためのものであれば対象とする。リクエストにCloudBaseアプリケーションのコンテキストがまったくない場合、停止してこのスキルはCloudBaseベースの開発のみをカバーしていることをユーザーに伝える。

アクティベーション契約

最初にこれを使うべきケース

• タスクがCloudBaseアプリケーションのビルド、統合、または修復であり、ワークスペースにすでにアプリケーションの実装が含まれている場合。
• リクエストが認証、データベース、ストレージ、フロントエンドの作業を1つのCloudBaseアプリケーションタスクに混在させている場合。

広範な調査の前に行うこと

• コードを書く前に関連するスキルを読むこと。 searchKnowledgeBase(mode="skill", skillName=...) で該当するスキルを検索し、返されたファイルパスを Read してSKILL.md全体の内容を取得する。検索結果の要約だけを基に実装を開始しないこと — 完全なドキュメントにはAPIシグネチャ、パラメータスキーマ、落とし穴の警告が含まれている。
• 最初に既存の実装面を検査する：
  • src/lib/backend.*
  • src/lib/auth.*
  • src/lib/*service.*
  • ルートガード
  • アクティブなフォーム送信ボタンにバインドされたページハンドラー
• これらのファイルにTODOが含まれている場合、新しいヘルパー、例、置き換えページを作成する前に、その場所でTODOを実装する。
• ユーザーが明示的に視覚的な変更を求めない限り、UIの再設計やデザイン仕様の出力から始めない。
• タスクが単一のターゲット修復である場合、TaskCreate / TaskUpdate のようなプロジェクト管理ループから始めない。アクティブなファイルを読み、直接編集する。

必要な最小限のスキルに素早くルーティングする

• 最小限のWeb + データベースデモ / LovableライクなBaaS高速パス -> ./minimal-web-baas-demo/SKILL.md（最小前後端デモのデフォルト。BaaSファースト、クラウド関数なし）
• Webアプリケーション実行 -> ./web-development/SKILL.md
• Web認証プロバイダーの準備 -> ./auth-tool/SKILL.md
• Web認証実装 -> ./auth-web/SKILL.md
• CloudBase PostgreSQL / PGアプリケーションデータ -> ./postgresql-development/SKILL.md
• CloudBase統合センター経由のWeChat決済 / 公式アカウントOAuth -> ./cloudbase-wechat-integration/SKILL.md
• ブラウザ側ドキュメントデータベースCRUD -> ./no-sql-web-sdk/SKILL.md
• ブラウザ側ファイルアップロード -> ./cloud-storage-web/SKILL.md
• 機能選択がまだ不明確な場合のみ、プラットフォーム概要 -> ./cloudbase-platform/SKILL.md
• searchKnowledgeBase(mode="skill") を使用する場合、参照ディレクトリID（例：postgresql-development-cloudbase や minimal-web-baas-demo）を渡す。推測したエイリアスは渡さない。

効果の高いガードレール

• フロントエンドコードを書く前にバックエンドリソースを準備する。 認証プロバイダー、データベーステーブル、ストレージドメイン、セキュリティルールにはMCPを優先する。このセッションでMCPツールがない場合は、次回のセッションのためにMCPを設定し、今はtcb CLIを使用する — 再起動を待って停止しない。存在しないリソースに対して書かれたフロントエンドコードは、採点者による不合格を引き起こす。
• 変更安全プロトコル：重要なコードまたは設定変更の前に、cloudbase-platform/references/protocols/change-safety-protocol.md に厳密に従う（影響を宣言 → ユーザー確認を取得 → 変更後に確認 → 同じ症状が3回発生したら根本原因分析にエスカレーションする）。
• デプロイゲート：デプロイ、公開、カスタムドメイン、CloudRun、またはパブリック公開の作業の前に、cloudbase-platform/references/protocols/deployment-gate.md のチェックを完了し、必須の宣言テンプレートを提示する。
• 同じパスが2〜3回失敗した場合、再試行を停止してルートを変更する。コードをさらに編集する前に、プラットフォームスキル、認証ドメイン、ランタイム、権限モデルを確認する。
• CloudBaseクライアントまたはマネージャー操作を初期化するときは、コード、設定、コマンド例で必ず EnvId を明示的に指定する。現在のCLI選択環境や暗黙のデフォルトに依存しない。
• 会話で環境エイリアス、ニックネーム、その他の省略形のみが提供されている場合、envQuery(action=list, alias=..., aliasExact=true) で解決し、auth.set_env を呼び出したり、コンソールリンクを生成したり、設定/コードを書いたりする前に、返された正規の完全な EnvId を使用する。エイリアスがあいまいまたは欠落している場合、停止してユーザーに確認を求める。

これを使うべきでないケース

• コードに触れる前にすべてのCloudBaseスキルを読む理由として。
• 既存のコードがすでにスタックと不足している部分を明らかにしているのに、プラットフォーム概要から始める理由として。

作業ルール

1. BaaSファースト、関数は最後の手段：

   • 最小前後端 / Lovableライクなデモの場合、最初に ./minimal-web-baas-demo/SKILL.md にルーティングする。順序：コネクタ準備 → 認証情報待ち中にテンプレートウォームアップ → envQuery → 1つのDBをロック → MCPスキーマ → @cloudbase/js-sdk CRUD → プレビュー。デフォルトのクラウド関数数 = 0。
   • クラウド関数またはCloudRunサービスを書く前に、正しいJS SDKサーフェスで直接処理できるかどうかを確認する。確認されたNoSQLコレクションには db.collection(...).get() のみを使用する。CloudBase PGテーブルには app.rdb().from(...) を使用する。認証/ストレージには該当するスキルから auth / storage を使用する。
   • データの読み取り/書き込み、ファイルアップロード、リアルタイム更新、リーダーボード、リスト、集計を含む単純なクエリには、該当するJS SDKサーフェスを直接使用する。
   • クラウド関数に降りるのは、ロジックがデータベースルール/RLSで表現できないサーバーサイド権限の適用を必要とする場合、サードパーティサービス（決済、SMS、外部API）を呼び出す場合、またはユーザーがトリガーしないバックグラウンドジョブの場合のみ。
   • CloudRunに降りるのは、永続的接続（WebSocket）、長時間実行コンピュート、またはカスタムランタイムが本当に必要な場合のみ。

2. 既存のTODOがあるアプリケーション：

   • 新規構築ではなく、ターゲット修復タスクとして扱う。
   • 現在のコードから動作するフローへの最短経路を優先する。

3. 認証タスク：

   • アカウント識別子が admin、editor など @ を含まないプレーンなユーザー名の場合、usernamePassword ログインを必須の前提条件として扱う。
   • 最初に queryAppAuth(action="getLoginConfig") を呼び出す。
   • loginMethods.usernamePassword !== true の場合、すぐに manageAppAuth(action="patchLoginStrategy", patch={ usernamePassword: true }) を呼び出す。
   • Webログインコードでは auth.signInWithPassword({ username, password }) を使用する。
   • すべての環境やSDKバージョンで直接Webの auth.signUp({ username, password }) が利用可能とは限らない。まず sdkHints / インストール済みSDKの動作を確認する。ユーザー名登録が必要で直接サインアップがサポートされていない場合、バックエンドまたは管理APIパスを通じてCloudBase Authユーザーを作成するルートにルーティングし、ブラウザコードに秘密鍵を公開しない。
   • これらのユーザー名形式のアカウントフローに signUpWithEmailAndPassword や signInWithEmailAndPassword を決して使用しない。
   • 準備が確認されたら、アクティブなフロントエンドハンドラーに戻り、実際のログイン/登録フローを完了する。

4. データベースおよびストレージタスク：

   • 並列のSDKラッパーを作成する代わりに、現在共有されている app、auth、db、ストレージヘルパーを再利用する。
   • タスクがCloudBase PG、PostgreSQL、Postgres、PGモード、JS SDK v3 PostgreSQL、app.rdb()、queryPgDatabase、managePgDatabase、mysqldb OpenAPI、またはRLSについて言及している場合、データベースコードに触れる前に ./postgresql-development/SKILL.md を読む。
   • CloudBase PGの場合、スキーマと管理には queryPgDatabase / managePgDatabase を使用する。PGの作業をMySQLの queryMysqlDatabase / manageMysqlDatabase やNoSQLコレクションAPIにルーティングしない。
   • OpenAPIの検索には、searchKnowledgeBase({ mode: "openapi", apiName: "mysqldb" }) を直接呼び出す。getApiDocs や listEndpoints などの推測された action 値を渡さない。これらはサポートされているツールモードに属さない。
   • CloudBase PGのWeb CRUDには、生のHTTPよりもJS SDK v3の app.rdb() と文書化されたストレージ app.storage.from() APIを優先する。
   • ローカルのVite/プレビューからのブラウザ側CloudBaseストレージアップロードでは、最初にセキュリティドメイン内の実際のブラウザ host:port を確認する（envQuery(action="domains")、欠落している場合は envDomainManagement(action="create")）。カバーアップロードの失敗は、その後のPG記事インサートを黙ってスキップしてはならない。
   • CloudBase Web SDKの db.collection(...).add(...) では、作成されたドキュメントIDを result._id から保持する。
   • 書き込みでは、成功を想定せずに実際のSDK結果を検証する。
   • レガシーAPIストップカード：タスクが PostgreSQL、CloudBase PG、PGモード、app.rdb()、queryPgDatabase、managePgDatabase、PostgREST、または RLS である場合、記憶からNoSQLの例を書かない。Web CRUDには app.rdb().from(...) を、管理には queryPgDatabase / managePgDatabase を、Web認証ガードには auth.getSession() を使用する。PG/認証のデフォルトとして app.database()、db.collection(...)、.where()、.orderBy()、app.uploadFile()、getLoginState()、auth.getUser() を使用しない。

5. ターゲット修復タスク：

   • 機能の完了が探索よりも優先される。
   • 広範なリポジトリスイープ、UI再設計、切り離されたデモコードを避ける。
   • ファイル発見は狭く保つ。プロジェクト全体にわたる Glob / 広範な検索よりも、既知のアクティブファイルの直接読み取りを優先する。