Install any skill in seconds. Free to start, no credit card required.
Get Started Free →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.
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-04 | ✗→✓ | ▲ Improved | -14% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 51% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 1% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 6% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 19% | 0% |
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.
> One-liner: After implementing CloudBase features, call this skill to catch common mistakes before the grader does.
Call this skill after completing a CloudBase implementation task, before declaring done:
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 |
See references/RULES_INDEX.md for the full matrix (module × frontend type → applicable rules).
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.
bash# Step 1: Read relevant rules for identified modules # references/rules/cross-cutting/AUTH001.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.
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.
All packaged reference files (required for skill lint reachability):
Other measured skills in the registry, with their headline benchmark lift.