Update to Postman

{
  "description": "Use when finding an API or owner, integrating a public provider, locating Postman resources, or investigating consumers and change impact across services. Turns discovered contracts and mocks into reusable dependencies and identifies evidence outside the current checkout. Use for requests such as \"who consumes this endpoint\".",
  "included_files": [
    {
      "relative_path": "reference/orbit.md",
      "size_in_bytes": 4078
    }
  ],
  "name": "api-discovery",
  "skill_md_contents": "---\nname: api-discovery\ndescription: Use when finding an API or owner, integrating a public provider, locating Postman resources, or investigating consumers and change impact across services. Turns discovered contracts and mocks into reusable dependencies and identifies evidence outside the current checkout. Use for requests such as \"who consumes this endpoint\".\n---\n\n# API Discovery\n\nExisting contracts and owners' mocks reduce the assumptions an integration\nmust invent. Relationship context broadens investigation beyond the checkout:\npassing this service's own tests does not establish that its consumers can\nstill use a changed interface.\n\nPostman search, the Context Graph and dependency downloads work only for a\nsigned-in CLI. Check `postman status` before the first of them and sign in if\nit reports signed out. If signing in isn't possible, don't run them; say which\nsources were skipped.\n\n1. Choose the source by the question:\n\n   | Need | Use |\n   | --- | --- |\n   | Public provider endpoints and integration details | Orbit search, then integrate |\n   | A concrete Postman collection, request, spec, mock, or workspace | `postman search <type> <query>` |\n   | Consumers, ownership, dependencies, or likely change impact | `postman context-graph ask` |\n\n   These sources answer different questions. A miss in one does not establish\n   absence in the others; combine entity search and relationship context when\n   both the resource and its impact matter.\n2. For public APIs, Orbit narrows discovery to task-relevant endpoints and\n   returns integration guidance instead of requiring a whole vendor spec in\n   context. Use it even when the provider is chosen: endpoint details and\n   capability limits still determine whether the integration fits the task.\n   `POST https://api.buildwithorbit.ai/v1/search` accepts a task in\n   `q`; pass the chosen results' `id` and `resourceType` unchanged to\n   `/v1/integrate`. Evaluate fit and limitations before choosing a provider,\n   then use the returned auth, base URL, steps, and gotchas to implement.\n   Read [Orbit's request schemas](reference/orbit.md) for the actual payloads\n   and error handling. Orbit access does not supply a provider's credentials.\n3. For Postman resources, narrow by entity type, ownership, and workspace.\n   Read `postman search <type> -h` for supported filters. An empty result in\n   the default ownership scope is incomplete evidence; consider\n   `--ownership all` or a relevant narrower scope before declaring absence.\n   Inspect the selected resource's owner and content rather than trusting a\n   similar name.\n4. For cross-service changes, ask the Context Graph a concrete question about\n   the endpoint, schema, or service. `--wait` waits for an answer; without it,\n   use the returned ID with `postman context-graph status <askId>`. The graph\n   can connect Postman definitions, repository call sites, and runtime\n   telemetry beyond the current checkout. Its coverage depends on connected\n   and ingested sources, so verify consequential leads against definitions,\n   source, or telemetry before treating them as facts. A newly added call may\n   not be present yet. The query uses the authenticated API key's team, not\n   the repository's workspace binding; changing that binding cannot fix a\n   query against the wrong organization's context.\n5. Before importing, tell this repository's owning workspace from a\n   dependency. For a dependency, `postman dependency add\n   <collection|environment|mock> <name-or-id>` declares and downloads the\n   selected resource without rebinding the repository. Prefer the discovered\n   ID; `--workspace <id>` disambiguates names. If the graph only identified a\n   service, search for its concrete resource first.\n6. Dependency declarations live in `.postman/resources.yaml`, with downloads\n   in `postman/.dependencies/`. `dependency install` restores them after a\n   clone or in CI; `dependency update` refreshes them. Review refreshes when\n   they can change test expectations. Copy a dependency into owned files to\n   customize it, because updating dependencies overwrites downloaded edits.\n   Use `dependency list` and command-specific help for targeted operations.\n\nUse **api-simulation** to exercise the real service against discovered mocks,\nand **ci-integration** to keep the resulting contract checks repeatable in PRs.\n\n## Verification\n\nReport which source answered the question, the resource IDs or evidence it\nreturned, what was reused, and any coverage gaps. A list of candidates alone\nis neither an integration nor proof of compatibility.\n"
}