nocobase-ui-builder

Original🇨🇳 Chinese
Translated
55 scripts

Create, read, update, move, and delete NocoBase Modern page (v2) pages and blocks via MCP; validation, review, and smoke testing are only initiated when explicitly requested by the user.

8installs
Added on

NPX Install

npx skill4agent add nocobase/skills nocobase-ui-builder

SKILL.md Content (Chinese)

View Translation Comparison →

Objective

Process NocoBase Modern page (v2) pages and blocks using the
desktopRoutes
and
flowModels
MCP tools.
This skill covers:
  • create / read / update / move / delete pages, tabs, blocks, actions, JS models
  • structured delivery driven by route-ready, readback, payload guard
  • validation / review / improve / smoke, but only initiated when explicitly requested by the user
The top-level
SKILL.md
only retains trigger boundaries, unified entry points, a small number of hard gates, and final reporting axes. Specific task routing, recipes, block/pattern/JS contracts are all subject to the following canonical docs:
  • references/index.md

When to Trigger

  • The user wants to create, read, update, move, or delete Modern page (v2) pages or blocks
  • The user wants to modify existing Modern pages using
    desktopRoutes v2
    /
    flowModels
  • The user requests route-ready, readback, guard, or structured validation conclusions
  • The user explicitly requests validation / review / improve / smoke / browser validation

When Not to Trigger

  • Only handling collections / fields / relations: use
    nocobase-data-modeling
    instead
  • Only handling workflows: use
    nocobase-workflow-manage
    instead
  • Only doing MCP installation or connection: use
    nocobase-mcp-setup
    instead

Unified Entry Point

  1. First open references/index.md.
  2. Read the corresponding canonical docs, recipes, block docs, pattern docs, JS docs according to task routing.
  3. Except for built-in pipelines like
    rest_validation_builder.mjs
    /
    rest_template_clone_runner.mjs
    , writing is only executed via
    node scripts/ui_write_wrapper.mjs run --action <create-v2|save|mutate|ensure> ...
    by default.
  4. The wrapper internally handles
    start-run -> guard -> write -> readback
    ; do not manually split the process at the outer layer.
  5. Validation / review / improve are only initiated when explicitly requested by the user;
    browser_attach
    /
    smoke
    should be marked as
    skipped
    if browser validation is not performed.

Default Hard Gates

  1. Do not guess the structure of
    use
    , slot, or
    requestBody
    if detection is possible.
  2. Must execute
    start-run
    before any detection or write operation; do not detect first and then supplement logs.
  3. Bare
    PostDesktoproutes_createv2
    /
    PostFlowmodels_save
    /
    PostFlowmodels_mutate
    /
    PostFlowmodels_ensure
    are disabled by default; agents can only use
    ui_write_wrapper.mjs
    or builder pipelines with a complete built-in validation chain by default.
  4. preflight_write_gate.mjs
    and
    flow_write_wrapper.mjs
    are now underlying/compatibility components and are no longer the default agent entry points; do not manually split into "gate first, write manually, then supplement readback manually".
  5. A successful
    createV2
    only means
    page shell created
    ; do not report that the page is ready without evidence of route-ready and anchor readback.
  6. An
    ok
    return from
    save
    /
    mutate
    /
    ensure
    only means the request was submitted successfully; the final result is subject to subsequent readback.
  7. By default, apply partial patches to existing pages; do not rebuild the entire page tree for local changes.
  8. Internal, unparsed, or high-risk model/use that are not approved by schema / graph cannot be written directly.
  9. Do not actively attach / launch the browser unless the user explicitly requests to open the browser, access the page, or perform runtime / smoke validation.
  10. Validation conclusions must be split into
    page shell
    ,
    route-ready
    ,
    readback
    ,
    data
    ,
    runtime
    ; cannot be merged into a single "success".
  11. Live tree patches are prohibited from reparenting via "old uid + new parent/subKey/subType"; when moving, cloning, or remounting business subtrees, fresh remap descendants by default instead of reusing old block uids.
  12. If
    gridSettings.rows
    and
    subModels.items
    members are inconsistent, it is considered a high-risk bad tree; if
    save ok
    but readback does not have stable
    items
    / slot membership, do not report success under any circumstances.

Validation / Review Subpath

Only enter this branch when the user explicitly requests validation / review / improve / smoke:
  • Structured validation rules can be found in references/validation.md
  • Rules for run log, phase/gate, report, improve can be found in references/ops-and-review.md
If the user does not explicitly request browser validation:
  • Only proceed to the route-ready, readback, data-ready stage
  • Mark
    browser_attach
    /
    smoke
    as
    skipped (not requested)
  • Report
    runtime-usable
    as
    not-run

Final Reporting Axes

The final explanation and review report must separately report at least these axes by default:
  • pageShellCreated
  • routeReady
  • readbackMatched
  • dataReady
  • runtimeUsable
  • browserValidation
  • dataPreparation
  • pageUrl
Allowed conservative states include:
  • not-recorded
  • evidence-insufficient
  • skipped (not requested)
  • not-run
Do not write "the page is ready to open" or "has been saved to the database" without route-ready or readback evidence.
If a page was actually created or updated in this round, and the
adminBase
, candidate page URL, or other derivable address can be obtained, the final result must provide the actual page URL for the user to click and view; only explain the blocking reason if it is truly impossible to derive.