원클릭으로
nocobase-env-manage
Use when users need NocoBase bootstrap, runtime lifecycle, CLI maintenance, and skills maintenance with nb CLI only.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Use when users need NocoBase bootstrap, runtime lifecycle, CLI maintenance, and skills maintenance with nb CLI only.
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-env-manage |
| description | Use when users need NocoBase bootstrap, runtime lifecycle, CLI maintenance, and skills maintenance with nb CLI only. |
| argument-hint | [task: install|app-manage|upgrade|start|stop|restart|logs|down|self-check|self-update|skills-check|skills-update] |
| allowed-tools | Bash, Read, Write, Grep, Glob |
| owner | platform-tools |
| version | 2.6.0 |
| last-reviewed | "2026-04-29T00:00:00.000Z" |
| risk-level | medium |
Use nb CLI only to complete NocoBase bootstrap, lifecycle, and maintenance actions.
nb init.nb env.nb app.nb CLI through nb self.nb skills.nb commands.*.mjs, *.ps1, *.sh).task=install, if the user provides an official NocoBase install or quick-start URL, read that URL first and follow the official guide flow. Ignore local install command tables when they conflict with the official guide.task=install, use nb init --ui as the guided install entrypoint unless the current official guide says otherwise.nb init --ui is not a completion condition. Keep following CLI output until setup reaches a finished state or the CLI exits with an actionable failure.nb init --ui, use a CLI timeout of 30 minutes and do not interrupt the command before it exits.nb init ... --resume ..., execute that exact direct nb command unless it is destructive or conflicts with the user's latest instruction.nb app <command> for runtime lifecycle operations.nb self <command> only for CLI self-check/update.nb skills <command> only for installed skills check/update.nb commands.nb --help when user asks for diagnostics/help output or command discovery is needed.installapp-manageupgradestopstartrestartlogsdownself-checkself-updateskills-checkskills-update| Input | Required | Default | Notes |
|---|---|---|---|
task | yes | inferred | one of install/app-manage/upgrade/start/stop/restart/logs/down/self-check/self-update/skills-check/skills-update |
app_env_action | for task=app-manage | list | one of add/use/current/list/remove; current is derived from list output |
app_env_name | conditional | none | required for add/use/remove |
app_base_url | conditional | none | required for add; accepts URL with or without /api (auto-normalized) |
cli_auth_mode | for env add | oauth | one of oauth/token |
app_token | conditional | none | required when cli_auth_mode=token |
runtime_env_name | optional for upgrade/start/stop/restart/logs/down | current env | explicit runtime env name |
nb command directly.nb init --ui as the guided install entrypointtask=install, treat nb init --ui as a long-running interactive command:
nb init --ui prints a local URL and browser open fails in sandbox, first ask to elevate/open outside sandbox; if that is declined, surface the URL so the user can open it manually.nb init ... --resume ... command next. Do not rerun a fresh setup unless the CLI asks for it or the user explicitly requests it.list/current), use fast path:
nb env list*nb env --help / nb env list --help are available when command discovery is needed.nb env info [name] and inspect app/database/API status.env add, normalize API base URL before execution:
/api, keep as-is/apiself-check -> nb self check --jsonself-update -> nb self update --yesskills-check -> nb skills check --jsonskills-update -> nb skills update --yesnb self check --json and nb skills check --json when reporting results.self-update or skills-update, run the matching check command as readback unless the CLI says the shell/session must be restarted first.When the user says generic status/check/update/upgrade wording without an explicit target, do not infer a command.
Ambiguous examples include:
检查状态检查一下健康检查诊断一下检查更新升级更新修复Ask which target they mean before executing:
nb env list, nb env info, or nb app ...nb self check --json or nb self update --yesnb skills check --json or nb skills update --yesClarification template:
你想检查/更新哪一类:NocoBase app/runtime/env、nb CLI,还是已安装 skills?Treat these as clear targets:
nb self check --jsonself-check or skills-update检查 nb CLI, 更新已安装 skills, 升级 NocoBase app, 检查当前环境For upgrade/start/stop/restart/logs/down:
runtime_env_name is provided, pass --env <env>.--env and follow CLI response.nb commands from the current command map or from CLI-provided continuation hints.nb env list, nb env info, and app/database status when relevant.nb self / nb skills commands exactly as mapped.nb init --ui
nb env list
nb env info
Install is done only when the CLI reports readiness/completion, such as NocoBase is ready ... and Workspace init finished, or equivalent success output from the current official guide.
nb env list
nb env info [name]
For current, derive from the row marked with leading * in nb env list output. Do not call nb env current.
When CLI returns:
No envs configured.Run 'nb env add <name> --api-base-url <url>' to add one.surface this message directly and ask whether to create a new app (nb init --ui) or add env.
nb env add <name> --api-base-url <url> --auth-type oauth
<url> uses normalized value (auto-append /api when missing).
nb env add <name> --api-base-url <url> --auth-type token --access-token <token>
<url> uses normalized value (auto-append /api when missing).
nb env use <name>
nb env remove <name>
Write actions (add/use/remove) must always be followed by:
nb env list
Use nb env remove <name> -f only after explicit user confirmation.
nb env auth [name]
nb app upgrade [--env <env>]
Optional:
nb app upgrade [--env <env>] --skip-code-update
nb app stop [--env <env>]
nb app start [--env <env>]
Optional:
nb app start --env <env> --quickstart
nb app start --env <env> --port <port>
nb app start --env <env> --daemon
nb app start --env <env> --no-daemon
nb app restart [--env <env>]
nb app logs [--env <env>] [--tail <lines>] [--no-follow]
nb app down [--env <env>]
nb self check --json
Use this for nb CLI health/version/update checks. No env is required.
nb self update --yes
nb self check --json
Run the update command first. Run the check command afterward as readback unless the CLI says a new shell/session is required.
nb skills check --json
Use this for installed NocoBase skills health/version/update checks. No env is required.
nb skills update --yes
nb skills check --json
Run the update command first. Run the check command afterward as readback unless the CLI says a new shell/session is required.
upgrade on ambiguous env.upgrade when user intent is not explicit.nb app down as destructive because it removes runtime containers and saved local app files. Always ask explicit confirmation before running it.--all or --yes to nb app down unless the user explicitly requests those flags.nb self update --yes and nb skills update --yes as allowed update shortcuts only when the user clearly requests CLI or skills update.npm, pnpm, yarn) for nb self update --yes or nb skills update --yes.Confirmation template:
Confirm execution: nb app upgrade --env <env>. Reply confirm to continue.Require explicit user confirmation before:
nb app upgrade when the target env is ambiguous or the user did not clearly request an upgrade.nb app down in all cases.nb env remove <name> -f.--all, --yes, or force-style deletion flags, except exact nb self update --yes / nb skills update --yes commands when the user clearly requested that update.Final response must include:
env add)| Reference | Use When |
|---|---|
| Usage Guide | Mapping user intent to current nb commands. |
| Install Runbook | Executing install/bootstrap flows, especially official URL and resume handling. |
| Upgrade Runbook | Upgrading app runtimes with nb app upgrade. |
| Preflight Checklist | Optional diagnostics when explicitly requested. |
| Troubleshooting | Recovering from CLI errors and version mismatch symptoms. |
nb init --ui was not treated as complete when only a setup URL appeared.nb init ... --resume ... continuation was followed or surfaced with a blocker.nb app ....nb env syntax.nb self check --json or nb self update --yes.nb skills check --json or nb skills update --yes.nb env list and, when relevant, nb env info.