Update to Postman

{
  "description": "Use when running, deploying, or debugging an existing Postman Flow. Distinguishes local graph execution from a deployed webhook, reuses named input scenarios, and follows a run to the failing block rather than treating an HTTP response as whole-flow success. Use for requests such as \"why did this flow fail\".",
  "included_files": [
    {
      "relative_path": "reference/flow_cli_flags.md",
      "size_in_bytes": 5698
    }
  ],
  "name": "flows",
  "skill_md_contents": "---\nname: flows\ndescription: Use when running, deploying, or debugging an existing Postman Flow. Distinguishes local graph execution from a deployed webhook, reuses named input scenarios, and follows a run to the failing block rather than treating an HTTP response as whole-flow success. Use for requests such as \"why did this flow fail\".\n---\n\n# Postman Flows\n\nA Flow saves an API workflow as a graph of blocks. Named inputs make runs\nrepeatable, deployment makes the workflow callable by other systems, and\nblock-level run evidence shows where it failed. These benefits come from\ndifferent execution paths; choosing the wrong path can produce a passing\nresult that says nothing about the caller's actual workflow.\n\n1. Choose the artifact the user means. `postman flows run <path>` executes a\n   local JSON file; `postman flows trigger <flow-id>` calls the deployed\n   webhook, including trigger auth and configuration. Local View and Cloud\n   View artifacts are isolated: local files cannot be assumed deployable,\n   and `workspace pull` does not download them. The desktop app's Git-connected\n   Local View produces those files. Check current local-run entitlement before\n   building CI around it; a deployed flow is not a substitute for a different\n   local artifact.\n2. Resolve hosted IDs through `flows list --workspace <id>`; there is no\n   local flow mapping in `.postman/resources.yaml`. Reuse its `workspace.id`\n   when applicable or use **api-discovery** for cross-workspace search.\n   Resolve ambiguous names before mutating a flow. Use returned flow/run IDs\n   verbatim; their spelling is not a reliable validation rule.\n3. Reuse a Start-block scenario when the same payload should travel with the\n   flow. `-s` supplies payload, headers, and query; explicit headers/query and\n   `-i`/`-f` override those values. One-off inputs belong on the invocation.\n   For deployed flows with side effects, `trigger --dry-run` lets you inspect\n   the resolved call first; keep secrets masked.\n4. Deploy when the workflow needs a callable URL. The hosted flow needs a\n   Start block configured for an API request trigger and a Response block;\n   changing CLI flags cannot repair missing canvas configuration. Resolve\n   the path suffix and intended authentication before deploying. Deploy/auth\n   changes affect other callers; a scoped user request authorizes that change,\n   while unrequested public exposure or auth removal needs consent.\n5. Inspect the deployed URL and whether its trigger is enabled. A deployed\n   but disabled flow is not ready to receive calls; `flows update <id>\n   --trigger on` enables it when intended. If deployment is part of a requested\n   run, continue through triggering and capture the Run ID. A request only to\n   deploy does not authorize executing unrelated downstream writes.\n6. Diagnose from run evidence. A trigger response is the Response block's\n   output: HTTP 200 can coexist with another failed block. Use\n   `flows get-run --run-id <id>` and add `--logs` or a block filter when the\n   summary does not explain it. `flows list-runs --workspace <id> --flow <id>`\n   recovers missing run IDs; widen its time range before concluding absence.\n7. In CI, preserve the local run's failure exit code and persist its result\n   and reports. Connector blocks need `--workspace` even for a local file;\n   otherwise failure occurs inside the graph. An access denial across several\n   workspaces points toward credentials or entitlement, not an empty flow list.\n\nRead [command options](reference/flow_cli_flags.md) for inputs, reporters,\ndataset iteration, and flag collisions; check installed subcommand `-h` before\ncarrying an option between commands.\n\n## Verification\n\nReport which artifact and path executed, its inputs/scenario without secrets,\nand the actual result. For a trigger, retain the Run ID; for a failure, name\nthe failing block and cause. For a deployment, report URL, auth, and enabled\nstate separately from any execution result.\n"
}