Business Flow Runtime
Scope
Only handles existing business flow instances, business flow tasks, lanes, instance forms, and runtime task data. Do not use it for business flow definitions, node configuration, publishing, enabling or disabling, or configuration deletion.
This skill only handles explicitly identified tasks, instances, lanes, or business objects. Do not treat instance detail, instance list, lane queries, or task detail as a to-do query.
Tool Routing
| User Intent |
Tool |
Type |
Primary Target |
Use |
| Complete current task |
bpm_runtime_task_complete-task |
Write |
taskId |
Complete the current business flow task without editing task data |
| Edit and complete, or update fields then complete |
First bpm_runtime_task_get-task-info, then choose bpm_runtime_task_update-data-and-complete-task or bpm_runtime_task_edit + bpm_runtime_task_complete-task by layoutType |
Write |
taskId + entityId + objectId |
Route completion by layout after confirming the current writable task form |
| Only edit task data |
bpm_runtime_task_edit |
Write |
taskId |
Save task form or business data without completing |
| Complete and create related data |
bpm_runtime_task_complete-and-create-task-data |
Write |
taskId + activity ID |
Complete the current task and create the required related business data in one operation |
| Execute specified task operation |
bpm_runtime_task_operate-task |
Write |
taskId + type |
Execute a concrete task-side operation such as a button-driven action identified in current context |
| View task details |
bpm_runtime_task_get-task-info |
Read |
id (taskId) |
Read task status, layout, current data, and writable-task context |
| View available buttons |
bpm_runtime_task_get-button-by-task-id |
Read |
taskIds |
Read task-level executable buttons or actions for the specified tasks |
| View tasks by lane |
bpm_runtime_task_get-task-info-by-lane-id |
Read |
laneId + workflow and instance context |
Read tasks that belong to a specific lane |
| View an instance form of a confirmed type |
bpm_runtime_instance_get-instance-form |
Read |
workflowInstanceId + instanceFormType |
Read an instance-level form when the form type is already known |
| Query instances by business record |
bpm_runtime_instance_get-instances-by-object |
Read |
objectId |
Read business-flow instances associated with a record |
| Find tasks by instance or view instance log |
bpm_runtime_instance_get-instance-log |
Read |
workflowInstanceId |
Read instance log data and locate task IDs under the instance |
| Cancel instance |
bpm_runtime_instance_cancel |
Write |
id (workflowInstanceId) |
Cancel an existing business flow instance |
| Trigger instance |
bpm_runtime_instance_trigger |
Write |
id (workflowDefinitionId) + objectId |
Trigger a business flow definition for a business record |
| Retry instance after-action |
bpm_runtime_instance_after-action-retry |
Write |
instanceId |
Retry a failed or pending instance-level after-action |
| Retry task after-action |
bpm_runtime_task_after-action-retry |
Write |
taskId |
Retry a failed or pending task-level after-action |
| Manually change handler |
bpm_runtime_task_change-task-handler |
Write |
taskId + candidateIds |
Replace the current task handler list with explicit user IDs |
| Recalculate handler |
bpm_runtime_task_refresh-handler-by-task-id |
Write |
taskId |
Recalculate the handler assignment for the specified task |
| Remind specified handler |
bpm_runtime_task_remind |
Write |
taskId + remindPersons |
Send a reminder to specified handlers on the task |
Layout Identification Before Editing And Completing
When the user asks to edit fields and complete the current BPM task, first call bpm_runtime_task_get-task-info for that same taskId, then route by layoutType.
layoutType |
Path |
defaultLayout |
Use bpm_runtime_task_update-data-and-complete-task to update fields and complete |
objectFlowLayout |
Use bpm_runtime_task_edit to save, then bpm_runtime_task_complete-task to complete |
| Missing, conflicting, or any other value |
Stop and resolve the layout explicitly; do not guess or downgrade to another write path |
The flow-layout path is a closed two-step sequence for the same task and unchanged parameters. The final preview must state "save, then complete". After one later explicit user confirmation, run bpm_runtime_task_edit first and run bpm_runtime_task_complete-task only if the save succeeds.
Read Tool Usage Rules
bpm_runtime_task_get-task-info is the primary read tool for task identity, task state, and layoutType.
bpm_runtime_task_get-button-by-task-id is the primary read tool when the final executable action or task operation type must be confirmed.
bpm_runtime_task_get-task-info-by-lane-id is only for lane-scoped task reads; do not use it to replace a task-detail read.
bpm_runtime_instance_get-instance-form only reads an already confirmed instance form type; do not use it to locate taskId, workflowId, or laneId, and do not treat it as the current task form.
bpm_runtime_instance_get-instances-by-object is the record-to-instance lookup path when starting from a business record.
bpm_runtime_instance_get-instance-log is the preferred read path for locating task IDs under a confirmed instance and for viewing instance execution logs.
Write Tool Usage Rules
Task completion
Use bpm_runtime_task_complete-task only when the task should be completed without changing task data in the same operation.
Edit then complete
When field updates are required before completion:
- First read
bpm_runtime_task_get-task-info
- Route by
layoutType
defaultLayout: use bpm_runtime_task_update-data-and-complete-task
objectFlowLayout: use bpm_runtime_task_edit, then bpm_runtime_task_complete-task
Task-only edit
Use bpm_runtime_task_edit only to save task data. Do not treat it as completion.
Complete and create related data
Use bpm_runtime_task_complete-and-create-task-data only when the user explicitly needs both task completion and creation of related data for the specified activity.
Task operation execution
Use bpm_runtime_task_operate-task only when the operation type is explicitly provided by the user or already confirmed from task buttons in current context. Do not infer type from natural-language intent alone.
Instance operations
bpm_runtime_instance_cancel is for an existing runtime instance identified by workflowInstanceId.
bpm_runtime_instance_trigger is for starting a flow definition on a business record and uses the flow definition ID, not the runtime instance ID.
bpm_runtime_instance_after-action-retry retries instance-level after-actions only.
Task-side recovery and assignment
bpm_runtime_task_after-action-retry retries task-level after-actions only.
bpm_runtime_task_change-task-handler requires explicit user IDs in candidateIds.
bpm_runtime_task_refresh-handler-by-task-id recalculates assignment instead of manually replacing candidate IDs.
bpm_runtime_task_remind sends reminders to the specified task handlers.
Execution Rules
- First classify the unique target and action. Stop when the target ID is missing, the target type is unclear, the candidate is not unique, the current status conflicts, or required parameters are incomplete.
- Read tools may execute directly, but they only answer or collect facts and must never auto-escalate to a write.
- Write tools must use the narrowest confirmed target and parameters from current context. Do not fabricate actions, IDs, field payloads, candidate IDs,
type, or related activity IDs.
- Only the confirmed
objectFlowLayout path may execute the fixed two-step bpm_runtime_task_edit then bpm_runtime_task_complete-task sequence.
- After a write, use only the narrowest supporting read path needed for verification. Do not chain a second write because of verification.
Identifiers And Data Contract
taskId is only for task operations.
instanceId or workflowInstanceId is only for instance operations.
laneId is only for lane queries.
entityId + objectId identifies the business object and record.
candidateIds and remindPersons must be real user IDs.
- The
id used by bpm_runtime_instance_cancel is the runtime instance ID.
- The
id used by bpm_runtime_instance_trigger is the flow definition ID.
- Those two
id values have different meanings and must not be mixed.
- When the user refers to "the first one" or "the Nth one", only bind it from the most recently displayed same-type list in current session.
- Business data may only contain real, writable field differences for the current task form. Do not pass full records, empty JSON, double-encoded payloads, or system fields unless the selected tool contract explicitly requires them.
Write Secondary Confirmation
Before every write, display a final business-facing preview and wait for an explicit affirmative in a later user message for the same unchanged operation.
- The preview should state the target business-flow item, intended action, changed fields or handler changes, opinion if any, impact scope, and any retry or cancel risk.
- Do not expose raw tool names, raw payload JSON, or internal IDs unless the user explicitly asks.
- The initial request, parameter clarification, read-only results, and the preview itself are not authorization.
- Any change to target, action, field data, handler list, retry scope, reminder recipients, opinion, or risk invalidates the prior confirmation and requires a new preview.
- After valid authorization, execute the write once. Do not ask again unless the operation changes.
Result Reporting
Report the actually executed operation, target, server result, and any read-only verification evidence. If the final business state cannot be independently verified, state that explicitly instead of overstating success.
1---2name: bpm-runtime-skill3description: Used to query or process existing business flow instances and business flow tasks. Use when the user mentions business flow to-dos, completion, submit after filling, editing task data, creating related data, executing a specified operation, changing or recalculating handlers, reminding, triggering, canceling, retrying, task details, buttons, lanes, instance forms or logs. First select a unique reference by intent; changes must confirm the target and parameters, and queries must not auto-escalate to changes.4---5# Business Flow Runtime
6
7## Scope
8
9Only handles existing business flow instances, business flow tasks, lanes, instance forms, and runtime task data. Do not use it for business flow definitions, node configuration, publishing, enabling or disabling, or configuration deletion.
10
11This skill only handles explicitly identified tasks, instances, lanes, or business objects. Do not treat instance detail, instance list, lane queries, or task detail as a to-do query.
12
13## Tool Routing
14
15| User Intent | Tool | Type | Primary Target | Use |
16| --- | --- | --- | --- | --- |
17| Complete current task | `bpm_runtime_task_complete-task` | Write | `taskId` | Complete the current business flow task without editing task data |
18| Edit and complete, or update fields then complete | First `bpm_runtime_task_get-task-info`, then choose `bpm_runtime_task_update-data-and-complete-task` or `bpm_runtime_task_edit` + `bpm_runtime_task_complete-task` by `layoutType` | Write | `taskId` + `entityId` + `objectId` | Route completion by layout after confirming the current writable task form |
19| Only edit task data | `bpm_runtime_task_edit` | Write | `taskId` | Save task form or business data without completing |
20| Complete and create related data | `bpm_runtime_task_complete-and-create-task-data` | Write | `taskId` + activity ID | Complete the current task and create the required related business data in one operation |
21| Execute specified task operation | `bpm_runtime_task_operate-task` | Write | `taskId` + `type` | Execute a concrete task-side operation such as a button-driven action identified in current context |
22| View task details | `bpm_runtime_task_get-task-info` | Read | `id` (`taskId`) | Read task status, layout, current data, and writable-task context |
23| View available buttons | `bpm_runtime_task_get-button-by-task-id` | Read | `taskIds` | Read task-level executable buttons or actions for the specified tasks |
24| View tasks by lane | `bpm_runtime_task_get-task-info-by-lane-id` | Read | `laneId` + workflow and instance context | Read tasks that belong to a specific lane |
25| View an instance form of a confirmed type | `bpm_runtime_instance_get-instance-form` | Read | `workflowInstanceId` + `instanceFormType` | Read an instance-level form when the form type is already known |
26| Query instances by business record | `bpm_runtime_instance_get-instances-by-object` | Read | `objectId` | Read business-flow instances associated with a record |
27| Find tasks by instance or view instance log | `bpm_runtime_instance_get-instance-log` | Read | `workflowInstanceId` | Read instance log data and locate task IDs under the instance |
28| Cancel instance | `bpm_runtime_instance_cancel` | Write | `id` (`workflowInstanceId`) | Cancel an existing business flow instance |
29| Trigger instance | `bpm_runtime_instance_trigger` | Write | `id` (`workflowDefinitionId`) + `objectId` | Trigger a business flow definition for a business record |
30| Retry instance after-action | `bpm_runtime_instance_after-action-retry` | Write | `instanceId` | Retry a failed or pending instance-level after-action |
31| Retry task after-action | `bpm_runtime_task_after-action-retry` | Write | `taskId` | Retry a failed or pending task-level after-action |
32| Manually change handler | `bpm_runtime_task_change-task-handler` | Write | `taskId` + `candidateIds` | Replace the current task handler list with explicit user IDs |
33| Recalculate handler | `bpm_runtime_task_refresh-handler-by-task-id` | Write | `taskId` | Recalculate the handler assignment for the specified task |
34| Remind specified handler | `bpm_runtime_task_remind` | Write | `taskId` + `remindPersons` | Send a reminder to specified handlers on the task |
35
36## Layout Identification Before Editing And Completing
37
38When the user asks to edit fields and complete the current BPM task, first call `bpm_runtime_task_get-task-info` for that same `taskId`, then route by `layoutType`.
39
40| `layoutType` | Path |
41| --- | --- |
42| `defaultLayout` | Use `bpm_runtime_task_update-data-and-complete-task` to update fields and complete |
43| `objectFlowLayout` | Use `bpm_runtime_task_edit` to save, then `bpm_runtime_task_complete-task` to complete |
44| Missing, conflicting, or any other value | Stop and resolve the layout explicitly; do not guess or downgrade to another write path |
45
46The flow-layout path is a closed two-step sequence for the same task and unchanged parameters. The final preview must state "save, then complete". After one later explicit user confirmation, run `bpm_runtime_task_edit` first and run `bpm_runtime_task_complete-task` only if the save succeeds.
47
48## Read Tool Usage Rules
49
50- `bpm_runtime_task_get-task-info` is the primary read tool for task identity, task state, and `layoutType`.
51- `bpm_runtime_task_get-button-by-task-id` is the primary read tool when the final executable action or task operation `type` must be confirmed.
52- `bpm_runtime_task_get-task-info-by-lane-id` is only for lane-scoped task reads; do not use it to replace a task-detail read.
53- `bpm_runtime_instance_get-instance-form` only reads an already confirmed instance form type; do not use it to locate `taskId`, `workflowId`, or `laneId`, and do not treat it as the current task form.
54- `bpm_runtime_instance_get-instances-by-object` is the record-to-instance lookup path when starting from a business record.
55- `bpm_runtime_instance_get-instance-log` is the preferred read path for locating task IDs under a confirmed instance and for viewing instance execution logs.
56
57## Write Tool Usage Rules
58
59### Task completion
60
61Use `bpm_runtime_task_complete-task` only when the task should be completed without changing task data in the same operation.
62
63### Edit then complete
64
65When field updates are required before completion:
66
67- First read `bpm_runtime_task_get-task-info`
68- Route by `layoutType`
69- `defaultLayout`: use `bpm_runtime_task_update-data-and-complete-task`
70- `objectFlowLayout`: use `bpm_runtime_task_edit`, then `bpm_runtime_task_complete-task`
71
72### Task-only edit
73
74Use `bpm_runtime_task_edit` only to save task data. Do not treat it as completion.
75
76### Complete and create related data
77
78Use `bpm_runtime_task_complete-and-create-task-data` only when the user explicitly needs both task completion and creation of related data for the specified activity.
79
80### Task operation execution
81
82Use `bpm_runtime_task_operate-task` only when the operation `type` is explicitly provided by the user or already confirmed from task buttons in current context. Do not infer `type` from natural-language intent alone.
83
84### Instance operations
85
86- `bpm_runtime_instance_cancel` is for an existing runtime instance identified by `workflowInstanceId`.
87- `bpm_runtime_instance_trigger` is for starting a flow definition on a business record and uses the flow definition ID, not the runtime instance ID.
88- `bpm_runtime_instance_after-action-retry` retries instance-level after-actions only.
89
90### Task-side recovery and assignment
91
92- `bpm_runtime_task_after-action-retry` retries task-level after-actions only.
93- `bpm_runtime_task_change-task-handler` requires explicit user IDs in `candidateIds`.
94- `bpm_runtime_task_refresh-handler-by-task-id` recalculates assignment instead of manually replacing candidate IDs.
95- `bpm_runtime_task_remind` sends reminders to the specified task handlers.
96
97## Execution Rules
98
991. First classify the unique target and action. Stop when the target ID is missing, the target type is unclear, the candidate is not unique, the current status conflicts, or required parameters are incomplete.
1002. Read tools may execute directly, but they only answer or collect facts and must never auto-escalate to a write.
1013. Write tools must use the narrowest confirmed target and parameters from current context. Do not fabricate actions, IDs, field payloads, candidate IDs, `type`, or related activity IDs.
1024. Only the confirmed `objectFlowLayout` path may execute the fixed two-step `bpm_runtime_task_edit` then `bpm_runtime_task_complete-task` sequence.
1035. After a write, use only the narrowest supporting read path needed for verification. Do not chain a second write because of verification.
104
105## Identifiers And Data Contract
106
107- `taskId` is only for task operations.
108- `instanceId` or `workflowInstanceId` is only for instance operations.
109- `laneId` is only for lane queries.
110- `entityId + objectId` identifies the business object and record.
111- `candidateIds` and `remindPersons` must be real user IDs.
112- The `id` used by `bpm_runtime_instance_cancel` is the runtime instance ID.
113- The `id` used by `bpm_runtime_instance_trigger` is the flow definition ID.
114- Those two `id` values have different meanings and must not be mixed.
115- When the user refers to "the first one" or "the Nth one", only bind it from the most recently displayed same-type list in current session.
116- Business data may only contain real, writable field differences for the current task form. Do not pass full records, empty JSON, double-encoded payloads, or system fields unless the selected tool contract explicitly requires them.
117
118## Write Secondary Confirmation
119
120Before every write, display a final business-facing preview and wait for an explicit affirmative in a later user message for the same unchanged operation.
121
122- The preview should state the target business-flow item, intended action, changed fields or handler changes, opinion if any, impact scope, and any retry or cancel risk.
123- Do not expose raw tool names, raw payload JSON, or internal IDs unless the user explicitly asks.
124- The initial request, parameter clarification, read-only results, and the preview itself are not authorization.
125- Any change to target, action, field data, handler list, retry scope, reminder recipients, opinion, or risk invalidates the prior confirmation and requires a new preview.
126- After valid authorization, execute the write once. Do not ask again unless the operation changes.
127
128## Result Reporting
129
130Report the actually executed operation, target, server result, and any read-only verification evidence. If the final business state cannot be independently verified, state that explicitly instead of overstating success.