Update to Postman

{
  "description": "Use when parameterizing requests across environments, choosing variable scopes, chaining values in scripts, or referencing credentials without committing or exposing them. Keeps one reusable collection while separating target configuration from secret values. Use for requests such as \"where should I put this API key\".",
  "included_files": [],
  "name": "variables",
  "skill_md_contents": "---\nname: variables\ndescription: Use when parameterizing requests across environments, choosing variable scopes, chaining values in scripts, or referencing credentials without committing or exposing them. Keeps one reusable collection while separating target configuration from secret values. Use for requests such as \"where should I put this API key\".\n---\n\n# Variables\n\nVariables let one maintained collection run against different targets without\nforking its requests. Scope determines which value wins; secret references\nallow the same files to be shared without sharing credential values.\n\n1. Put API defaults in collection variables and target-specific values, such\n   as `base_url`, in an environment. Parameterize values that actually vary;\n   a stable literal need not become another configuration choice. Reference\n   values as `{{key}}` in URLs, headers, parameters, or bodies.\n2. Resolve surprises through precedence: local script values override\n   iteration data, then environment, collection, and global values. A correct\n   environment file can still lose to a row or script override. Values can\n   reference other variables and resolve at send time, so inspect the chain\n   rather than just the final request field.\n3. Use runtime values for chaining responses into later requests. Choose\n   `pm.environment` or `pm.collectionVariables` when the scope is intentional;\n   `pm.variables.get` reads across scopes, and `pm.variables.set` holds a local\n   value for the current run. For transient sensitive values, avoid persisting\n   them to an environment or logging them.\n4. Store durable credentials in the shared vault and commit references.\n   `type: secret` alone masks the UI but still leaves a literal YAML value\n   readable. **collection-schema-v3**'s environment reference describes the\n   file schema; command-specific `-h` supplies supported vault operations.\n\nFor non-sensitive target configuration:\n\n```bash\npostman environment new \"Staging\"\npostman environment var set base_url https://staging.example.com \\\n  --environment \"postman/environments/Staging.environment.yaml\"\n```\n\nFor a secret, have the user supply the value through the CLI's masked prompt,\nnot through agent context or a literal command argument:\n\n```bash\npostman secret create STRIPE_API_KEY --workspace <workspace-id>\npostman environment var set api_key --secret-id <secret-id> --vault-id <vault-id> \\\n  --environment \"postman/environments/Staging.environment.yaml\"\n```\n\nThe environment then carries the vault/secret IDs rather than the value.\nSecret resolution and permission to view the secret are distinct; a teammate's\nability to run a request need not expose the credential to them. Vault\noperations require a signed-in CLI.\n\n## Verification\n\nRun `postman environment lint <path> --fail-severity warning` to fail on\nwarnings as well as errors in the saved environment. Lint checks the artifact;\nit does not prove that the session can resolve a vault secret. Verify resolution\nwith an appropriate authenticated request and a contract-derived assertion,\nkeeping credentials out of output. An unresolved-reference or authorization\nfailure needs investigation, not a claim that the secret worked.\nReport the selected environment and scope\nor reference that supplies the value; a masked display alone does not prove\nthat the committed file contains no literal secret.\n"
}