Awesome/awesome-copilot
1
0
Fork 0
mirror of https://github.com/github/awesome-copilot.git synced 2026-08-28 03:25:15 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: publish from main

Browse Source
This commit is contained in:
github-actions[bot]
2026-08-27 04:36:36 +00:00
parent 4d9d17dff0
commit 351b969d89
8 changed files with 130 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plugins/flowstudio-power-automate/skills/flowstudio-power-automate-build/SKILL.md
+4 -3
View File
@@ -392,7 +392,7 @@ if runs:
print(result) # {"resubmitted": true, "triggerName": "..."}
```
### HTTP-triggered flows — custom test payload
### HTTP, Button, and PowerApps flows — custom test payload
Only use `trigger_live_flow` when you need to send a **different** payload
than the original run. For verifying a fix, `resubmit_live_flow_run` is
@@ -407,7 +407,8 @@ print("Expected body:", manual.get("inputs", {}).get("schema"))
result = mcp("trigger_live_flow",
environmentName=ENV, flowName=FLOW_ID,
body={"name": "Test", "value": 1})
print(f"Status: {result['responseStatus']}")
print(f"Status: {result['responseStatus']}, via: {result['invocation']}")
print(result.get("warning")) # set when a required input was missing: the run still ran, with null
```
### Brand-new non-HTTP flows (Recurrence, connector triggers, etc.)
@@ -469,7 +470,7 @@ payload.
| Flow deployed but state is "Stopped" | Flow won't run on schedule | Call `set_live_flow_state` with `state: "Started"` — do **not** use `update_live_flow` for state changes |
| Teams "Chat with Flow bot" recipient as object | 400 `GraphUserDetailNotFound` | Use plain string with trailing semicolon (see below) |
| Copilot/Skills flow not in a solution | Copilot Studio may not discover it as an agent tool | After deploy, call `add_live_flow_to_solution` with the target `solutionId` |
| Button/Skills trigger used for MCP testing | MCP cannot directly fire the production trigger | Test the same actions through a temporary HTTP twin, then swap the trigger back |
| Button/Skills trigger used for MCP testing | Runs even when a required input is missing (null) | Pass inputs in `trigger_live_flow` `body`; on `warning`, cancel and retry with the full body |
| Connector action missing `metadata.operationMetadataId` | Designer/run-only UI can behave inconsistently | Preserve existing IDs; add stable GUIDs for new connector actions |
| Placeholder Excel `scriptId` | Dynamic validation fails at save time | Resolve the real Office Script ID before deploying |
| SharePoint `PatchItem` omits required fields | Save can fail even if the field is not changing | Echo unchanged required fields such as `item/Title` |
plugins/flowstudio-power-automate/skills/flowstudio-power-automate-build/references/trigger-types.md
+3 -3
View File
@@ -121,9 +121,9 @@ input names and types.
After deploying a production Skills-triggered flow, call
`add_live_flow_to_solution` with the target `solutionId`; Copilot Studio agent
tool discovery expects the flow to be solution-aware. For MCP-driven testing,
use a temporary HTTP twin with the same actions and payload shape, then restore
the Skills trigger after the actions are verified.
tool discovery expects the flow to be solution-aware. To test it from MCP, call
`trigger_live_flow` with the inputs in `body` — Skills triggers run through the
connector runtime the same way Button and PowerApps triggers do.
---
plugins/flowstudio-power-automate/skills/flowstudio-power-automate-debug/SKILL.md
+24 -6
View File
@@ -411,13 +411,14 @@ print(new_runs[0]["status"]) # Succeeded = done
| **Testing a fix** on any flow | `resubmit_live_flow_run` | Replays the exact trigger payload that caused the failure — best way to verify |
| Recurrence / scheduled flow | `resubmit_live_flow_run` | Cannot be triggered on demand any other way |
| SharePoint / connector trigger | `resubmit_live_flow_run` | Cannot be triggered without creating a real SP item |
| HTTP trigger with **custom** test payload | `trigger_live_flow` | When you need to send different data than the original run |
| Brand-new flow, never run | `trigger_live_flow` (HTTP only) | No prior run exists to resubmit |
| HTTP, Button, or PowerApps trigger with **custom** test payload | `trigger_live_flow` | When you need to send different data than the original run |
| Brand-new flow, never run | `trigger_live_flow` (HTTP, Button, PowerApps) | No prior run exists to resubmit |
### Testing HTTP-Triggered Flows with custom payloads
### Testing HTTP, Button, and PowerApps flows with custom payloads
For flows with a `Request` (HTTP) trigger, use `trigger_live_flow` when you
need to send a **different** payload than the original run:
For flows with a `Request` trigger (HTTP request, manual Button, or PowerApps),
use `trigger_live_flow` when you need to send a **different** payload than the
original run. Pass trigger inputs as `body` for every kind:
```python
# First inspect what the trigger expects — read directly from the flow definition
@@ -438,10 +439,27 @@ result = mcp("trigger_live_flow",
flowName=FLOW_ID,
body={"name": "Test User", "value": 42})
print(f"Status: {result['responseStatus']}, Body: {result.get('responseBody')}")
print(f"Kind: {result['triggerKind']}, via: {result['invocation']}, run: {result.get('runName')}")
if result.get("warning"):
print(result["warning"]) # required trigger inputs you left out
```
> `trigger_live_flow` handles AAD-authenticated triggers automatically.
> Only works for flows with a `Request` (HTTP) trigger type.
> Works for `Request` triggers only: HTTP request, Button, and PowerApps.
> Scheduled and connector triggers cannot be run this way.
>
> Power Automate does not enforce a trigger's `required` inputs. If you leave
> one out the run still starts, with that input null, and the result carries a
> `warning` naming the missing keys. Cancel the run and call again with the
> full body if that matters.
>
> `runName` is only returned for Button and PowerApps runs. For HTTP triggers
> find the run with `get_live_flow_runs`.
>
> Over a browser-extension key, Button and PowerApps triggers run only with an
> empty body. The tool says so and lists the ways round it: resubmit a past run,
> default the inputs inside the flow with `coalesce(triggerBody()?['x'], 'value')`,
> or use a standard API key.
---
plugins/flowstudio-power-automate/skills/flowstudio-power-automate-mcp/references/tool-reference.md
+34 -16
View File
@@ -435,31 +435,47 @@ responseSchemaCount - Number of Response actions that define output schemas
### `get_live_flow_trigger_url`
Deprecated. Prefer `trigger_live_flow` when you need to invoke an HTTP-triggered
flow; it fetches the current callback URL internally.
Deprecated. Prefer `trigger_live_flow` when you need to run a flow; it fetches the
callback URL internally for HTTP triggers and uses the connector runtime for
Button and PowerApps triggers, which have no callback URL.
Returns the signed callback URL for HTTP-triggered flows. Response includes
`flowKey`, `triggerName`, `triggerType`, `triggerKind`, `triggerMethod`, `triggerUrl`.
### `trigger_live_flow`
Response keys: `flowKey`, `triggerName`, `triggerUrl`, `requiresAadAuth`, `authType`,
`responseStatus`, `responseBody`.
Response keys: `flowKey`, `triggerName`, `triggerKind`, `invocation`, `triggerUrl`,
`requiresAadAuth`, `authType`, `responseStatus`, `responseBody`, `runName`, and
`warning` when a required trigger input was not supplied.
> **Only works for `Request` (HTTP) triggers.** Returns an error for Recurrence
> and other trigger types: `"only HTTP Request triggers can be invoked via this tool"`.
> `Button`-kind triggers return `ListCallbackUrlOperationBlocked`.
> **Works for `Request` triggers: HTTP request, Button, and PowerApps.** Returns an
> error for Recurrence and connector triggers:
> `"only HTTP Request triggers can be invoked via this tool"`.
>
> HTTP triggers go through the signed callback URL (`invocation: callbackUrl`).
> Button and PowerApps triggers have no callback URL; with a `body` they run
> through the Power Platform connector runtime (`connectorFlowToken` or
> `connectorApihubToken`), which is the only route that delivers the inputs.
> With no body they use the cheaper direct run (`directRun`).
>
> `runName` is returned only for connector-runtime runs. Otherwise look the run
> up with `get_live_flow_runs`.
>
> Power Automate does not enforce a trigger's `required` list. A missing input
> still starts the run with a null value; `warning` names the missing keys and
> the body shape to retry with.
>
> Browser-extension keys cannot reach the connector runtime, so Button and
> PowerApps triggers run only with an empty body over that key type. The error
> lists the alternatives (resubmit a past run, default the inputs inside the flow
> with `coalesce()`, or use a standard key).
>
> `responseStatus` + `responseBody` contain the flow's Response action output.
> AAD-authenticated triggers are handled automatically.
>
> **Content-type note**: The body is sent as `application/octet-stream` (raw),
> not `application/json`. Flows with a trigger schema that has `required` fields
> will reject the request with `InvalidRequestContent` (400) because PA validates
> `Content-Type` before parsing against the schema. Flows without a schema, or
> flows designed to accept raw input (e.g. Baker-pattern flows that parse the body
> internally), will work fine. The flow receives the JSON as base64-encoded
> `$content` with `$content-type: application/octet-stream`.
> **Content type**: `body` is sent as `application/json`, so `triggerBody()` and
> the trigger schema see the object you passed. Verified 2026-08-27 on server 1.2.43
> against Button, PowerAppV2, and Skills triggers with `required` schemas.
---
@@ -578,8 +594,10 @@ tool schemas cannot tell you.
connectionReferences. Use `set_live_flow_state` to start/stop a flow.
### `trigger_live_flow`
- **Only works for HTTP Request triggers.** Returns error for Recurrence, connector,
and other trigger types.
- **Works for HTTP, Button, and PowerApps triggers.** Returns error for Recurrence,
connector, and other trigger types.
- Pass trigger inputs as `body`. A `warning` in the result means a required input
was missing and the run started with it null.
- AAD-authenticated triggers are handled automatically (impersonated Bearer token).
### `get_live_flow_runs`
skills/flowstudio-power-automate-build/SKILL.md
+4 -3
View File
@@ -392,7 +392,7 @@ if runs:
print(result) # {"resubmitted": true, "triggerName": "..."}
```
### HTTP-triggered flows — custom test payload
### HTTP, Button, and PowerApps flows — custom test payload
Only use `trigger_live_flow` when you need to send a **different** payload
than the original run. For verifying a fix, `resubmit_live_flow_run` is
@@ -407,7 +407,8 @@ print("Expected body:", manual.get("inputs", {}).get("schema"))
result = mcp("trigger_live_flow",
environmentName=ENV, flowName=FLOW_ID,
body={"name": "Test", "value": 1})
print(f"Status: {result['responseStatus']}")
print(f"Status: {result['responseStatus']}, via: {result['invocation']}")
print(result.get("warning")) # set when a required input was missing: the run still ran, with null
```
### Brand-new non-HTTP flows (Recurrence, connector triggers, etc.)
@@ -469,7 +470,7 @@ payload.
| Flow deployed but state is "Stopped" | Flow won't run on schedule | Call `set_live_flow_state` with `state: "Started"` — do **not** use `update_live_flow` for state changes |
| Teams "Chat with Flow bot" recipient as object | 400 `GraphUserDetailNotFound` | Use plain string with trailing semicolon (see below) |
| Copilot/Skills flow not in a solution | Copilot Studio may not discover it as an agent tool | After deploy, call `add_live_flow_to_solution` with the target `solutionId` |
| Button/Skills trigger used for MCP testing | MCP cannot directly fire the production trigger | Test the same actions through a temporary HTTP twin, then swap the trigger back |
| Button/Skills trigger used for MCP testing | Runs even when a required input is missing (null) | Pass inputs in `trigger_live_flow` `body`; on `warning`, cancel and retry with the full body |
| Connector action missing `metadata.operationMetadataId` | Designer/run-only UI can behave inconsistently | Preserve existing IDs; add stable GUIDs for new connector actions |
| Placeholder Excel `scriptId` | Dynamic validation fails at save time | Resolve the real Office Script ID before deploying |
| SharePoint `PatchItem` omits required fields | Save can fail even if the field is not changing | Echo unchanged required fields such as `item/Title` |
skills/flowstudio-power-automate-build/references/trigger-types.md
+3 -3
View File
@@ -121,9 +121,9 @@ input names and types.
After deploying a production Skills-triggered flow, call
`add_live_flow_to_solution` with the target `solutionId`; Copilot Studio agent
tool discovery expects the flow to be solution-aware. For MCP-driven testing,
use a temporary HTTP twin with the same actions and payload shape, then restore
the Skills trigger after the actions are verified.
tool discovery expects the flow to be solution-aware. To test it from MCP, call
`trigger_live_flow` with the inputs in `body` — Skills triggers run through the
connector runtime the same way Button and PowerApps triggers do.
---
skills/flowstudio-power-automate-debug/SKILL.md
+24 -6
View File
@@ -411,13 +411,14 @@ print(new_runs[0]["status"]) # Succeeded = done
| **Testing a fix** on any flow | `resubmit_live_flow_run` | Replays the exact trigger payload that caused the failure — best way to verify |
| Recurrence / scheduled flow | `resubmit_live_flow_run` | Cannot be triggered on demand any other way |
| SharePoint / connector trigger | `resubmit_live_flow_run` | Cannot be triggered without creating a real SP item |
| HTTP trigger with **custom** test payload | `trigger_live_flow` | When you need to send different data than the original run |
| Brand-new flow, never run | `trigger_live_flow` (HTTP only) | No prior run exists to resubmit |
| HTTP, Button, or PowerApps trigger with **custom** test payload | `trigger_live_flow` | When you need to send different data than the original run |
| Brand-new flow, never run | `trigger_live_flow` (HTTP, Button, PowerApps) | No prior run exists to resubmit |
### Testing HTTP-Triggered Flows with custom payloads
### Testing HTTP, Button, and PowerApps flows with custom payloads
For flows with a `Request` (HTTP) trigger, use `trigger_live_flow` when you
need to send a **different** payload than the original run:
For flows with a `Request` trigger (HTTP request, manual Button, or PowerApps),
use `trigger_live_flow` when you need to send a **different** payload than the
original run. Pass trigger inputs as `body` for every kind:
```python
# First inspect what the trigger expects — read directly from the flow definition
@@ -438,10 +439,27 @@ result = mcp("trigger_live_flow",
flowName=FLOW_ID,
body={"name": "Test User", "value": 42})
print(f"Status: {result['responseStatus']}, Body: {result.get('responseBody')}")
print(f"Kind: {result['triggerKind']}, via: {result['invocation']}, run: {result.get('runName')}")
if result.get("warning"):
print(result["warning"]) # required trigger inputs you left out
```
> `trigger_live_flow` handles AAD-authenticated triggers automatically.
> Only works for flows with a `Request` (HTTP) trigger type.
> Works for `Request` triggers only: HTTP request, Button, and PowerApps.
> Scheduled and connector triggers cannot be run this way.
>
> Power Automate does not enforce a trigger's `required` inputs. If you leave
> one out the run still starts, with that input null, and the result carries a
> `warning` naming the missing keys. Cancel the run and call again with the
> full body if that matters.
>
> `runName` is only returned for Button and PowerApps runs. For HTTP triggers
> find the run with `get_live_flow_runs`.
>
> Over a browser-extension key, Button and PowerApps triggers run only with an
> empty body. The tool says so and lists the ways round it: resubmit a past run,
> default the inputs inside the flow with `coalesce(triggerBody()?['x'], 'value')`,
> or use a standard API key.
---
skills/flowstudio-power-automate-mcp/references/tool-reference.md
+34 -16
View File
@@ -435,31 +435,47 @@ responseSchemaCount - Number of Response actions that define output schemas
### `get_live_flow_trigger_url`
Deprecated. Prefer `trigger_live_flow` when you need to invoke an HTTP-triggered
flow; it fetches the current callback URL internally.
Deprecated. Prefer `trigger_live_flow` when you need to run a flow; it fetches the
callback URL internally for HTTP triggers and uses the connector runtime for
Button and PowerApps triggers, which have no callback URL.
Returns the signed callback URL for HTTP-triggered flows. Response includes
`flowKey`, `triggerName`, `triggerType`, `triggerKind`, `triggerMethod`, `triggerUrl`.
### `trigger_live_flow`
Response keys: `flowKey`, `triggerName`, `triggerUrl`, `requiresAadAuth`, `authType`,
`responseStatus`, `responseBody`.
Response keys: `flowKey`, `triggerName`, `triggerKind`, `invocation`, `triggerUrl`,
`requiresAadAuth`, `authType`, `responseStatus`, `responseBody`, `runName`, and
`warning` when a required trigger input was not supplied.
> **Only works for `Request` (HTTP) triggers.** Returns an error for Recurrence
> and other trigger types: `"only HTTP Request triggers can be invoked via this tool"`.
> `Button`-kind triggers return `ListCallbackUrlOperationBlocked`.
> **Works for `Request` triggers: HTTP request, Button, and PowerApps.** Returns an
> error for Recurrence and connector triggers:
> `"only HTTP Request triggers can be invoked via this tool"`.
>
> HTTP triggers go through the signed callback URL (`invocation: callbackUrl`).
> Button and PowerApps triggers have no callback URL; with a `body` they run
> through the Power Platform connector runtime (`connectorFlowToken` or
> `connectorApihubToken`), which is the only route that delivers the inputs.
> With no body they use the cheaper direct run (`directRun`).
>
> `runName` is returned only for connector-runtime runs. Otherwise look the run
> up with `get_live_flow_runs`.
>
> Power Automate does not enforce a trigger's `required` list. A missing input
> still starts the run with a null value; `warning` names the missing keys and
> the body shape to retry with.
>
> Browser-extension keys cannot reach the connector runtime, so Button and
> PowerApps triggers run only with an empty body over that key type. The error
> lists the alternatives (resubmit a past run, default the inputs inside the flow
> with `coalesce()`, or use a standard key).
>
> `responseStatus` + `responseBody` contain the flow's Response action output.
> AAD-authenticated triggers are handled automatically.
>
> **Content-type note**: The body is sent as `application/octet-stream` (raw),
> not `application/json`. Flows with a trigger schema that has `required` fields
> will reject the request with `InvalidRequestContent` (400) because PA validates
> `Content-Type` before parsing against the schema. Flows without a schema, or
> flows designed to accept raw input (e.g. Baker-pattern flows that parse the body
> internally), will work fine. The flow receives the JSON as base64-encoded
> `$content` with `$content-type: application/octet-stream`.
> **Content type**: `body` is sent as `application/json`, so `triggerBody()` and
> the trigger schema see the object you passed. Verified 2026-08-27 on server 1.2.43
> against Button, PowerAppV2, and Skills triggers with `required` schemas.
---
@@ -578,8 +594,10 @@ tool schemas cannot tell you.
connectionReferences. Use `set_live_flow_state` to start/stop a flow.
### `trigger_live_flow`
- **Only works for HTTP Request triggers.** Returns error for Recurrence, connector,
and other trigger types.
- **Works for HTTP, Button, and PowerApps triggers.** Returns error for Recurrence,
connector, and other trigger types.
- Pass trigger inputs as `body`. A `warning` in the result means a required input
was missing and the run started with it null.
- AAD-authenticated triggers are handled automatically (impersonated Bearer token).
### `get_live_flow_runs`