debug-flow
Debug a failed Power Automate flow run. Use when a flow failed, has errors, or the user wants to troubleshoot a run.
Works with
---
name: debug-flow
description: Debug a failed Power Automate flow run. Use when a flow failed, has errors, or the user wants to troubleshoot a run.
license: MIT
---
# Debug a Failed Flow Run
You are helping the user debug a failed Power Automate flow run.
## Tools
This skill uses the **FlowAgent MCP tools**. Clients surface them with a
client-specific prefix — `mcp__flowagent__<tool>` (Claude Code) or
`flowagent-<tool>` (Copilot CLI) — so they're referred to by bare name below
(e.g. `get_run_actions`). Use CLI shell commands (local engine build only) for
CLI-only operations or when no MCP tools are present.
| Tool | Purpose |
|------|---------|
| `list_flows` | Find flows by name (use `name` param for search) |
| `get_run_history` | Get recent runs for a flow |
| `diagnose_run` | One-shot: classify failed actions with remediations |
| `get_run_details` | Get details for a specific run |
| `get_run_actions` | Get action-level execution trace |
| `get_run_action_repetitions` | Iteration-level detail for a loop (which iteration failed — pass an action **inside** the loop) |
| `get_flow` | Get flow definition for context |
| `get_operation_details` | Confirm the correct action type / parameters |
| `edit_flow` | Apply a surgical fix to one action/parameter |
| `update_flow` | Replace the whole definition (large rewrites) |
| `run_flow` | Re-run after fix (use `wait: true` to see result) |
| `resubmit_run` / `cancel_run` | Resubmit a fixed run / cancel a stuck one |
## Steps
1. **Identify the flow and run**
- Parse `$ARGUMENTS` for flow ID and optional run ID.
- If no flow ID, call `list_flows` with `name` param to search. Ask user to pick if ambiguous.
- If no run ID, call `get_run_history` and find the most recent failed run.
- Present recent runs in a table: Run ID | Status | Start Time | Error
2. **Fast triage with `diagnose_run`**
- Call `diagnose_run` for the run — it returns the failed/timed-out actions already classified with a remediation each. Use this as the starting point.
- For deeper analysis, also fetch (in parallel): `get_run_actions` (full trace) and `get_flow` (definition context). For a failed loop, call `get_run_action_repetitions` on an action **inside** the loop to find the failing iteration.
3. **Analyze failures**
- Identify actions with status != "Succeeded"
- Trace the `runAfter` dependency chain to separate root cause from cascading failures:
- **Root cause**: action whose dependencies all Succeeded but it failed
- **Cascading**: actions skipped because a dependency failed
- Report root cause actions with: name, type, error code, error message
4. **Root cause classification**
- **Connection errors** (`AuthorizationFailed`, `ConnectionNotFound`, `InvokerConnectionOverrideFailed`): Suggest re-auth or fix connection source to Embedded
- **Expression errors** (`ExpressionEvaluationFailed`, `InvalidTemplate`): Show the expression, explain what's wrong, suggest fix
- **API/External errors** (401/403/404/429/500+): Explain the HTTP error, check connector status
- **Parameter errors** (`WorkflowOperationParametersRuntimeMissingValue`): Missing/empty required parameter. Add null guard: `@if(empty(...), 'default', ...)`
- **Timeout** (`ActionTimedOut`): Suggest retry policy or splitting the operation
- **Type mismatch** (`InvalidOpenApiConnectionOperationType`): Wrong action type. Call `get_operation_details` to find correct type.
5. **Suggest fix**
- Provide a specific fix with code/expression changes.
- If the fix is a definition change, offer to apply it with `edit_flow` (surgical, one action/parameter) — fall back to `update_flow` only for large rewrites.
6. **Re-test**
- Offer to call `run_flow` with `wait: true` to verify the fix works (or `resubmit_run` to retry the original run with its trigger inputs).
- Report the result: Succeeded/Failed with action details.
## Output Format
### Diagnosis Summary
- **Flow**: [name] ([ID])
- **Run**: [run ID] | [start time] | Status: **[status]**
### Failed Actions
| # | Action | Status | Error Code | Error Message |
|---|--------|--------|------------|---------------|
### Root Cause
[Classification]: [Explanation]
### Fix
[Step-by-step fix with code]More Debugging skills
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
explore-code
lllllllama/rigorpilot-skills
Rigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated branch or worktree to transplant modules, adapt a backbone, add LoRA or adapter layers, replace a head, or stitch together meaningful low-risk migration ideas with rollback-aware records in `explore_outputs/`. Do not use for end-to-end exploration orchestration on top of `current_research`, trusted baseline reproduction, conservative debugging, environment setup, verified contribution claims, or default repository analysis.
safe-debug
lllllllama/rigorpilot-skills
Rigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training failure and wants conservative diagnosis before any patching, with debug fixes clearly separated from research contributions. Do not use for broad refactoring, speculative adaptation, automatic exploratory patching, or general repository familiarization.

