@josephyan/qingflow-app-user-mcp 0.2.0-beta.54 → 0.2.0-beta.56

package/README.md

@@ -3,13 +3,13 @@
 Install:
 
 ```bash
-npm install @josephyan/qingflow-app-user-mcp@0.2.0-beta.54
+npm install @josephyan/qingflow-app-user-mcp@0.2.0-beta.56
 ```
 
 Run:
 
 ```bash
-npx -y -p @josephyan/qingflow-app-user-mcp@0.2.0-beta.54 qingflow-app-user-mcp
+npx -y -p @josephyan/qingflow-app-user-mcp@0.2.0-beta.56 qingflow-app-user-mcp
 ```
 
 Environment:
@@ -23,7 +23,10 @@ This package bootstraps a local Python runtime on first install and then starts
 Bundled skills:
 
 - `skills/qingflow-app-user`
-- `skills/qingflow-record-crud`
+- `skills/qingflow-record-insert`
+- `skills/qingflow-record-update`
+- `skills/qingflow-record-delete`
+- `skills/qingflow-record-import`
 - `skills/qingflow-task-ops`
 - `skills/qingflow-record-analysis`
 

package/docs/local-agent-install.md

@@ -1,9 +1,10 @@
 # 本地智能体安装
 
-这个目录下现在只保留两个本地命令入口：
+这个目录下现在有三个本地命令入口：
 
-1. 记录/待办优先的 `qingflow-app-user-mcp`
-2. 精简 builder 的 `qingflow-app-builder-mcp`
+1. 统一 CLI：`qingflow`
+2. 记录/待办优先的 `qingflow-app-user-mcp`
+3. 精简 builder 的 `qingflow-app-builder-mcp`
 
 ## npm 安装器适用场景
 
@@ -62,6 +63,7 @@ npm run pack:npm
 会生成：
 
 ```bash
+dist/npm/josephyan-qingflow-cli-<version>.tgz
 dist/npm/josephyan-qingflow-app-user-mcp-<version>.tgz
 dist/npm/josephyan-qingflow-app-builder-mcp-<version>.tgz
 ```
@@ -69,6 +71,7 @@ dist/npm/josephyan-qingflow-app-builder-mcp-<version>.tgz
 然后在目标机器安装：
 
 ```bash
+npm install /absolute/path/to/dist/npm/josephyan-qingflow-cli-<version>.tgz
 npm install /absolute/path/to/dist/npm/josephyan-qingflow-app-user-mcp-<version>.tgz
 npm install /absolute/path/to/dist/npm/josephyan-qingflow-app-builder-mcp-<version>.tgz
 ```
@@ -78,7 +81,7 @@ npm install /absolute/path/to/dist/npm/josephyan-qingflow-app-builder-mcp-<versi
 1. 创建 `.npm-python/`
 2. 在其中建立 Python 虚拟环境
 3. 执行 `pip install .`
-4. 在安装位置暴露 `qingflow-app-user-mcp`、`qingflow-app-builder-mcp` 命令
+4. 在安装位置暴露 `qingflow`、`qingflow-app-user-mcp`、`qingflow-app-builder-mcp` 命令
 
 ## 本地验证
 
@@ -86,6 +89,7 @@ npm install /absolute/path/to/dist/npm/josephyan-qingflow-app-builder-mcp-<versi
 
 ```bash
 cd qingflow-support/mcp-server
+node ./npm/bin/qingflow.mjs --help
 node ./npm/bin/qingflow-app-user-mcp.mjs
 node ./npm/bin/qingflow-app-builder-mcp.mjs
 ```
@@ -93,6 +97,7 @@ node ./npm/bin/qingflow-app-builder-mcp.mjs
 如果你是全局安装：
 
 ```bash
+qingflow --help
 qingflow-app-user-mcp
 qingflow-app-builder-mcp
 ```
@@ -100,6 +105,7 @@ qingflow-app-builder-mcp
 如果你是把包安装到了某个本地 agent workspace，命令通常位于：
 
 ```bash
+/absolute/path/to/agent-workspace/node_modules/.bin/qingflow
 /absolute/path/to/agent-workspace/node_modules/.bin/qingflow-app-user-mcp
 /absolute/path/to/agent-workspace/node_modules/.bin/qingflow-app-builder-mcp
 ```
@@ -107,6 +113,7 @@ qingflow-app-builder-mcp
 如果你是从 tgz 安装到某个空目录，命令通常位于：
 
 ```bash
+/absolute/path/to/install-dir/node_modules/.bin/qingflow
 /absolute/path/to/install-dir/node_modules/.bin/qingflow-app-user-mcp
 /absolute/path/to/install-dir/node_modules/.bin/qingflow-app-builder-mcp
 ```
@@ -202,7 +209,7 @@ qingflow-app-builder-mcp
 ```
 
 说明：
-- 源码目录 `npm install` 不会把命令加到全局 PATH；这种模式请用 `node ./npm/bin/qingflow-app-user-mcp.mjs` 或 `node ./npm/bin/qingflow-app-builder-mcp.mjs`
+- 源码目录 `npm install` 不会把命令加到全局 PATH；这种模式请用 `node ./npm/bin/qingflow.mjs`、`node ./npm/bin/qingflow-app-user-mcp.mjs` 或 `node ./npm/bin/qingflow-app-builder-mcp.mjs`
 - `npx` 方式适合临时安装或容器化本地 agent
 - 全局安装方式更适合长期固定使用的本机开发环境
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@josephyan/qingflow-app-user-mcp",
-  "version": "0.2.0-beta.54",
+  "version": "0.2.0-beta.56",
   "description": "Operational end-user MCP for Qingflow records, tasks, comments, and directory workflows.",
   "license": "MIT",
   "type": "module",

package/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "qingflow-mcp"
-version = "0.2.0b54"
+version = "0.2.0b56"
 description = "User-authenticated MCP server for Qingflow"
 readme = "README.md"
 license = "MIT"
@@ -46,6 +46,7 @@ build = [
 [project.scripts]
 qingflow-app-user-mcp = "qingflow_mcp.server_app_user:main"
 qingflow-app-builder-mcp = "qingflow_mcp.server_app_builder:main"
+qingflow = "qingflow_mcp.cli.main:main"
 
 [project.urls]
 Homepage = "https://github.com/qingflow/qingflow-mcp"

package/skills/qingflow-app-user/SKILL.md

@@ -16,28 +16,40 @@ Assumes MCP is connected, authenticated, and on the correct workspace.
 
 Route to exactly one of these specialized paths:
 
-1. Record CRUD and import  
-   Switch to [$qingflow-record-crud](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-record-crud/SKILL.md)
+1. Record insert  
+   Switch to [$qingflow-record-insert](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-record-insert/SKILL.md)
 
-2. Task workflow operations  
+2. Record update  
+   Switch to [$qingflow-record-update](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-record-update/SKILL.md)
+
+3. Record delete  
+   Switch to [$qingflow-record-delete](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-record-delete/SKILL.md)
+
+4. Record import  
+   Switch to [$qingflow-record-import](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-record-import/SKILL.md)
+
+5. Task workflow operations  
    Switch to [$qingflow-task-ops](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-task-ops/SKILL.md)
 
-3. Analysis  
+6. Analysis  
    Switch to [$qingflow-record-analysis](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-record-analysis/SKILL.md)
 
-4. MCP connection / auth / workspace selection  
+7. MCP connection / auth / workspace selection  
    Switch to [$qingflow-mcp-setup](/Users/yanqidong/.codex/skills/qingflow-mcp-setup/SKILL.md)
 
 ## Routing Rules
 
 - If the user does not know the target `app_key`, discover apps first with `app_list` or `app_search`, then route to the specialized skill
 - If the app is known but the available data range is unclear, call `app_get` first and inspect `accessible_views`
-- If the task is about browsing, reading, creating, updating, deleting, attachments, relations, subtable writes, member/department-field candidate lookup, code-block field execution, import templates, import capability discovery, import-file verification, authorized local file repair, import execution, or import status, switch to `$qingflow-record-crud`
+- If the task is about creating or new record entry, switch to `$qingflow-record-insert`
+- If the task is about editing an existing record directly, switch to `$qingflow-record-update`
+- If the task is about deleting records directly, switch to `$qingflow-record-delete`
+- If the task is about import templates, import capability discovery, import-file verification, authorized local file repair, import execution, or import status, switch to `$qingflow-record-import`
 - If the task is about todo discovery, task context, approval actions, rollback or transfer, associated report review, or workflow log review, switch to `$qingflow-task-ops`
-- If the task is about creating new records or importing data, prefer `$qingflow-record-crud` under applicant-node create semantics
-- If the task is about updating an existing record directly, route to `$qingflow-record-crud`, which uses `record_update` and defaults to `system:all` before requiring an explicit accessible `view_id`
-- If the task involves member, department, or relation fields and the user only has natural names/titles, still route to `$qingflow-record-crud`; direct write now supports backend-native auto resolution and may return `needs_confirmation` with candidates instead of failing blind
-- If the task is about subtable writes, still route to `$qingflow-record-crud`, but shape the payload through the parent subtable field `rows/tableValues`; do not route users toward top-level leaf selectors
+- If the task involves member, department, or relation fields and the user only has natural names/titles, keep the same route; direct write now supports backend-native auto resolution and may return `needs_confirmation` with candidates instead of failing blind
+- If the task involves linked visibility, upstream/downstream field dependencies, reference-driven auto fill, or formula-driven defaulting, keep the same insert/update route and read field-level `linkage` from the schema before composing payloads
+- If the task is about subtable writes, still route to the matching insert/update skill, but shape the payload as parent subtable field -> row array; do not route users toward top-level leaf selectors
+- If the task is insert-focused and readback consistency matters, keep the same route and prefer `record_get / record_list` with `output_profile="normalized"` after the write
 - If the user sounds like an ordinary workflow assignee rather than a system operator, prefer `$qingflow-task-ops` over direct record mutation whenever both paths could fit
 - If the task is about grouped distributions, ratios, rankings, trends, insights, or any final statistical conclusion, switch to `$qingflow-record-analysis`
 - If the MCP is not connected, authenticated, or bound to the right workspace, switch to `$qingflow-mcp-setup`
@@ -46,6 +58,7 @@ Route to exactly one of these specialized paths:
 
 - prefer canonical app ids, record ids, task ids, and workflow node ids over guessed names
 - if a field or target is still ambiguous after schema/task lookup, ask the user to confirm from a short candidate list instead of guessing
+- if schema fields include `linkage.sources` or `linkage.affects_fields`, treat those as the preferred high-level explanation of field dependencies instead of trying to infer hidden front-end logic
 - if the task can stay read-only, do not write or act
 - if the task involves a user-uploaded import file, do not modify the file unless the user explicitly authorizes repair or normalization
 - if the task involves record import, call `app_get` first and inspect `data.import_capability` before template download, file repair, or import start
@@ -59,5 +72,8 @@ Route to exactly one of these specialized paths:
 
 ## Resources
 
-- Record CRUD: [$qingflow-record-crud](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-record-crud/SKILL.md)
+- Record insert: [$qingflow-record-insert](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-record-insert/SKILL.md)
+- Record update: [$qingflow-record-update](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-record-update/SKILL.md)
+- Record delete: [$qingflow-record-delete](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-record-delete/SKILL.md)
+- Record import: [$qingflow-record-import](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-record-import/SKILL.md)
 - Dedicated analysis workflow: [$qingflow-record-analysis](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-record-analysis/SKILL.md)

package/skills/qingflow-app-user/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Qingflow App User"
-  short_description: "Route Qingflow operational tasks to CRUD, task ops, or analysis"
-  default_prompt: "Use $qingflow-app-user as a router: switch to $qingflow-record-crud for record browse/read/write, switch to $qingflow-task-ops for task-center, comments, directory, and workflow usage actions, and switch to $qingflow-record-analysis for grouped analysis or final statistical conclusions."
+  short_description: "Route Qingflow operational tasks to insert, update, delete, import, task ops, or analysis"
+  default_prompt: "Use $qingflow-app-user as a router: switch to $qingflow-record-insert for new record entry, $qingflow-record-update for direct edits, $qingflow-record-delete for deletes, $qingflow-record-import for bulk import, $qingflow-task-ops for task-center, comments, directory, and workflow usage actions, and $qingflow-record-analysis for grouped analysis or final statistical conclusions."

package/skills/qingflow-app-user/references/data-gotchas.md

@@ -6,43 +6,24 @@ For final statistics, grouped distributions, rankings, trends, or insight-style
 
 - `record_list` is for browsing, export, and sample inspection only
 - `record_get` is for one exact record
+- Use `record_browse_schema_get` when field titles are uncertain instead of guessing ids
 - Do not present paged browse output as if it were a grouped or full-population conclusion
-- If the browser and MCP disagree, compare `request_route.base_url` and `request_route.qf_version` first
 
-## Write Preflight
+## Direct Writes
 
-- `record_insert`, `record_update`, and `record_delete` always perform internal static preflight before any apply
+- `record_insert` is schema-first through `record_insert_schema_get`
+- `record_update` is schema-first through `record_update_schema_get`
+- `record_delete` does not need a schema-get step
 - If a direct-write tool returns `ok=false`, the write was blocked and not executed
-- Use `record_schema_get` when field titles are uncertain instead of guessing ids
 - Prefer `verify_write=true` for complex, relation-heavy, subtable, or production writes
-- Even when a direct-write tool returns `ok=true`, it may still surface verification failures; do not report success before checking them
 
-## Write Semantics
+## Lookup Fields
 
-- `record_insert` uses an applicant-node `fields` map
-- `record_update` uses a view-scoped `fields` map
-- `record_delete` uses `record_id` or `record_ids`
-- Do not fake formula or expression fields
-- Do not guess relation targets from display text; resolve the real `record_id` first
+- Member / department / relation fields may accept natural text, but MCP may return `needs_confirmation`
+- Do not guess ids when the response returns candidate options
+- Retry only after the user confirms the explicit candidate
 
-## Attachments
+## Subtables and Attachments
 
-- Attachment fields are two-step: upload first, then write the returned URL object into the record
-- `file_upload_local` may report `effective_upload_kind=login` even when the requested kind was `attachment`; this is an implementation fallback, not necessarily an error
-- When debugging uploads, surface both `effective_upload_kind` and `upload_protocol`
-
-## Subtables
-
-- Subtable fields accept row objects keyed by subfield title, or native `tableValues`
-- Use the current form schema's subfield titles; do not guess nested ids
-- When updating existing subtable rows, preserve row ids if the source record returns them
-- Nested subtable writes are still unsupported
-
-## Unsupported Direct-Write Fields
-
-- `14` time range
-- `34` image recognition
-- `35` image generation
-- `36` document parsing
-
-Do not fake values for these fields in app-user writes. Stop and explain the limitation.
+- Subtable payloads stay under the parent table field as a row array
+- Attachment fields are two-step: upload first, then write the returned upload payload

package/skills/qingflow-app-user/references/record-patterns.md

@@ -4,106 +4,45 @@ If the task shifts into grouped analysis, ratio, ranking, trend, or any final st
 
 ## Browse Pattern
 
-Use `record_schema_get -> record_list` when:
+Use `record_browse_schema_get -> record_list` when:
 
 - the user wants to browse records
 - the target `record_id` is unknown
-- a delete or update target still needs confirmation
+- a delete target still needs confirmation
 - the user needs sample rows or a small export
 
-Keep the browse DSL simple:
-
-- `columns`: field ids only
-- `where`: flat AND filters only
-- `order_by`: field sorting only
-- `limit` and `page`: browsing intent only
-
-Do not use `record_list` for grouped conclusions, ratios, rankings, trends, or any final statistical claim.
-
 ## Detail Pattern
 
-Use `record_schema_get -> record_get` when:
+Use `record_browse_schema_get -> record_get` when:
 
 - the exact `record_id` is known
 - the user needs one record in detail
 - a write target needs verification before action
 
-Prefer passing explicit `columns` when the user only needs a subset of fields.
+## Insert Pattern
 
-## Write Pattern
-
-Use `record_schema_get -> record_insert / record_update / record_delete`.
+Use `record_insert_schema_get -> record_insert`.
 
 1. Confirm the target app
-2. Resolve fields with `record_schema_get`
-3. Decide whether the task is `insert`, `update`, or `delete`
-4. Build a field-title keyed `fields` map for insert/update
-5. Run `record_insert`, `record_update`, or `record_delete`
-6. If `ok=false`, explain `field_errors` first, then summarize blockers; stop because the write was not executed
-7. If `ok=true`, report the affected resource and any verification outcome
-8. For important writes, keep `verify_write=true`
-
-### Insert
-
-```json
-{
-  "app_key": "APP_1",
-  "fields": {
-    "客户名称": "测试客户",
-    "合同金额": 1000
-  },
-  "submit_type": "submit",
-  "verify_write": true
-}
-```
-
-### Update
-
-```json
-{
-  "app_key": "APP_1",
-  "record_id": 123,
-  "fields": {
-    "合同金额": 2000
-  },
-  "view_id": "system:all",
-  "verify_write": true
-}
-```
-
-### Delete
-
-```json
-{
-  "app_key": "APP_1",
-  "record_ids": [123, 124]
-}
-```
-
-## Write Anti-Patterns
-
-Do not do this:
-
-- do not send raw SQL text
-- do not build free-form `WHERE` updates or deletes
-- do not invent formulas or expressions
-- do not auto-fill missing required fields
-- do not guess relation targets without first resolving them
-- do not claim a blocked direct write was executed
-
-## Unsupported Direct Writes
-
-Do not attempt direct app-user writes for these field types:
-
-- `14` time range
-- `34` image recognition
-- `35` image generation
-- `36` document parsing
-
-If the payload includes them, stop after the blocked response and explain that the tool does not support a reliable direct write for those fields yet.
-
-## Relation, Attachment, and Subtable Rules
-
-- Relation fields are record-id based. Resolve the referenced target first, then write the relation field with the real `record_id`.
-- Attachment fields are two-step: upload first with `file_upload_local`, then reuse the returned attachment payload in `record_insert` or `record_update`.
-- Subtable writes require the current schema shape; when updating existing subtable rows, preserve row ids if the current record exposes them.
+2. Read `required_fields`, `optional_fields`, `runtime_linked_required_fields`, and `payload_template`
+3. Build a field-title keyed `fields` map
+4. If lookup fields are ambiguous, stop and ask for confirmation
+5. Run `record_insert`
+
+## Update Pattern
+
+Use `record_update_schema_get -> record_update`.
+
+1. Confirm the target app and `record_id`
+2. Read `writable_fields` and `payload_template`
+3. Update only fields present in `writable_fields`
+4. Let MCP auto-select the first matched accessible view that can execute the payload
+5. Run `record_update`
+
+## Delete Pattern
+
+Use `record_list / record_get -> record_delete`.
+
+1. Confirm the exact `record_id`
+2. Run `record_delete`
+3. Do not invent range deletes from guessed browse results

package/skills/qingflow-record-analysis/SKILL.md

@@ -9,15 +9,15 @@ metadata:
 
 This skill is for final statistical conclusions only.
 Assumes MCP is connected, authenticated, and on the correct workspace.
-Analysis tasks must start with `app_get`, then `record_schema_get(schema_mode="browse", view_id=...)`. Read top-level `fields` and `suggested_*`, then build field_id-based DSLs only.
-Analysis tasks must start with `record_schema_get`.
+Analysis tasks must start with `app_get`, then `record_browse_schema_get(view_id=...)`. Read top-level `fields` and `suggested_*`, then build field_id-based DSLs only.
+Analysis tasks must start with `record_browse_schema_get`.
 If `app_get.accessible_views` marks a view with `analysis_supported=false`, do not use that view for `record_list` or `record_analyze`. `boardView` and `ganttView` are special UI views, not list/analyze targets.
 
-## Step 1: `app_get` → Step 2: `record_schema_get(schema_mode="browse", view_id=...)` → Step 3: build DSL → Step 4: `record_analyze`
+## Step 1: `app_get` → Step 2: `record_browse_schema_get(view_id=...)` → Step 3: build DSL → Step 4: `record_analyze`
 
 This is the ONLY execution order. Never skip `app_get` when the browse range is unclear. Never call `record_analyze` without a browse schema.
 
-Core tools: `app_get`, `record_schema_get`, `record_analyze`. Use `record_list`/`record_get` only for post-analysis samples; task/comment work stays in [$qingflow-task-ops](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-task-ops/SKILL.md).
+Core tools: `app_get`, `record_browse_schema_get`, `record_analyze`. Use `record_list`/`record_get` only for post-analysis samples; task/comment work stays in [$qingflow-task-ops](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-task-ops/SKILL.md).
 
 ---
 

package/skills/qingflow-record-analysis/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Qingflow Record Analysis"
   short_description: "Analyze Qingflow record data with schema-first DSL execution"
-  default_prompt: "Use $qingflow-record-analysis for grouped distributions, ratios, rankings, trends, and final statistical conclusions in Qingflow apps. Start with record_schema_get, build one or more field_id-based DSLs, then run record_analyze. Treat record_list as sample-only when capped or paged, and separate full conclusions from sample observations."
+  default_prompt: "Use $qingflow-record-analysis for grouped distributions, ratios, rankings, trends, and final statistical conclusions in Qingflow apps. Start with record_browse_schema_get, build one or more field_id-based DSLs, then run record_analyze. Treat record_list as sample-only when capped or paged, and separate full conclusions from sample observations."

package/skills/qingflow-record-analysis/references/analysis-gotchas.md

@@ -6,7 +6,7 @@ If the task is analysis-style and you jump straight to `record_list` or `record_
 
 Correct recovery:
 
-1. `record_schema_get`
+1. `record_browse_schema_get`
 2. inspect the schema and choose fields
 3. build one or more small DSLs
 4. run `record_analyze`
@@ -75,7 +75,7 @@ If the field is uncertain:
 
 Correct recovery:
 
-1. `record_schema_get`
+1. `record_browse_schema_get`
 2. if several plausible candidates remain, ask the user to confirm from a short list
 3. build the DSL only after the field is clear
 

package/skills/qingflow-record-analysis/references/analysis-patterns.md

@@ -15,7 +15,7 @@ Use this skill when the user asks for:
 
 ## Canonical analysis sequence
 
-1. `record_schema_get`
+1. `record_browse_schema_get`
 2. decide whether the question needs `count`, `sum`, `avg`, `distinct_count`, `ratio`, or `ranking`
 3. build one or more field_id-based DSLs
 4. `record_analyze`
@@ -30,11 +30,11 @@ Result reading order:
 5. `completeness`
 6. `presentation`
 
-Treat `record_schema_get` as applicant-node visible-only schema. Missing fields are permission boundaries, not invitations to guess hidden ids.
+Treat `record_browse_schema_get` as the browse-schema source of truth. Missing fields are permission boundaries, not invitations to guess hidden ids.
 
 ## Distribution / ratio pattern
 
-1. Run `record_schema_get`
+1. Run `record_browse_schema_get`
 2. Inspect candidate fields and aliases
 3. If several plausible candidates remain, stop and ask the user to confirm the field from a short list
 4. Build a DSL with:
@@ -51,7 +51,7 @@ Treat `record_schema_get` as applicant-node visible-only schema. Missing fields
 
 ## penetration / conversion / share-of-total pattern
 
-1. Run `record_schema_get`
+1. Run `record_browse_schema_get`
 2. Write down the business definition in plain language:
    - numerator
    - denominator
@@ -64,7 +64,7 @@ Treat `record_schema_get` as applicant-node visible-only schema. Missing fields
 
 ## Average / ranking pattern
 
-1. Run `record_schema_get`
+1. Run `record_browse_schema_get`
 2. Choose one dimension field and one numeric metric field
 3. Build a DSL with:
    - `dimensions=[...]`
@@ -76,7 +76,7 @@ Treat `record_schema_get` as applicant-node visible-only schema. Missing fields
 
 ## Trend pattern
 
-1. Run `record_schema_get`
+1. Run `record_browse_schema_get`
 2. Choose a date/time field from `suggested_time_fields`
 3. Build a DSL with `bucket=day|week|month|quarter|year`
 4. Run `record_analyze`
@@ -109,7 +109,7 @@ Never use list mode alone to justify final averages, shares, rankings, or region
 
 If the user asks for something like “来源分布” or “类型占比” and the exact field is unclear:
 
-1. run `record_schema_get`
+1. run `record_browse_schema_get`
 2. inspect titles, aliases, and suggested fields
 3. if one candidate is clearly dominant, proceed
 4. if multiple candidates are still plausible, ask the user to confirm which field they want

package/skills/qingflow-record-analysis/references/confidence-reporting.md

@@ -12,7 +12,7 @@ When analysis is intended as a final answer, use this order:
 
 Only write `全量可信结论` when:
 
-- `record_schema_get` was used
+- `record_browse_schema_get` was used
 - the analysis path used one or more `record_analyze` calls
 - every key analysis result has `safe_for_final_conclusion=true`
 - `safe_for_final_conclusion=true is necessary but not sufficient`
@@ -30,7 +30,7 @@ Put evidence into `样本观察` when:
 
 ## Downgrade rule
 
-If `record_schema_get` was not used for an analysis task, downgrade the overall framing to `初步观察` instead of `洞察` or `结论`.
+If `record_browse_schema_get` was not used for an analysis task, downgrade the overall framing to `初步观察` instead of `洞察` or `结论`.
 
 ## Anti-mixing rule
 

package/skills/qingflow-record-analysis/references/dsl-templates.md

@@ -1,6 +1,6 @@
 # DSL Templates
 
-Use these copy-paste templates after `record_schema_get`.
+Use these copy-paste templates after `record_browse_schema_get`.
 
 ## Whole-table summary
 

package/skills/qingflow-record-delete/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: qingflow-record-delete
+description: Delete Qingflow records safely after the MCP is already connected and authenticated.
+metadata:
+  short-description: Qingflow record delete
+---
+
+# Qingflow Record Delete
+
+## Default Path
+
+`record_list / record_get -> record_delete`
+
+## Core Tools
+
+- `record_list`
+- `record_get`
+- `record_delete`
+
+## Working Rules
+
+1. Resolve the exact target `record_id` first
+2. Prefer reading the current state before delete when the request is high risk
+3. Call `record_delete` with `record_id` or `record_ids`
+
+## Do Not
+
+- Do not pass any `view_*` selector
+- Do not infer the target record id from a vague title if `record_list` can disambiguate it

package/skills/qingflow-record-import/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: qingflow-record-import
+description: Explain and operate Qingflow file-based bulk import after the MCP is already connected and authenticated.
+metadata:
+  short-description: Qingflow bulk import workflow and troubleshooting
+---
+
+# Qingflow Record Import
+
+## Default Path
+
+`app_get -> record_import_schema_get -> record_import_template_get -> record_import_verify -> (optional authorized repair) -> record_import_start -> record_import_status_get`
+
+## Core Tools
+
+- `app_get`
+- `record_import_schema_get`
+- `record_import_template_get`
+- `record_import_verify`
+- `record_import_repair_local`
+- `record_import_start`
+- `record_import_status_get`
+
+## Working Rules
+
+1. Inspect `app_get.data.import_capability` first
+2. Read `record_import_schema_get` before touching the file when column meaning is unclear
+3. Keep official headers unchanged
+4. Verify before start
+5. Only repair a file after explicit user authorization
+6. Read back one imported sample after success