OpenYida
AI-native CLI for building DingTalk Yida low-code applications.
OpenYida connects AI coding agents with Yida's low-code platform, so developers can create apps, forms, workflows, custom pages, reports, integrations, and deployment configuration from a normal chat-driven development workflow.
Quick Start · 帮助网站&文档 · Capabilities · Full Capability List · CLI Reference · Examples · Contributing · Changelog · Application Previews
What OpenYida Provides
OpenYida is a bridge between AI coding tools and Yida. It gives agents a stable openyida CLI to create resources, inspect schemas, generate source code, compile and publish pages, and diagnose issues.
The result remains a native Yida application: teams can continue editing it in Yida, use existing enterprise security controls, and deploy through the Yida platform.
Application Previews
Example applications built with the themes below. Click an image to view it at full size. These are visual references, not ready-made business applications: content, data, brand colors, and layouts are adapted to your requirements.
Dark Rail · Fine Lines![]() |
Soft Inset Surfaces![]() |
Sage![]() |
Teal![]() |
Terminal![]() |
Platinum![]() |
Use an application theme or an independent creative direction. Describe a style you like, or provide a reference website or design image to customize your app’s appearance. Browse more application examples.
Core Capabilities
| Area | What you can do | |------|-----------------| | Application delivery | Create, update, export, and import Yida applications | | Form modeling | Create forms, update fields, inspect schemas, and manage permissions | | Custom pages | Generate React-based pages, lint Yida runtime rules, compile, and publish | | Workflow automation | Create process forms, configure approval flows, preview process instances | | Data operations | Query form/process/task/subform data and run anomaly checks | | Integrations | Manage HTTP connectors, connector actions, auth accounts, and automation flows | | Operations | Diagnose environment issues, manage login state, configure sharing, upload CDN assets |
From Request to Delivery
- Describe the goal. Explain who will use the app, what they need to do, and any existing app or reference material.
- Share requirements and preferences. Add the business details and appearance preferences that matter to you. Include any colors, websites, or design images you like.
- Choose how to build. Fast suits clear requirements you want to move forward with. Plan produces a reviewable proposal and waits for approval before creating resources.
- Review and refine. Check the delivered app and common actions, then request page, field, or workflow changes. Your chosen style is reused unless you ask to change it.
Recent Updates
2026.10.14-1 improves appearance customization, with better support for style descriptions, reference websites, and design images. Read the full changelog.
Quick Start
1. Install
npm install -g openyida
OpenYida requires Node.js 18 or later. The package exposes both openyida and yida commands.
Global npm installations check for updates at most once a day and update automatically. Run openyida update to update manually, or set OPENYIDA_NO_AUTO_UPDATE=1 to keep your installed version.
Auto-update environments and development settings
Local terminals and AI tools share the same policy. Managed cloud Agent runtimes skip automatic updates. For development and testing, OPENYIDA_AUTO_UPDATE_SECS changes the check interval.
If Codex is already installed, OpenYida also imports a local Codex plugin during postinstall. Restart Codex after installation, then type @宜搭 or @openyida in the composer to attach the OpenYida context.
Optional: install DingTalk Workspace CLI (dws)
For DingTalk A2UI authoring, validation or messaging, install the official DingTalk Workspace CLI separately:
npm install -g dingtalk-workspace-cli
dws version
Alternatively, openyida dws install displays official instructions for your platform without running an installer. Once installed, openyida dws forwards arguments to your system's dws.
OpenYida does not bundle or automatically install dws. Dws manages its own version, updates and login. Use dws auth login for DingTalk business access and verify the target organization and account. Native YiDA cool-card creation, reads and editor links work without dws; updating a chat card through dws does not save a YiDA template. See the official instructions for other installation methods and check the installed command's --help before use.
2. Check Your Environment
Run this from the AI coding workspace where you want OpenYida to operate:
openyida agent-capabilities --summary-json
This checks the installed version, login state, and workspace. Use openyida agent-capabilities --json for detailed diagnostics.
3. Log In
openyida login
OpenYida login defaults to OAuth token mode. It opens the DingTalk OAuth authorization page, receives the local loopback callback, exchanges code / authCode with the Yida server, and stores access_token / refresh_token in the user auth store when available. If the user auth store is not writable, OpenYida explicitly falls back to the current project cache and reports that narrower persistence scope.
When the user names a target Yida entry URL, pass it to the login command so OpenYida can select the matching environment and auth profile. For example:
openyida login https://yida-group.alibaba-inc.com/
openyida login --alibaba
For token status checks, use:
openyida login --check-only --json
openyida auth status
In QwenWork web, openyida login --qwenwork --json (or ordinary login) reuses the sandbox identity. If cloud authentication fails, the same command falls back to OAuth; follow its authorization URL and wait for completion. Desktop and other hosts keep their existing login paths.
Login supports DingTalk and QwenWork organizations, ODS and personal spaces. Sessions preserve server-provided identity classification, business domain and refresh credentials. Historical sessions default to DingTalk organizations. JSON errors include bounded diagnostics without credentials or response bodies.
For QwenWork cloud identity diagnostics, run inside the actual cloud execution environment:
openyida auth qwenwork user-info --json
This legacy diagnostic reads the injected host credentials and reports identity and scope without printing or saving tokens. It does not create or validate a YiDA session; QwenWork organization IDs are not YiDA corpId values. Check the YiDA session with openyida login --check-only --json. See QwenWork login guidance for authentication behavior.
To reuse an existing shared login profile for the current project, switch first instead of starting a new OAuth login:
openyida auth profiles
openyida auth profile switch <auth_profile>
If the target profile is not listed, run openyida login to add it, then switch to the new profile.
OpenYida does not install Playwright by default.
4. Build With an AI Agent
Ask your coding agent for a concrete Yida application or workflow:
Create a CRM application in Yida with customer, contact, opportunity, and follow-up forms.
Use Plan mode to design a procurement app with requests, approvals, and dashboards. Show me the proposal first.
Build an oolong tea brand storefront and order management back office, with navigation groups.
Improve the appearance of this existing app. Show me the proposal first, preserve business logic, and back up before changes.
The agent can then call OpenYida commands to create the application, generate source files, publish pages, and return the final Yida URLs. In Codex, QwenWork, Qoder, Qoder IDE, and QoderWork environments, successful creation and publish commands also include a browser handoff so the agent can open the resulting Yida page in the in-app browser. Use --open to force this handoff or --no-open to suppress it.
Supported AI Coding Tools
| Tool | Support | |------|---------| | Codex | Full support | | Claude Code | Full support | | MuleRun | Full support | | Cursor | Full support | | Visual Studio Code | Full support | | QwenWork(千问办公) | Full support | | Qoder | Full support | | Qoder IDE | Full support | | QoderWork | Full support |
How It Works
flowchart LR
A["AI coding agent"] --> B["OpenYida CLI"]
B --> C["Environment detection"]
B --> D["Login and organization context"]
B --> E["Yida API operations"]
B --> F["Local page generation and compile"]
E --> G["Native Yida app"]
F --> G
OpenYida keeps platform-specific behavior inside the CLI, while agents interact with predictable commands and project files.
Project Layout
openyida/
├── bin/yida.js # CLI entry and command routing
├── lib/
│ ├── app/ # Application, form, page, import/export commands
│ ├── auth/ # OAuth token login, token session storage, organization switch
│ ├── connector/ # HTTP connector lifecycle and smart creation
│ ├── core/ # Environment detection, i18n, diagnostics, data commands
│ ├── process/ # Process form creation, configuration, preview
│ ├── report/ # Yida report and chart generation
│ └── samples/ # Reusable code templates emitted by openyida sample
├── project/ # Default workspace template for generated Yida projects
├── yida-skills/ # Source skill docs and Yida API references
└── scripts/ # CI, packaging, and installation helpers
Capabilities
For a user-facing list of supported features and matching CLI commands, see OpenYida 功能完整列表.
Application and Form Management
openyida create-app --name "CRM" --desc "Customer management"
openyida sample yida-design app-theme --output .cache/openyida/crm/app-theme.css
openyida create-app --name "CRM" --desc "Customer management" --theme-file .cache/openyida/crm/app-theme.css --nav-theme light --logo-source appIcon --layout l_shape
openyida app-list --type managed --page 1 --size 16
openyida update-app APP_XXX --theme-file .cache/openyida/crm/app-theme.css --nav-theme light --logo-source appIcon --layout l_shape
openyida corp-efficiency
openyida create-form create APP_XXX "Customer" .cache/openyida/forms/customer-fields.json
openyida create-form update APP_XXX FORM_XXX .cache/openyida/forms/customer-changes.json
openyida create-form update APP_XXX FORM_XXX --data-file .cache/openyida/forms/customer-changes.json
openyida create-form resume APP_XXX FORM_XXX .cache/openyida/forms/customer-fields.json --json
openyida sample openyida-page-template form-fields --output .cache/openyida/forms/customer-fields.json
openyida sample openyida-page-template canvas-form-drawer --output project/pages/src/customer-entry.canvas.jsx --var APP_TYPE=APP_XXX --var FORM_UUID=FORM_XXX
openyida get-schema APP_XXX FORM_XXX
openyida get-schema APP_XXX FORM_XXX --compact --resolve-fields "Customer Name,Status"
openyida get-schema APP_XXX --all --output-dir .cache/schemas
Native forms use a component tree: business fields capture data, tabs switch content, action groups trigger business actions, images establish visual focus, status areas provide feedback, and Divider plus ColumnContainer organize hierarchy and columns. create-form field definitions create 19 business field types plus Divider and ColumnContainer (mapped to ColumnsLayout + Column), while updates retain other existing components.
Custom Page Development
openyida create-page APP_XXX "Dashboard" --mode dashboard
openyida publish pages/src/home.canvas.jsx APP_XXX FORM_XXX
Custom page source is authored directly from PRD and design guidance. Custom page development uses yida-canvas-custom-page and .canvas.jsx.
For member, department, attachment, and image upload components, .canvas.jsx pages should follow yida-canvas-custom-page/references/native-components-bridge.md for feature detection, fallback, and value normalization.
For the current custom page native-component support matrix, see Yida native components supported by custom pages.
Workflow, Data, and Permissions
openyida create-process APP_XXX "Purchase Request" .cache/openyida/process/fields.json .cache/openyida/process/process.json
openyida configure-process APP_XXX FORM_XXX .cache/openyida/process/process.json
openyida process preview APP_XXX PROC_INST_XXX --output .cache/openyida/process/process.html
openyida data query form APP_XXX FORM_XXX --page 1 --size 20
openyida data query form APP_XXX FORM_XXX --dynamic-order '{"dateField_xxx":"-"}'
openyida data query process APP_XXX FORM_XXX --current-approver USER_ID --count
openyida data create form APP_XXX FORM_XXX --expect-form-name 客户 --expect-form-type receipt --data-file .cache/openyida/data-import/record.json
openyida get-permission APP_XXX FORM_XXX
--current-approver takes an exact userId, not a display name. It scans running instances and their current TODO records, counts each matching instance once, and respects the current login's server-authorized data scope. Omit --count to include matching instance data. An incomplete scan or permission failure is reported as an error; the result does not claim application-wide visibility.
Append and forward permissions are configured in the process definition through nodes[].actions.normalActions/appendActions. Both create-process and configure-process compile these settings into matching designer and runtime properties. See approval action configuration for the JSON example, defaults, and verification limits.
configure-process 的流程 JSON 中,审批人可配置为发起人、指定成员、指定角色、部门主管或直属主管,例如:
{
"nodes": [
{
"type": "approval",
"name": "主管审批",
"approver": {
"type": "user",
"users": [{ "id": "manager7350", "name": "九神" }],
"multiApproverType": "all"
}
}
]
}
configure-process 会先通过表单绑定和流程版本只读接口证明 processCode ownership。目标已有 PUBLISHED 流程或 SAVED 草稿时,整图替换必须在人工确认后显式传入 --replace;未确认或 ownership 不匹配时远程写入数为 0。draft/save/publish 均为 one-shot,认证异常返回 NON_IDEMPOTENT_RESULT_UNKNOWN,不得自动重试。
发布成功还必须精确回读同一 PUBLISHED processId/processVersion 的 getProcessById 平台视图,并验证可见节点的组件、名称、顺序和审批模式。只有输出 verificationLevel: "PLATFORM_VIEW_VERIFIED" 才表示平台 view 已验证;PUBLISHED_UNVERIFIED 表示发布可能已生效但回读不完整,不能宣称 processJson 已验证,也不能直接重放写请求。
When creating or updating test data with openyida data, Yida date fields must use 13-digit millisecond timestamps, for example "dateField_xxx": 1719705600000. Do not submit YYYY-MM-DD strings for DateField or CascadeDateField values.
For deterministic query order, pass --dynamic-order '{"fieldId":"+"}' for ascending order or --dynamic-order '{"fieldId":"-"}' for descending order. Without --dynamic-order, searchFormDatas does not guarantee a stable result order; pagination, comparison, and pairing logic must not depend on the default order.
Temporary JSON, CSV, and one-off import scripts should live under .cache/openyida/ so generated run artifacts do not clutter the repository root.
Real Environment E2E
Most checks should stay offline, but OpenYida also includes an explicit real-environment smoke path for release and nightly validation:
OPENYIDA_E2E=1 npm run test:e2e:real
OPENYIDA_E2E=1 npm run test:e2e:real:full
OPENYIDA_E2E=1 OPENYIDA_E2E_FULL_STAGES=auth,app,form,process npm run test:e2e:real:full
npm run test:e2e:real:skills
The runner creates a disposable app, form, and custom page with an OY_E2E_* prefix, then verifies token login, app listing, schema fetch, data query, and page publish. It writes a registry to project/.cache/e2e-real/ so created resources can be audited later. Run openyida login for the target environment before starting the real E2E runner.
test:e2e:real:full extends the smoke path into a broad deterministic feature matrix: auth/env, app update, form update and option mutation, page build/compile/generate/publish, data create/get/update/query, permission read, page config and short URL check, report create/append, dashboard skill verification, export/import, batch, task-center, formula/doctor/sample/CDN config, and local connector parsing/template generation. AI-backed commands such as flash-to-prd are available as the optional ai stage because they depend on remote model availability. Workflow mutation is available as the opt-in process stage; it creates and republishes a workflow on the disposable E2E form and records advanced official-node fixtures for review.
test:e2e:real:skills enforces coverage for every directory under yida-skills/skills/. Each skill must be classified as real E2E, offline/unit, opt-in, or deprecated with an explicit reason. This prevents new skills from quietly bypassing the real-environment test plan.
Each successful full run leaves a human-inspectable result app in the target organization. The final step publishes a dedicated Full E2E Dashboard custom page, renames the app to OY_E2E_*_PASSED by default, and prints direct links for the app, form, dashboard page, and report; the same links are saved under resultApp in the registry JSON.
Useful options:
| Env var | Purpose |
|---------|---------|
| OPENYIDA_E2E_PREFIX | Override the disposable resource name prefix |
| OPENYIDA_E2E_CORP_ID | Switch to the dedicated test organization before creating resources |
| OPENYIDA_E2E_RESULT_APP_NAME | Override the final app name shown as the full-run result |
| OPENYIDA_E2E_BASE_URL | Override the Yida base URL for private deployments |
| OPENYIDA_E2E_FIELDS_FILE | Use a custom form fields fixture |
| OPENYIDA_E2E_PAGE_SOURCE | Use a custom page source for publish verification |
| OPENYIDA_E2E_SKIP_PUBLISH=1 | Skip custom page creation and publish |
| OPENYIDA_E2E_REGISTRY_DIR | Write registries outside project/.cache/e2e-real/ |
| OPENYIDA_E2E_FULL_STAGES | Comma-separated stage list for test:e2e:real:full; use all or omit for the default broad matrix |
Use npm run test:e2e:real:cleanup to list recorded disposable resources. OpenYida does not yet expose a safe app/form deletion command, so cleanup is intentionally a registry-backed audit step rather than an automatic destructive action.
Skill Evaluation Harness
The E2E paths above prove the CLI works. The eval harness under scripts/eval/ measures whether the agent still routes natural-language requests to the right sub-skill and produces good output after you edit yida-skills/SKILL.md. It is the feedback loop for harness engineering.
# Routing eval — "did it pick the right sub-skill?" No real resources, no login.
Drives a headless claude -p agent with each scenario prompt and checks
the selected sub-skill against the golden set.
npm run eval:routing
Doc quality — static analysis of all SKILL.md files (standards + maintainability).
npm run eval:doc-quality
Safety — credential leak detection, command whitelist, corpId consistency.
npm run eval:safety
Coverage — how much of the skill/category/reference space is covered by scenarios.
npm run eval:coverage
Comprehensive — 10-dimension scorecard for a single skill (doc quality, routing,
safety, step completeness, output validity, efficiency, stability, coverage).
Outputs a JSON scorecard, SVG radar chart, and trend analysis.
npm run eval:comprehensive -- --skill yida-dashboard
Tool-pipeline baseline (end-to-end) — wraps the real-environment runner for one
sub-skill, adds guardrail assertions, screenshots the published page, and writes a
human scoring template. Runs deterministic CLI commands (no agent) so it serves as
a control that proves the build→publish→screenshot→score plumbing itself works.
Requires OPENYIDA_E2E=1 and a valid token session.
OPENYIDA_E2E=1 npm run eval:e2e -- --skill yida-dashboard --screenshot
Same, plus automatic screenshot scoring via the local multimodal claude -p.
OPENYIDA_E2E=1 npm run eval:e2e -- --skill yida-dashboard --screenshot --auto-score
Real-generation eval — "can one sentence really build a usable app?" Feeds a
natural-language request ("帮我创建一个订单管理系统") to a headless claude -p
that actually reads the openyida skill and runs the CLI to build a real app, then
reuses the screenshot + scoring + report pipeline. Creates real 宜搭 resources, so
it needs OPENYIDA_E2E=1 + an authenticated agent. Unlike the deterministic baseline
above, here the agent self-orchestrates.
OPENYIDA_E2E=1 npm run eval:generate -- --screenshot
Re-evaluate an archived real CLI trace against the latest scenario contract and
current read-only platform state. This does not run an agent or mutate resources.
npm run eval:replay -- --report <generation-report.json> --scenario <scenario.json> --app-type APP_XXX
Run all three in one pass (routing + tool-pipeline baseline + real generation).
OPENYIDA_E2E=1 npm run eval:all -- --skill yida-dashboard --screenshot
Optional: a zero-dependency local web console (buttons + live streamed output)
that runs the tasks above on click. Binds to 127.0.0.1 only; tasks are a fixed
whitelist. Use the Node version you start it with, so run nvm use 20 first.
npm run eval:dashboard # http://127.0.0.1:4500
Configuration precedence is CLI flag > env (OPENYIDA_EVAL_*) > scripts/eval/eval.config.json > defaults.
| Flag | Purpose |
|------|---------|
| --mode e2e\|routing\|generate\|doc-quality\|safety\|coverage\|comprehensive\|all | Which evals to run (default e2e) |
| --skill | Restrict the e2e run to one sub-skill; stages are reverse-looked-up from the SKILL_COVERAGE matrix |
| --stages a,b | Explicit stage list, overriding the skill reverse-lookup |
| --runs N | Multi-run stability: repeat routing N times, report consistency rate |
| --screenshot / --no-screenshot | Capture the published page (default on; skipped gracefully if Playwright is absent) |
| --auto-score / --no-auto-score | Score screenshots with the local claude -p agent (default off → human template only) |
| --scenarios | Routing golden-set directory (default scripts/eval/scenarios) |
| --gen-scenarios | Real-generation golden-set directory (default scripts/eval/scenarios/generation) |
Results are written back into the existing acceptance-manifest.json under a new eval section (guardrails, screenshots, scores) plus two sibling artifacts: a scoring.md human-scoring template and a self-contained eval-report.html visual report (screenshots inlined as base64, so the single file opens anywhere). Routing results land in project/.cache/eval/routing-report.json; generation results (with their own scoring.md + eval-report.html) land in project/.cache/eval/generate/gen-. The harness degrades gracefully: a missing Playwright skips screenshots (enable with npm install --no-save playwright && npx playwright install chromium), and a missing claude CLI skips auto-scoring while keeping the human template. A guardrail failure (for example a resource-creating command issued before a successful login --check-only) fails the run.
A zero-dependency local dashboard (npm run eval:dashboard, then open http://127.0.0.1:4500) drives these runs from buttons and streams output live; its "📊 查看最新报告" button opens the most recent eval-report.html.
Connectors, Integrations, and Reports
Automation spec sendMessage nodes accept toRoles: [{"roleCode":"REAL_ROLE_ID","roleName":"Finance"}] for NORMAL messages, alongside users and member fields. Process approval, operator, and CC nodes can also select roles. Role selection differs from conditional actor selection, which does not yet have a complete CLI shorthand. See the yida-flow-node-config skill for shared node guidance.
openyida connector smart-create --curl "curl https://api.example.com/users"
openyida connector list
openyida integration create APP_XXX FORM_XXX "Sync customer data"
openyida integration create APP_XXX FORM_XXX "Approval result notify" \
--events processFinish --approval-actions agree,disagree --receivers 123456
Capability probe only; currently fails closed before auth/spec reads/remote writes
openyida integration update APP_XXX FORM_XXX LPROC_XXX \
--spec .cache/openyida/integration/desired-spec.json
openyida create-report APP_XXX "Sales Dashboard" .cache/openyida/reports/charts.json
openyida append-chart APP_XXX REPORT_XXX .cache/openyida/reports/chart.json
Aggregate tables use two independent optimistic-concurrency axes.
openyida aggregate-table inspect APP_XXX FORM_XXX --json
openyida aggregate-table preview APP_XXX FORM_XXX .cache/openyida/aggregate/design.json --json
openyida aggregate-table save APP_XXX FORM_XXX .cache/openyida/aggregate/design.json --json --no-open
openyida aggregate-table publish APP_XXX FORM_XXX .cache/openyida/aggregate/design.json --json --no-open
openyida aggregate-table status APP_XXX FORM_XXX --json
Aggregate-table save verifies the draft stashGmtModified axis; publish verifies the live gmtModified axis. Both commands require the corresponding GET readback revision to advance; when a response revision exists it must equal that readback axis. Both commands also require canonical readback of relationForms, relationships, aggregatedFields, auxFields, formulaFields, and validators. The CLI intentionally does not expose aggregate-table deletion, AI authoring, a high-level design DSL, or tenant-dynamic limits until the corresponding platform contracts are proven.
The opt-in aggregate real-E2E runner additionally requires OPENYIDA_AGGREGATE_E2E_RUN_ID and an exact OPENYIDA_AGGREGATE_E2E_OWNED_MARKER beginning with . Before its first write it verifies the exact list/inspect identity and name, persists a redacted manifest, registry, and baseline snapshot, then conditionally restores the baseline using the latest live revision. Missing ownership proof or concurrent revision movement produces PLATFORM_PROBE_REQUIRED / restore_blocked without a restore write.
CLI Reference
Run openyida --help or openyida for detailed usage.
Report a problem or contribute a fix
Tell your AI: “OpenYida keeps failing. Analyze the cause and prepare feedback.” You can prepare a redacted report and reproduction steps without a GitHub account or a local source checkout. Preparing a report does not submit it.
openyida feedback report --input summary.json --output-dir feedback-draft-001
Your AI prepares the summary from observed evidence and selected reproduction screenshots. PRs include before/after test comparisons. Before anything is published, review the final text and images, confirm sensitive information, and remove anything you do not want to share. See the report input format. Review business information before sharing. With a GitHub account, authorize your AI to submit an Issue or contribute a verified public OpenYida fix through your personal Fork. Without an account, create a GitHub account first. If that is not possible, share the report in the AI开发者群 (AI developer group).
To configure a submission tool, your AI can first run openyida feedback github setup --json to check gh and the current account. After you approve the installation plan, it can run openyida feedback github setup --install --confirm --json, using existing Homebrew on macOS/Linux or WinGet on Windows. Without a supported manager, official instructions or the web remain available. Browser authorization is a separate step performed by you; installation does not log you in, request passwords or tokens, or replace public-content approval. Resume the original draft after setup. See the account and tool guide.
When preparing a PR that needs a personal Fork, or when you ask how to support the project, the feedback Skill can inspect account support state with openyida feedback github status --json. Star and a personal Fork are optional: feedback github star --confirm and feedback github fork --confirm run only after you choose them. Existing actions are reused. This check is separate from installation and automatic updates; neither action is required to submit an Issue.
Auth & Environment
| Command | Description |
|---------|-------------|
| openyida login [--qwenwork] [target-url] [--env | Login with OAuth token mode |
| openyida logout | Logout / unbind current project auth |
| openyida auth | Token login state and profile management |
| openyida org | Organization management (list / switch existing profiles first) |
| [--json] [--corp-id
openyida env [--json\|setup\|list\|show\|switch\|add\|remove] [options] | Detect AI tool environment & token login state |
App Management
| Command | Description |
|---------|-------------|
| openyida app-settings | Read theme, frontend/backend, native data card and cool card management links |
| openyida cool-card | Create and read native YiDA cool cards (interactive and pinned) |
|
openyida data-card | Create, configure, publish and distribute native YiDA data cards |
|
openyida plugin | Manage YiDA platform plugin versions, installation state, and runtime registrations |
| openyida app-entry get | Read frontend and management runtime entries |
| openyida app-entry set | Register application entries with partial update and readback |
| openyida app-list [--type managed\|created] [--page N] [--size N] | Page through apps I manage or created |
| openyida solution-template | Solution templates for independent local agents: discovery, cloud AI handoff and direct enable |
| openyida corp-efficiency [overview\|details\|detail\|groups\|notify] [options] [--open\|--no-open] | Query enterprise efficiency overview and detail reports |
| openyida create-app " | Create a Yida app |
| openyida design-plan catalog [--json] | List available planning themes and page patterns |
| openyida design-plan init | Initialize a plan draft from confirmed requirements |
| openyida design-plan preview | Update plan drafts by module |
| openyida design-plan materialize | Generate or update plan documents and theme with consistency checks |
| openyida design-plan patch | Patch plan fields and optionally sync documents and theme |
| openyida update-app | Update app info |
| openyida data-manage-style guide [--json] | Inspect data-management UI directions, tokens and scoped CSS guidance |
| openyida data-manage-style list [--json] | List optional data-management recipe examples |
| openyida data-manage-style generate --app | Generate data-management CSS from an optional recipe (local only) |
| openyida app-theme snapshot | Archive application theme settings and CSS (read-only) |
| openyida app-theme restore | Check or restore an application theme snapshot (supported exact values only) |
| openyida upgrade-app-theme | Upgrade an AI-built legacy app theme (explicit request and ask_human confirmation required) |
| openyida app-online | Enable a Yida app |
| openyida app-offline | Disable a Yida app |
| openyida nav-group | Manage app sidebar navigation groups |
|
openyida app-permission | Manage app primary, data, and developer admins |
| openyida i18n | Manage app multilingual copy and language config |
| openyida export | Export app (generate migration package) |
| openyida import | Import migration package, rebuild app |
Forms & Pages
| Command | Description |
|---------|-------------|
| openyida create-form batch | Create forms concurrently by dependency |
| openyida create-form create | Create a form page |
| openyida create-form icons [--json] | List available form navigation icons |
| openyida create-form validate-fields | Validate form field JSON locally |
| openyida create-form update | Update a form page |
| openyida create-form resume | Update a form page |
| openyida create-form patch | Update a form page |
| openyida create-form rule | Update a form page |
| openyida create-form validation | Update a form page |
| openyida add-validation | Update a form page |
| openyida create-form bind-datasource | Update a form page |
| openyida create-form add-option | Update a form page |
| openyida list-forms | List forms/pages in an app |
| openyida aggregate-table | Manage aggregate tables (virtualView) |
|
openyida print-template | Manage native YiDA print templates, generate document layouts, back up, restore and request PDFs |
|
--detail-url
openyida form-view | Native form views: list, inspect and configure columns, widths, frozen columns and filters |
|
openyida custom-button | Native custom buttons: inspect and configure form edits, automation flows and page links |
|
openyida form-message | Native form notifications: inspect triggers, recipients and templates, then safely maintain bindings |
|
openyida get-schema | Get one form Schema or all form Schemas |
| openyida check-prd-completeness | Check resources, frontend menu hiding and application theme delivery |
| openyida check-design | Validate design documents, theme tokens and PRD handoff |
| openyida er | Export app entity relationship diagram |
| openyida create-page | Create a custom display page |
| openyida build-page | Build Yida-compatible page source |
| openyida check-page | Check custom page standards |
| openyida compile | Compile custom page locally |
| openyida publish | Compile and publish custom page |
| openyida update-form-config | Update form configuration |
| openyida get-form-config | Query form configuration |
Data & Permissions
| Command | Description |
|---------|-------------|
| openyida data | Unified data management (form/process/task/subform) |
| openyida task-center | Global task center (todo/processed/cc etc.) |
| openyida basic-info | Query organization basic info, capacity, quotas, and domain settings |
| openyida read-dingtalk-doc | Fetch Markdown content from a DingTalk document |
| openyida read-dingtalk-tingji | Fetch DingTalk Tingji details by task UUID |
| openyida get-permission | Query form permission config |
| openyida save-permission | Save form permission config |
| openyida permission-manage | Copy, rename or delete a permission group |
| openyida matrix | Manage permission matrix definitions, references and rows |
| [matrixId] [--file config.json] [--page 1] [--limit 20] [--expect hash] [--dry-run] [--confirm]
openyida corp-manager | Manage platform admins and address book permissions |
| openyida agent-center | Manage process and departure delegation | ...
Process
| Command | Description |
|---------|-------------|
| openyida configure-process | Configure and publish process rules; Supports append/forward via JSON nodes[].actions.normalActions/appendActions |
| openyida create-process | Create process form (all-in-one); Supports append/forward via JSON nodes[].actions.normalActions/appendActions |
| openyida ai-form-setting | Manage process form AI approval prompts |
| openyida process preview | Preview process instance (visual flowchart) |
| openyida process fields | Check process designer field loading and subtable field paths |
Page Config & Sharing
| Command | Description |
|---------|-------------|
| openyida verify-short-url | Verify short URL |
| openyida save-share-config | Save public access / share config |
| openyida get-page-config | Query page public access config |
| openyida externalize-form | Plan external access-safe mirror fields |
Reports
| Command | Description |
|---------|-------------|
| openyida create-report | Create a Yida report |
| openyida append-chart | Append chart to existing report |
| openyida report inspect | Inspect report runtime bindings (read-only) |
| openyida report configure | Configure dynamic zero-value hiding on a native bar chart (explicit opt-in) |
Connectors
| Command | Description |
|---------|-------------|
| openyida connector list | List HTTP connectors |
| openyida connector create "name" "domain" ... | Create a connector |
| openyida connector detail | View connector details |
| openyida connector delete | Show manual deletion guidance (CLI does not delete) |
| openyida connector add-action --operations | Add an action |
| openyida connector update-action --connector-id | Safely update action query defaults |
| openyida connector list-actions | List actions |
| openyida connector delete-action | Delete an action |
| `openyi
... (README truncated for length)





