@josephyan/qingflow-app-user-mcp 1.1.24 → 1.1.26

package/skills/qingflow-app-builder-code-integrations/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: qingflow-app-builder-code-integrations
+description: Configure Qingflow code block and Q-Linker fields through the builder surface when the task involves input field insertion, alias parsing, target field binding, or troubleshooting broken code/q-linker form configurations. Use after MCP is connected and authenticated, especially for CRM-style scoring, lookup, and enrichment forms.
+metadata:
+  short-description: Configure Qingflow code blocks and Q-Linkers safely
+---
+
+# Qingflow App Builder Code Integrations
+
+Use this skill when the user wants to build or repair:
+- `code_block` fields
+- `q_linker` fields
+- output alias parsing
+- target field binding
+- form configurations that depend on code block or Q-Linker relations
+
+Do not use this skill for MCP setup, generic field CRUD, or runtime execution debugging unless those are strictly supporting code block or Q-Linker configuration work.
+
+## Core Rule
+
+Treat code blocks and Q-Linkers as **integration fields**, not ordinary fields.
+
+For both of them, the public builder request may look like one step, but the real backend form structure has multiple layers. Never invent a new backend meaning. Only compile into the backend structures that already exist.
+
+## Mental Model
+
+### Code block
+
+There are three conceptual layers:
+
+1. Code block field itself
+2. Parsed output aliases
+3. Target field bindings
+
+Current builder support:
+- configure the code block field itself
+- configure input insertion into code content
+- configure alias parsing
+
+Important:
+- keep `qf_output = {...}` as a plain assignment
+- do not emit `const qf_output =` or `let qf_output =`
+
+### Q-Linker
+
+There are two conceptual layers:
+
+1. Q-Linker field itself via `remoteLookupConfig`
+2. Target field bindings via relation-default + `questionRelations(relationType=Q_LINKER)`
+
+Current builder support:
+- one-step high-level config through `q_linker_binding`
+- internal compilation into existing backend payloads
+
+## Operating Order
+
+For code block or Q-Linker work, use this order:
+
+1. Resolve the app and read fields:
+   - `app_resolve`
+   - `app_read_fields`
+2. Confirm the target field set already exists.
+3. Apply schema updates with `app_schema_apply`.
+4. Read fields again and verify:
+   - field type
+   - alias config
+   - target field binding shape
+5. For page-safety checks, use user-side schema or insert checks:
+   - `record_insert_schema_get`
+   - optional safe `record_insert`
+
+Do not treat raw apply success as enough. Always re-read the field config.
+
+## Code Block Rules
+
+Read [references/code-block.md](references/code-block.md) before changing a code block field.
+
+Use builder high-level config only for:
+- input field insertion
+- code content
+- alias parsing
+- auto trigger
+- custom button text
+
+When binding outputs to target fields, do not guess payload shape from memory. Follow the current builder implementation and the readback shape.
+
+Hard rules:
+- target fields must already exist
+- keep target field types business-compatible
+- if a page starts hanging on “关联中”, inspect whether the target field default type or relation config was written incorrectly
+
+## Q-Linker Rules
+
+Read [references/q-linker.md](references/q-linker.md) before changing a Q-Linker field.
+
+First-stage stable support is only:
+- custom mode
+- request config
+- alias parsing
+- target field binding
+- auto trigger / button text
+
+Do not generate:
+- template mode
+- openApp/light-wing branches
+- subtable table-match bindings
+
+Hard rules:
+- `outputs[*].target_field` is required
+- use only supported target field types
+- on rebinding, old target fields must be restored from relation-default to safe default type
+- `resultFormatPath` must preserve backend-required alias metadata
+
+## Verification Checklist
+
+After each code block or Q-Linker change, verify all of these:
+
+- `app_read_fields` shows the intended field type
+- the high-level config is readable and stable
+- target fields still have valid types
+- insert schema can be opened
+- record insert does not get blocked by malformed integration config
+
+If the task explicitly includes runtime verification, keep it separate from configuration verification.
+
+## Common Pitfalls
+
+- Writing code block code with `const qf_output =`
+- Treating a Q-Linker or code block binding as a plain field default
+- Forgetting to restore old target fields after unbinding
+- Using unsupported target field types
+- Assuming apply success means the form page can open
+
+## References
+
+- Code block details: [references/code-block.md](references/code-block.md)
+- Q-Linker details: [references/q-linker.md](references/q-linker.md)

package/skills/qingflow-app-builder-code-integrations/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Qingflow Code Integrations"
+  short_description: "Configure Qingflow code block and Q-Linker fields safely"
+  default_prompt: "Use $qingflow-app-builder-code-integrations when configuring Qingflow code block or Q-Linker fields, especially when input insertion, alias parsing, target field binding, or page-safety verification matter."

package/skills/qingflow-app-builder-code-integrations/references/code-block.md

@@ -0,0 +1,66 @@
+# Code Block Builder Notes
+
+## What Builder Should Configure
+
+- code block field type
+- code content
+- inserted input fields inside code content
+- alias parsing
+- auto trigger
+- custom button text
+
+## Stable Writing Rules
+
+- Always emit `qf_output = {...}`
+- Never emit `const qf_output = {...}`
+- Never emit `let qf_output = {...}`
+
+## Useful CRM Pattern
+
+Inputs:
+- customer name
+- source
+- budget
+- timing
+- decision-maker flag
+
+Outputs:
+- score
+- level
+- priority
+- summary
+- next follow date
+
+## Target Field Rules
+
+Required:
+- every `outputs[*].target_field` must point to an existing field
+
+Allowed target field types:
+- text
+- long text
+- number
+- amount
+- date
+- datetime
+- single select
+- multi select
+- boolean
+
+Do not bind code block outputs to:
+- q_linker
+- code_block
+- relation
+- subtable
+- attachment
+- member
+- department
+- address
+
+## Safe Verification
+
+- `app_read_fields`
+- `record_insert_schema_get`
+- optional `record_code_block_run`
+
+Treat configuration verification and runtime verification as separate checks.

package/skills/qingflow-app-builder-code-integrations/references/q-linker.md

@@ -0,0 +1,77 @@
+# Q-Linker Builder Notes
+
+## What Builder Should Configure
+
+- `remoteLookupConfig`
+- alias parsing
+- target field binding
+- auto trigger
+- custom button text
+
+## Current Supported Scope
+
+- custom mode only
+- standard request fields
+- alias path parsing
+- target field binding to existing ordinary fields
+
+## Recommended Public APIs For Samples
+
+### Httpbin
+
+- URL: `https://httpbin.org/get`
+- Good for:
+  - query echo
+  - request URL echo
+
+Useful paths:
+- `$.args.keyword`
+- `$.url`
+
+### Open-Meteo Geocoding
+
+- URL: `https://geocoding-api.open-meteo.com/v1/search`
+- Good for:
+  - place normalization
+  - country
+  - lat/lng summary
+
+Useful paths:
+- `$.results[0].name`
+- `$.results[0].country`
+- `$.results[0].latitude`
+- `$.results[0].longitude`
+
+## Target Field Rules
+
+Required:
+- every `outputs[*].target_field` must point to an existing field
+
+Prefer:
+- text
+- long text
+- number
+- amount
+- date
+- datetime
+- single select
+- multi select
+- boolean
+
+Avoid:
+- q_linker
+- code_block
+- relation
+- subtable
+- attachment
+- member
+- department
+- address
+
+## Safe Verification
+
+- `app_read_fields`
+- `record_insert_schema_get`
+- `record_insert`
+
+This verifies that the configuration does not break the form page, even before runtime execution is tested.

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

@@ -1,67 +1,64 @@
 ---
 name: qingflow-app-user
-description: Route Qingflow end-user requests to the right specialized operational skill using the current Wingent Momo runtime MCP session. Use when the task is operational but it is not yet clear whether it is record CRUD or final analysis.
+description: Route Qingflow end-user requests to the right specialized operational skill after the MCP is already connected and authenticated. Use when the task is operational but it is not yet clear whether it is record CRUD or final analysis.
 metadata:
   short-description: Router for Qingflow operational skills
 ---
 
 # Qingflow App User
 
-> **Skill 版本**：`qingflow-skills-2026.06.24.2`（入口文档版本；如需确认 CLI 包版本，使用 `qingflow --version` 或 `qingflow --json version`）。
-
 ## Overview
 
 This skill is a lightweight router for operational Qingflow work.
-In Wingent Momo runtime, trust injected MCP credentials, workspace, and route context until a business tool explicitly reports otherwise.
+Assumes MCP is connected, authenticated, and on the correct workspace.
 Before routing, skim the shared maintenance baseline: [public-surface-sync.md](references/public-surface-sync.md).
 
 ## Default Paths
 
 Route to exactly one of these specialized paths:
 
-1. Record insert
+1. Record insert  
    Switch to [$qingflow-record-insert](../qingflow-record-insert/SKILL.md)
 
-2. Record update
+2. Record update  
    Switch to [$qingflow-record-update](../qingflow-record-update/SKILL.md)
 
-3. Record delete
+3. Record delete  
    Switch to [$qingflow-record-delete](../qingflow-record-delete/SKILL.md)
 
-4. Record import
+4. Record import  
    Switch to [$qingflow-record-import](../qingflow-record-import/SKILL.md)
 
-5. Task workflow operations
+5. Task workflow operations  
    Switch to [$qingflow-task-ops](../qingflow-task-ops/SKILL.md)
 
-6. Analysis
+6. Analysis  
    Switch to [$qingflow-record-analysis](../qingflow-record-analysis/SKILL.md)
 
-7. Standalone MCP setup or explicit auth/workspace recovery
+7. MCP connection / auth / workspace selection  
    Switch to [$qingflow-mcp-setup](../qingflow-mcp-setup/SKILL.md)
 
 8. App / view / workflow / chart / portal / package configuration
-   This is outside the App User MCP tool surface. Use the separate `qingflow-app-builder` skill/MCP package when that builder surface is installed; otherwise ask the user to enable the builder MCP.
+   Switch to [$qingflow-app-builder](../qingflow-app-builder/SKILL.md)
 
 ## Routing Rules
 
-- If the user does not know the target `app_key`, discover apps first with `app_list` / `app list --query` over current-user visible apps, then route to the specialized skill; do not use the legacy app search path for ordinary members
+- 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 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 package, app, field, layout, workflow, view, chart, portal, visibility, icon, or app base configuration, do not continue with App User MCP tools. Use the separate `qingflow-app-builder` skill/MCP package when available, or ask the user to enable the builder MCP.
+- If the task is about package, app, field, layout, workflow, view, chart, portal, visibility, icon, or app base configuration, switch to `$qingflow-app-builder`
 - 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
-- For member/department field ambiguity, keep the record insert/update route and use `record_member_candidates` / `record_department_candidates`; do not switch to `directory_*`, builder member search, external-contact lookup, or contact-directory management queries. App User MCP only exposes `directory_search` for member-visible keyword search, not directory tree/list management.
 - 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/detail context matters, keep the same route and prefer the single-record detail readback after the write; use normalized list readback only when batch row shape is needed
 - 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 task discovery by natural language query, still route to `$qingflow-task-ops`; `task_list --query` now uses backend search first and only falls back to local matching when backend returns zero rows
 - If the task is about grouped distributions, ratios, rankings, trends, insights, or any final statistical conclusion, switch to `$qingflow-record-analysis`
-- In Wingent Momo runtime, do not route to `$qingflow-mcp-setup` as a preflight. Switch there only when a business tool explicitly reports missing auth, invalid session, or wrong/missing workspace, or when the user asks to configure a standalone MCP client.
+- If the MCP is not connected, authenticated, or bound to the right workspace, switch to `$qingflow-mcp-setup`
 
 ## Shared Preconditions
 
@@ -89,4 +86,4 @@ Route to exactly one of these specialized paths:
 - Record import: [$qingflow-record-import](../qingflow-record-import/SKILL.md)
 - Task workflow operations: [$qingflow-task-ops](../qingflow-task-ops/SKILL.md)
 - Dedicated analysis workflow: [$qingflow-record-analysis](../qingflow-record-analysis/SKILL.md)
-- Builder workflow requires the separate `qingflow-app-builder` skill/MCP package.
+- Builder workflow: [$qingflow-app-builder](../qingflow-app-builder/SKILL.md)

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

@@ -9,12 +9,12 @@ For final statistics, grouped distributions, rankings, trends, or insight-style
 - `record_get` is for one exact record and downloads readable detail-page images into `media_assets.items[].local_path` plus attachments/documents/tables into `file_assets.items[].local_path`
 - 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
-- Use `record_export_direct` only when the user explicitly asks for export/download/Excel output, and always pass an explicit `view_id` from `app_get.accessible_views` or the frontend URL
+- Use `record_export_direct` only when the user explicitly asks for export/download/Excel output
 
 ## Direct Writes
 
 - `record_insert` is schema-first through `record_insert_schema_get`; default to `items=[{"fields": {...}}]`
-- `record_update` is detail-first: read `record_get`, compose the requested title-keyed `fields` map, then write directly; use `record_update_schema_get` only after update failure or ambiguity
+- `record_update` is schema-first through `record_update_schema_get`
 - `record_delete` does not need a schema-get step
 - For batch insert, `partial_success` means some rows were created; use `created_record_ids`, failed `row_number`, and `failed_fields` to repair only failed rows
 - If a direct-write tool returns `write_executed=false`, the write was blocked and not executed for that item

package/skills/qingflow-app-user/references/public-surface-sync.md

@@ -1,6 +1,6 @@
 # Qingflow Core Public Surface Sync
 
-Use this file as the maintenance baseline for the core Qingflow skills.
+Use this file as the maintenance baseline for the core Qingflow skills.  
 It is not a user-facing product spec. It exists to prevent skill drift.
 
 ## Current Public Defaults
@@ -12,9 +12,9 @@ It is not a user-facing product spec. It exists to prevent skill drift.
 - Standard flows:
   - analyze: `app_get -> record_browse_schema_get -> record_access -> Python`
   - browse detail: `app_get -> record_browse_schema_get -> record_list / record_get`
-  - explicit export/download/Excel: `app_get -> choose view_id -> view_get -> record_export_*` or `record_export_direct`; export tools require explicit `view_id`
+  - explicit export/download/Excel: `view_get -> record_export_*` or `record_export_direct`
   - insert: `record_insert_schema_get -> record_insert(items)`
-  - update: `record_get -> record_update`; use `record_update_schema_get` only for failure diagnosis or ambiguous writable-field routing
+  - update: `record_update_schema_get -> record_update`
 
 ### Tasks
 

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

@@ -41,13 +41,13 @@ Use `record_insert_schema_get -> record_insert(items)`.
 
 ## Update Pattern
 
-Use `record_get -> record_update`.
+Use `record_update_schema_get -> record_update`.
 
 1. Confirm the target app and `record_id`
-2. Read `record_get` in the same view/context the user is using when a `view_id` is known
-3. Build a field-title keyed `fields` map from `record_get.fields[]` and the user's requested changes
-4. Run `record_update` directly; let MCP auto-select the executable update route
-5. If `record_update` fails because fields/routes are ambiguous or unavailable, then use `record_update_schema_get` as a diagnostic tool
+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
 

package/skills/qingflow-app-user/references/workflow-usage.md

@@ -14,12 +14,13 @@ Examples:
 
 Rules:
 
-- if the user starts from inbox, todo, workload, cc, or bottleneck language, use the public task tools first
-- use `task_list` for headline counts and flat browsing; group locally by app or workflow node when buckets matter
-- use `task_get`, `task_workflow_log_get`, and `task_associated_report_detail_get` only after locating the exact task
+- if the user starts from inbox, todo, workload, cc, or bottleneck language, use `task_*` first
+- use `task_summary` for headline counts
+- use `task_list` for flat browsing
+- use `task_facets` when worksheet or workflow-node buckets matter
 - treat task counts as task-center counts, not record counts
 - switch to `record_*` only after locating the exact business record behind a task
 - identify the exact target first
-- for approve or reject, identify the exact target first; prefer `task_id` from task-center results, then use `task_action_execute` with action `approve` or `reject`
+- for approve or reject, identify the exact `workflow_node_id` first; prefer task-center results or current audit info, then use `task_approve` or `task_reject`
 - avoid usage-side workflow actions on ambiguous records
 - summarize the final action and target task ids or record ids

package/skills/qingflow-mcp-setup/SKILL.md

@@ -7,8 +7,6 @@ metadata:
 
 # Qingflow MCP Setup
 
-> **Skill 版本**：`qingflow-skills-2026.06.24.2`（入口文档版本；如需确认 CLI 包版本，使用 `qingflow --version` 或 `qingflow --json version`）。
-
 ## Overview
 
 This skill sets up the local Qingflow MCP server, connects it to a local AI client, and verifies authentication and workspace selection. Use it for installation, client configuration, token login, and connection troubleshooting.
@@ -75,26 +73,24 @@ cd <repo_root>/qingflow-support/mcp-server
 
 Prefer validating through the client after config is added.
 
-### Step 5: Use injected session first; authenticate only for setup or recovery
-
-For Wingent Momo runtime conversations, the session normally already carries the credential-derived token, workspace, and route context. Do not run `auth_use_credential`, `auth_login`, `workspace_list`, or `workspace_select` before ordinary business tools. Start with the smallest read-only business call that fits the task; if it succeeds, continue.
+### Step 5: Authenticate and select workspace
 
-For a standalone local MCP client that has no injected session, use this setup order:
+Recommended order inside the client:
 
-1. `auth_use_credential` or `auth_login`
+1. `auth_use_token` or `auth_login`
 2. `workspace_list`
 3. `workspace_select`
-4. Run a small read-only business tool
+4. Only then use business tools
 
-`auth_use_credential` gets the selected workspace from the credential context. If the user needs a different workspace after authentication, use `workspace_list` and then `workspace_select`.
+If the user already knows the target workspace, prefer `auth_use_token(..., ws_id=<id>)`.
 After auth, prefer one read-only tool call that returns `request_route` so you can confirm the live `base_url` and `qf_version` before proceeding.
-`auth_use_credential` is a tool call, not a custom HTTP header. It exchanges the createClaw credential for a Qingflow token, `wsId`, and when needed `Cookie: qfVersion=...` after the session is established.
-Do not run `workspace_select` on production paths unless the user explicitly asks to switch workspace or a business tool clearly reports that no workspace is selected. If `/user` does not return a version lane, the session now falls back to the workspace `systemVersion`.
+`auth_use_token` is a tool call, not a custom HTTP header. The runtime injects `token`, `wsId`, and when needed `Cookie: qfVersion=...` after the session is established.
+Do not skip `workspace_select` on production paths. If `/user` does not return a version lane, the session now falls back to the workspace `systemVersion`.
 
 ### Step 6: Troubleshoot in the right layer
 
 - If the client cannot launch the server, check path, execute permission, and `.venv`
-- If tools return `auth required`, re-run `auth_use_credential` or `auth_login`
+- If tools return `auth required`, re-run `auth_use_token` or `auth_login`
 - If tools return `workspace not selected`, call `workspace_list` and `workspace_select`
 - If calls fail after a working session, assume token expiry and re-authenticate
 - If the browser shows data but MCP does not, compare `request_route` against the browser environment and check whether `qf_version` should be `canary`
@@ -102,7 +98,7 @@ Do not run `workspace_select` on production paths unless the user explicitly ask
 ## Guardrails
 
 - Never write tokens into the skill files
-- In Wingent Momo runtime, trust injected workspace context until a business tool proves otherwise; for standalone clients, confirm workspace with `auth_whoami`, `workspace_select`, or a successful read-only business call.
+- Never assume a workspace is selected until `auth_whoami` or `workspace_select` confirms it
 - When debugging, distinguish server startup issues from Qingflow auth issues
 - When the user mentions production, restate the exact `base_url`, `qf_version`, and workspace before any live validation
 - If setup is complete but the current MCP capability is still unsupported or the user's need still cannot be satisfied, summarize the gap, ask whether to submit feedback, and call `feedback_submit` only after explicit user confirmation

package/skills/qingflow-mcp-setup/references/claude-desktop.md

@@ -31,4 +31,4 @@ Keep separate snippets for `test` and `prod` so switching environments does not
 - Replace `<ABSOLUTE_PATH_TO_REPO>` with the real checkout path on the current machine
 - If the server path changes, update the `command` field
 - The server is local stdio MCP, so no remote URL is required
-- Do not store Qingflow credentials in Claude Desktop config; pass the createClaw credential through `auth_use_credential` inside the chat, or use `auth_login` when credential exchange is unavailable
+- Do not store Qingflow token in Claude Desktop config; pass it through `auth_use_token` inside the chat

package/skills/qingflow-mcp-setup/references/environments.md

@@ -28,8 +28,7 @@ Known values in the current workspace:
 Setup behavior:
 
 - prefer this environment for Claude Desktop or local MCP client onboarding
-- for Wingent Momo runtime, use the injected session and skip auth/workspace preflight
-- for standalone MCP client setup, use `auth_use_credential` or `auth_login`, then `workspace_list`, then `workspace_select`
+- use `auth_use_token` or `auth_login`, then `workspace_list`, then `workspace_select`
 - if the user asks to verify installation, a real read-only smoke path is acceptable
 
 ## Production Environment

package/skills/qingflow-mcp-setup/references/generic-stdio.md

@@ -19,14 +19,13 @@ Keep separate client entries or separate config snippets for `test` and `prod`.
 
 1. Start the client
 2. Confirm the `qingflow` MCP server is visible
-3. In Wingent Momo runtime, skip auth/workspace preflight and run a read-only tool such as `app_list`
-4. In a standalone client without injected credentials, run `auth_use_credential` or `auth_login`
-5. Then run `workspace_list`
-6. Then run `workspace_select`
-7. Run a read-only tool such as `app_list`
+3. Run `auth_use_token`
+4. Run `workspace_list`
+5. Run `workspace_select`
+6. Run a read-only tool such as `app_list`
 
 ## Common failures
 
 - Launch failure: bad `command` path or missing `.venv`
-- Auth failure: invalid or expired credential/token
+- Auth failure: invalid or expired token
 - Business tool failure before setup: workspace not selected

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

@@ -1,14 +1,12 @@
 ---
 name: qingflow-record-analysis
-description: Analyze Qingflow record data safely. Use when the user wants grouped distributions, ratios, averages, rankings, trends, insights, comparisons, or any final statistical conclusion across an existing app's data. Default to schema-first record_access CSV retrieval plus local Python/pandas; do not use export tools unless the user explicitly asks for a file download.
+description: Analyze Qingflow record data safely after the MCP is already connected and authenticated. Use when the user wants grouped distributions, ratios, averages, rankings, trends, insights, comparisons, or any final statistical conclusion across an existing app's data. Default to schema-first record_access CSV retrieval plus local Python/pandas; do not use export tools unless the user explicitly asks for a file download.
 metadata:
   short-description: Analyze Qingflow record data with record_access CSV and Python
 ---
 
 # Qingflow Record Analysis
 
-> **Skill 版本**：`qingflow-skills-2026.06.24.2`（入口文档版本；如需确认 CLI 包版本，使用 `qingflow --version` 或 `qingflow --json version`）。
-
 Use this skill only for final statistical conclusions: counts, distributions, ratios, averages, rankings, trends, comparisons, and analysis reports.
 
 Default path, every time:
@@ -22,7 +20,7 @@ app_get -> record_browse_schema_get(view_id=...) -> record_access -> Python/pand
 ```bash
 qingflow record --help
 qingflow record access --help
-qingflow --json record access --app-key APP_KEY --view-id VIEW_ID --columns-file columns.json --where-file where.json --order-by-file order_by.json
+qingflow record access --app-key APP_KEY --view-id VIEW_ID --columns-file columns.json --where-file where.json --order-by-file order_by.json --json
 ```
 
 The CLI command is under the `record` command group, so the discovery path is: first inspect `qingflow record --help`, then inspect `qingflow record access --help`.
@@ -39,10 +37,10 @@ The CLI command is under the `record` command group, so the discovery path is: f
 - Before final analysis, run a field-quality profile in pandas: row count, null rate, distinct count, and period coverage for candidate grouping fields.
 - Do not use a high-missing field as the main conclusion dimension. If a candidate dimension is sparse, downgrade it to an `已填写样本观察` and choose a cleaner semantic fallback when available.
 - Full final conclusions require `record_access.complete=true` and `record_access.safe_for_final_conclusion=true`.
-- `record_list` is only for sample inspection after the aggregate result is understood; its `data.items[]` rows are flat field-title keyed objects, not nested `fields[]`.
+- `record_list` is only for sample inspection after the aggregate result is understood.
 - `record_get` is only for single-record detail verification, logs, references, images, or readable attachments. Read images from `media_assets.items[].local_path`; read documents/tables from `file_assets.items[].local_path` and `extraction.text_path`.
 - `record_export_direct` is only for explicit export/download/Excel requests.
-- `chart_get` / QingBI is only for user-provided report URLs or chart ids. If it reports `CHART_BASE_INFO_UNAVAILABLE` but `chart_data_loaded=true`, treat the chart data as readable and only the metadata/base info as degraded.
+- `chart_get` / QingBI is only for user-provided report URLs or chart ids.
 
 ## Tool Selection
 
@@ -51,7 +49,7 @@ The CLI command is under the `record` command group, so the discovery path is: f
 | Batch analysis, statistics, comparison, report | `record_access -> Python` |
 | Browse a few example rows | `record_list` |
 | Inspect one record, logs, references, images, attachments | `record_get` |
-| User asks to export/download/Excel | `record_export_direct` with explicit `view_id` |
+| User asks to export/download/Excel | `record_export_direct` |
 | User gives report URL or chart id | `chart_get` |
 | Todo/workflow task actions | `$qingflow-task-ops` |
 
@@ -86,12 +84,13 @@ CSV columns are already readable and field-id anchored, for example `项目状
 For CLI use, write JSON argument files instead of embedding large JSON in shell text:
 
 ```bash
-qingflow --json record access \
+qingflow record access \
   --app-key APP_KEY \
   --view-id system:all \
   --columns-file columns.json \
   --where-file where.json \
-  --order-by-file order_by.json
+  --order-by-file order_by.json \
+  --json
 ```
 
 ## Status Handling

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

@@ -1,14 +1,12 @@
 ---
 name: qingflow-record-delete
-description: Delete Qingflow records safely using the current Wingent Momo runtime MCP session; recover auth/workspace only after a tool error.
+description: Delete Qingflow records safely after the MCP is already connected and authenticated.
 metadata:
   short-description: Qingflow record delete
 ---
 
 # Qingflow Record Delete
 
-> **Skill 版本**：`qingflow-skills-2026.06.24.2`（入口文档版本；如需确认 CLI 包版本，使用 `qingflow --version` 或 `qingflow --json version`）。
-
 ## Default Path
 
 `record_list / record_get -> record_delete`
@@ -23,11 +21,9 @@ metadata:
 
 1. Resolve the exact target `record_id` first
 2. Prefer reading the current state before delete when the request is high risk
-3. Choose an accessible system `view_id` from `app_get.accessible_views`; custom views can locate records but cannot be used as the delete route
-4. Call `record_delete` with `record_id` or `record_ids` and the system `view_id` so the backend uses the matching listType delete route
+3. Call `record_delete` with `record_id` or `record_ids`
 
 ## Do Not
 
-- Do not pass `custom:*` view selectors to `record_delete`; custom views can locate records, but delete currently supports only system listType routes
-- Do not omit `view_id`; a delete without frontend list context is ambiguous and should return `RECORD_DELETE_VIEW_REQUIRED`
+- Do not pass any `view_*` selector
 - Do not infer the target record id from a vague title if `record_list` can disambiguate it