メニュー
Use when users need NocoBase backup restore or migration publish operations through nb api backup and nb api migration commands.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
DEFAULT entry point for NocoBase Modern UI authoring or tweaks: new pages, blocks, menu items, and localized edits to blocks, fields, actions, layouts, or reactions on an already-running app via backend flow-surfaces through nb api. Also handles AI employee / AI assistant action placement on UI surfaces. Hand off employee lifecycle work such as discovering, judging, creating, or configuring profile, prompt, model, skills, tools, or knowledge base to nocobase-ai-employee, then return for the UI write. Only hand off to nocobase-dsl-reconciler when the user explicitly asks for DSL, YAML, git, or cli push workflow. Does not handle ACL, data modeling, workflow orchestration, browser reproduction, page error postmortems, or non-Modern page navigation.
Use when users need to inspect, create, revise, enable, or diagnose NocoBase workflows through the `nb` CLI, including trigger selection, node-chain changes, version safety checks, and execution troubleshooting.
Step-by-step playbook for developing a NocoBase plugin, covering scaffolding, server-side code (collections, APIs, ACL, migrations), client-side code (blocks, fields, actions, settings pages, routes, components), i18n, and verification. TRIGGER when: user asks to create, build, implement, or develop a NocoBase plugin, mentions 'NocoBase plugin', or describes a feature to be built as a NocoBase plugin. This skill contains NocoBase-specific conventions and templates that general coding cannot replicate — always invoke it instead of planning from scratch.
General-purpose NocoBase reference utilities covering cross-cutting topics such as evaluator engines, expression syntax, UID generation, and more. Use when you need authoritative reference information or reusable snippets that apply across multiple NocoBase features.
Use when users need to configure, inspect, test, or troubleshoot NocoBase notification management, including in-app message channels, email SMTP channels, workflow notification nodes, and notification send logs.
Use when the task hands over a prototype to reproduce in NocoBase — an HTML file, an image, or a link, INCLUDING the published form "Build a NocoBase app — X … Match the layout and signature visuals of this reference prototype: <url>" — or when someone says a built page "doesn't match the prototype / looks monotone / is ugly". A prototype/URL being present is what triggers this skill, EVEN WHEN the same prompt also says "build an app" — the verb "build" does not cancel the prototype. Skip it only when there is NO prototype at all: a bare "build me a CRM/app" → nocobase-app- discipline; a one-field edit / rename → nocobase-ui-builder. It turns "here is the prototype, build it" into a faithful app — analyze prototype, native CRUD, the right native block per region, then a screenshot-vs-prototype visual loop. Native-first; JS only inside a native container; never a full-page JS block. Mechanics live in nocobase-ui-builder, nocobase-data-modeling, nocobase-app-discipline.
| name | nocobase-publish-manage |
| description | Use when users need NocoBase backup restore or migration publish operations through nb api backup and nb api migration commands. |
| argument-hint | [action: plan|run|validate] [method: backup|migration] [source-env=dev] [target-env=dev] [file?] [rule-id?] |
| allowed-tools | Bash, Read, Grep, Glob |
| owner | platform-tools |
| version | 4.0.0 |
| last-reviewed | "2026-04-30T00:00:00.000Z" |
| risk-level | high |
Orchestrate NocoBase backup restore and migration workflows with the current API CLI command surface.
The skill converts user intent into an API-first publish context, carries generated names and local paths between steps, and requires explicit confirmation before restore or migration execution changes target data.
nb api backup.nb api migration.nb api migration rules.nb api migration logs for diagnosis.source_env=dev and target_env=dev.| Input | Required | Default | Validation | Clarification |
|---|---|---|---|---|
action | yes | inferred | plan, run, or validate | "Should I plan, run, or validate the workflow?" |
method | run: yes | inferred | backup or migration | "Use backup restore or migration publish?" |
source_env | conditional | dev for tests | non-empty env name | "Which environment provides or generates the file?" |
target_env | run: yes | dev for tests | non-empty env name | "Which environment should receive and execute the file?" |
backup_name | optional | unset | backup file name from backup list/create | "Which server backup should be restored or downloaded?" |
migration_name | optional | unset | migration file name from migration list/create | "Which server migration package should be downloaded?" |
local_file | optional | unset | readable local .nbdata path | "Which local package file should be uploaded or executed?" |
cli_home | optional | CLI global home | writable CLI home directory | "Which CLI home should store downloaded release files?" |
rule_id | migration create only | unset | non-empty id | "Which migration rule ID should be used?" |
migration_user_rule | migration rule create only | schema-only | schema-only or overwrite | "How should user-defined tables be handled?" |
migration_system_rule | migration rule create only | overwrite-first | overwrite-first or schema-only | "How should system tables be handled?" |
title | migration create only | publish-<source>-to-<target> | non-empty text | "Which migration title should be used?" |
execute_options | optional | safe CLI defaults | known nb api backup restore* or nb api migration execute flags | "Any high-risk flags such as --skip-backup or --skip-revert-on-error?" |
confirm_publish_input | before create/download/rule create/check | unset | explicit approval | "Confirm the selected input before I create, download, or check the package." |
confirm_execute | before restore/execute/remove | unset | must be confirm | "Type confirm to execute on the target environment." |
method, source_env, and target_env.rule_id.backup or migration.method, sourceEnv, targetEnv, cliHome, releaseDir, backupName, migrationName, localFile, downloadPath, ruleId, title, and step.Not Found, unknown resource, inactive plugin, or license capability errors as unsupported_publish_env.nb api backup restore-upload --file <localFile> -e <targetEnv> --force.nb api backup restore --name <backupName> -e <targetEnv> --force.sourceEnv, download it to <cliHome>/release/<sourceEnv>/<backupName>, then restore-upload that path on targetEnv with --force.targetEnv, then execute it on targetEnv.sourceEnv to <cliHome>/release/<sourceEnv>/<migrationName>, check it on targetEnv, then execute it on targetEnv.sourceEnv, poll migration get until the generated package reports status=ok, download it to <cliHome>/release/<sourceEnv>/<migrationName>, check it on targetEnv, then execute it on targetEnv.backup status, backup restore-status --task <taskId>, migration get, and migration logs.taskId from data.taskId or data.task, then pass that value to backup restore-status --task.See Runtime Contract for exact command construction and parsing rules.
| Reference | Use When |
|---|---|
| Intent Routing | Mapping user phrases to backup, migration, file reuse, and environment shape. |
| Runtime Contract | Building commands and carrying names, paths, rules, and status between steps. |
| Test Playbook | Validating supported API workflows and failure cases. |
High-impact actions:
nb api backup restorenb api backup restore-uploadnb api backup removenb api migration executenb api migration removenb api migration rules create--skip-backup or --skip-revert-on-errorPublish input confirmation template:
Confirm publish input: <method> from <source_env> to <target_env>. Package source: <existing server file | local file | create new>. Migration rule: <ruleId/name | create new with user-defined-rule/system-defined-rule | not applicable>. Reply `confirm input` to continue with package creation, download, or check.
Execution confirmation template:
Confirm execution: <backup restore | migration execute> on <target_env> using <backupName | migrationName | localFile>. This may change target data. Reply `confirm` to continue.
Failure guidance:
data.taskId or data.task, inspect nb api backup restore-status --task <taskId> -e <targetEnv>.migration get reports status=in_progress, tell the user the package is still generating, wait, and do not run migration download until status=ok.nb api migration logs list -e <targetEnv> and relevant logs get/download output.nb api backup and nb api migration command groups.sourceEnv=dev and targetEnv=dev.unsupported_publish_env.backup restore --name when restoring inside the same target environment.backup download followed by backup restore-upload --force.--force directly.<cliHome>/release/<sourceEnv>/.migration check --file before migration execute --file.rule_id.migration rules create uses global rule options.migration rules get when possible.--output.--task <taskId> and are only run after a task id is returned as data.taskId or data.task.