debugging-executions — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited debugging-executions (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Use this skill when debugging workflow execution failures or successful runs with wrong or empty values.
Re-run the failing path with executions(action="run") (or verify-built-workflow) and inspect the real result before responding. Do not restate that the workflow is "fixed", "verified", or "working", and do not attribute the reported failure to a test-harness artifact, stale state, or "it works in production" without a re-run against the failing path. Treat live signals as real: an execution error, partial coverage (nodesNotReached), an empty node, or a missing node is a real defect to investigate, not something to explain away. If you genuinely cannot re-run the failing path, say so plainly and name what is unconfirmed instead of repeating a success claim.
Use executions(action="run") with inputData matching the trigger's output shape — do not rebuild the workflow with a Manual Trigger. For trigger inputData shapes, read knowledge-base/reference/trigger-input-data-shapes.md when a sandbox workspace is available.
executions(action="debug") already includes failedNode.resolvedParameters — start there. That bundle has parameters (raw, with expressions intact), resolved (substituted), failedExpressions (those that threw), and emptyResolutions (those that resolved to null/undefined/"" silently). The offending expression is usually visible without a follow-up call. Entries in either list tagged with reason: "unreconstructable-context" are NOT real bugs — they reference variables we don't reconstruct in replay ($vars, $secrets, $response, $request, $pageCount, $ai). The value existed at execution time; we just don't have it here.
When debug doesn't apply because nothing errored, call executions(action="get-resolved-node-parameters", executionId, nodeName) on the node whose output looks off — do this unprompted, don't ask the user for permission first. It's a cheap read-only inspection and the only reliable way to confirm whether an empty value came from an expression silently resolving to nullish. Check emptyResolutions first; most "this parameter is empty" cases are expressions resolving to null/undefined/"", not thrown errors.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.