Skip to main content

cloudbase-code-review

Code review and validation for CloudBase projects. After writing code for Web / miniprogram / CloudRun / cloud-function projects, call this skill to check for known pitfalls — auth guard misuse, missing database tables, RLS misconfiguration, storage domain setup, and SDK API misuse. Supports automated lint scripts (regex-based) + LLM semantic review.

Quellinformationen

Repository
TencentCloudBase/cloudbase-skills
Letzte Quellaktivität
25. Oktober 2026 um 07:41
Erkannte Sprache von SKILL.md
Englisch
Sterne
39
Forks
2

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

Datei-Explorer
12 Dateien

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
name
cloudbase-code-review
description
Code review and validation for CloudBase projects. After writing code for Web / miniprogram / CloudRun / cloud-function projects, call this skill to check for known pitfalls — auth guard misuse, missing database tables, RLS misconfiguration, storage domain setup, and SDK API misuse. Supports automated lint scripts (regex-based) + LLM semantic review.
version
2.36.1
license
MIT
alwaysApply
false
## Sibling skills (local only) Sibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`. If a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context. # CloudBase Code Review > **One-liner**: After implementing CloudBase features, call this skill to catch common mistakes before users do. ## When to use Call this skill **after** completing a CloudBase implementation task, before declaring done: - You implemented auth (login / register / route guard) - You created database tables or wrote CRUD (NoSQL / PostgreSQL / MySQL) - You set up CloudBase Storage (file upload, hosting) - You configured security rules or RLS policies - You wrote MCP-dependent code - You wrote Cloud Function or CloudRun HTTP handlers (check for credential / header echo leaks) ## How it works The skill runs in two layers: | Layer | Method | Speed | What it catches | |-------|--------|-------|-----------------| | **Lint (optional)** | No executable script is shipped. If the user approves running lint, review the code block in `references/lint-rules/README.md`, copy it to a temporary local `cloudbase-lint.mjs`, then run `node cloudbase-lint.mjs --project-dir <path>` | Seconds | Deterministic regex checks — wrong API calls, missing configs, pattern mismatches | | **LLM review** | Read each rule's "LLM 检查" section, inspect code semantically | Variable | Semantic issues — route guard logic, RLS completeness, architecture-level problems | ## Rule index See `references/RULES_INDEX.md` for the full matrix (module × frontend type → applicable rules). ## Rule boundary Do not promote a single failed run or case-specific workaround into a hard rule. A rule should be backed by stable SDK/API documentation, repeated failures, or deterministic runtime behavior. Case-specific observations belong in attribution reports; only broadly applicable constraints should enter `RULES_INDEX.md` or the optional lint checklist. ## Quick start ```bash # Step 1: Read relevant rules for identified modules # references/rules/cross-cutting/AUTH001.md # references/rules/cross-cutting/SEC001.md # references/rules/postgresql/PG-CR001.md # ... # Optional: if the user approves running lint, review the script code block in # references/lint-rules/README.md, copy it to a temporary cloudbase-lint.mjs, # then run: node cloudbase-lint.mjs --project-dir . # Step 2: For each applicable rule, read the "LLM 检查" section # and manually inspect your code before claiming done. ``` ## Rule format Each rule `.md` file follows this structure: ```markdown # RULE-ID Rule Name - **Module**: which module (auth / postgresql / storage / ...) - **Severity**: error | warning - **Stage**: code-generation | deployment | config ## 正则检查 (Lint) The condition checked by the optional script code block in `references/lint-rules/README.md`. ## LLM 检查 Semantic review prompt for human or LLM to evaluate. ## 修复指引 How to fix the issue. ``` ## Reference index All packaged reference files (required for skill lint reachability): - [RULES_INDEX.md](references/RULES_INDEX.md) - [lint-rules/README.md](references/lint-rules/README.md) - [rules/cross-cutting/AUTH001.md](references/rules/cross-cutting/AUTH001.md) - [rules/cross-cutting/SEC001.md](references/rules/cross-cutting/SEC001.md) - [rules/cross-cutting/SKILL001.md](references/rules/cross-cutting/SKILL001.md) - [rules/postgresql/PG-CR001.md](references/rules/postgresql/PG-CR001.md) - [rules/postgresql/PG-CR002.md](references/rules/postgresql/PG-CR002.md) - [rules/postgresql/PG-CR003.md](references/rules/postgresql/PG-CR003.md) - [rules/postgresql/PG-CR004.md](references/rules/postgresql/PG-CR004.md) - [rules/postgresql/PG-CR005.md](references/rules/postgresql/PG-CR005.md) - [rules/storage/STORAGE001.md](references/rules/storage/STORAGE001.md)
Auf GitHub ansehen