@postman/postman-plugin 0.3.0 → 0.4.0

package/README.md

@@ -24,12 +24,22 @@ Install Postman in every compatible coding agent detected on your machine:
 npx @postman/postman-plugin
 ```
 
-One command configures **Claude Code, Codex, Cursor, Factory Droid, Kimi Code,
-OpenCode and Pi**. Run it again to update, `status` to see what's installed,
+One command configures **Antigravity, Claude Code, Codex, GitHub Copilot CLI, Cursor,
+Factory Droid, Kimi Code, OpenCode and Pi**. Run it again to update, `status` to see what's installed,
 and `remove` to uninstall; `--agent <id>` limits any of them to one agent.
 
 You can also use the following commands to install individually:
 
+### Antigravity
+
+```bash
+agy plugin install https://github.com/postmanlabs/postman-plugin
+```
+
+Run the same command again to update; `agy plugin uninstall postman` removes it.
+In the Antigravity app, **Customizations → Plugins → + Install from URL** takes
+the same URL.
+
 ### Claude Code
 
 [View Postman on Claude Plugins](https://claude.com/plugins/postman)
@@ -60,6 +70,16 @@ codex plugin add postman@postman
 /add-plugin postman
 ```
 
+### GitHub Copilot CLI
+
+```bash
+copilot plugin marketplace add postmanlabs/postman-plugin
+copilot plugin install postman@postman
+```
+
+`copilot plugin marketplace update postman`, then `copilot plugin update postman`, updates it. Sign in to Postman's MCP server
+with `/mcp` inside a Copilot CLI session.
+
 ### Factory Droid
 
 ```bash
@@ -172,15 +192,19 @@ test consumers without waiting for the real service to be ready or available.
 
 The mock stays local until you choose to push and deploy it. When teammates or
 external systems need access, the same mock can become a durable hosted URL
-without rebuilding it in another tool.
+without rebuilding it in another tool. Pushed to the service's own workspace,
+it's the mock other teams' simulations pull first.
 
 ### Develop against simulated dependencies
 
-The [`api-simulation`](https://github.com/postmanlabs/postman-plugin/blob/main/skills/api-simulation/) skill is the local loop for a
-service change: find every dependency the service calls, mock each one (reusing
-the owning team's mock when they publish one), serve them on one port from one
-`.sim.yaml`, run the real service against them, test, and push. It needs
-Postman CLI 1.70.0 or later:
+The [`api-simulation`](https://github.com/postmanlabs/postman-plugin/blob/main/skills/api-simulation/) skill runs your code (a service
+you're changing, a frontend, a test suite or a demo) for real against stand-ins
+for the HTTP services it calls, served together on one port from one
+`.sim.yaml`. Each stand-in is the owning team's mock when they publish one.
+It reuses an existing `.sim.yaml`, proves a change with a request through the
+changed path, and answers "what happens if X goes down" by running each failure.
+Pushing the simulation is optional and needs your approval. It needs Postman CLI
+1.70.0 or later:
 
 ```bash
 postman simulation run postman/simulations/orders-dev.sim.yaml --port 4900

package/dist/hosts/antigravity.js

@@ -0,0 +1,47 @@
+import { REPO } from '../source.js';
+import { guard, mustProbeJson, mustRun, parseJson } from './shared.js';
+import { result } from './types.js';
+// `agy plugin install` clones a git URL into ~/.gemini/config/plugins/<name>. It has no update
+// command; installing again replaces the copy in place, so a re-run is the update.
+const PLUGIN_NAME = 'postman', SOURCE = `https://github.com/${REPO}`, NEXT = 'Restart Antigravity for the change to take effect.';
+const isOurs = (plugin) => plugin.name === PLUGIN_NAME;
+export const antigravity = {
+    id: 'antigravity',
+    name: 'Antigravity',
+    route: '.antigravity-plugin',
+    async detect(system) {
+        return (await system.which('agy')) !== null;
+    },
+    async status(system) {
+        const exec = await system.probe('agy', ['plugin', 'list', '--json']), plugins = exec.code === 0 ? parseJson(exec.stdout) : null;
+        if (!Array.isArray(plugins)) {
+            return { installed: null, detail: 'could not read `agy plugin list --json`', notes: [] };
+        }
+        const installed = plugins.find(isOurs);
+        if (!installed) {
+            return { installed: false, detail: 'not installed', notes: [] };
+        }
+        return {
+            installed: true,
+            detail: `${PLUGIN_NAME} ${installed.version ?? ''}`.trim(),
+            notes: installed.enabled === false ? ['installed but disabled; run `agy plugin enable postman`'] : []
+        };
+    },
+    install(system) {
+        return guard(async () => {
+            const plugins = await mustProbeJson(system, 'agy', ['plugin', 'list', '--json']), current = plugins.some(isOurs);
+            await mustRun(system, 'agy', ['plugin', 'install', SOURCE]);
+            return result('done', `${current ? 'updated' : 'installed'} ${PLUGIN_NAME}`, NEXT);
+        });
+    },
+    remove(system) {
+        return guard(async () => {
+            const plugins = await mustProbeJson(system, 'agy', ['plugin', 'list', '--json']);
+            if (!plugins.some(isOurs)) {
+                return result('skipped', 'not installed');
+            }
+            await mustRun(system, 'agy', ['plugin', 'uninstall', PLUGIN_NAME]);
+            return result('done', `uninstalled ${PLUGIN_NAME}`, NEXT);
+        });
+    }
+};

package/dist/hosts/copilot.js

@@ -0,0 +1,60 @@
+import { REPO } from '../source.js';
+import { guard, mustProbeJson, mustRun, parseJson } from './shared.js';
+import { result } from './types.js';
+// Copilot CLI is deprecating direct installs (repos, URLs, local paths), so this installs from this
+// repo as a marketplace, which Copilot reads from `.claude-plugin/marketplace.json`. Once Postman is
+// listed in awesome-copilot, which Copilot ships registered, `postman@awesome-copilot` replaces it.
+const PLUGIN_NAME = 'postman', MARKETPLACE = 'postman', PLUGIN_ID = `${PLUGIN_NAME}@${MARKETPLACE}`, NEXT = 'Restart Copilot CLI (or run /restart) for the change to take effect.';
+const isOurs = (plugin) => plugin.name === PLUGIN_NAME, 
+// A direct install has no marketplace; it would load the same skills a second time.
+isDirect = (plugin) => isOurs(plugin) && !plugin.marketplace;
+export const copilot = {
+    id: 'copilot',
+    name: 'GitHub Copilot CLI',
+    route: '.github/plugin',
+    async detect(system) {
+        return (await system.which('copilot')) !== null;
+    },
+    async status(system) {
+        const exec = await system.probe('copilot', ['plugin', 'list', '--json']), plugins = exec.code === 0 ? parseJson(exec.stdout) : null;
+        if (!Array.isArray(plugins)) {
+            return { installed: null, detail: 'could not read `copilot plugin list --json`', notes: [] };
+        }
+        const installed = plugins.find(isOurs);
+        if (!installed) {
+            return { installed: false, detail: 'not installed', notes: [] };
+        }
+        return {
+            installed: true,
+            detail: `${PLUGIN_NAME} ${installed.version ?? ''}`.trim(),
+            notes: installed.enabled === false ? ['installed but disabled; run `copilot plugin enable postman`'] : []
+        };
+    },
+    install(system) {
+        return guard(async () => {
+            const plugins = await mustProbeJson(system, 'copilot', ['plugin', 'list', '--json']), marketplaces = await mustProbeJson(system, 'copilot', ['plugin', 'marketplace', 'list', '--json']), current = plugins.some((plugin) => isOurs(plugin) && plugin.marketplace === MARKETPLACE);
+            if (marketplaces.some((marketplace) => marketplace.name === MARKETPLACE)) {
+                await mustRun(system, 'copilot', ['plugin', 'marketplace', 'update', MARKETPLACE]);
+            }
+            else {
+                await mustRun(system, 'copilot', ['plugin', 'marketplace', 'add', REPO]);
+            }
+            // The same name can't be installed twice, so a direct install goes first.
+            if (plugins.some(isDirect)) {
+                await mustRun(system, 'copilot', ['plugin', 'uninstall', PLUGIN_NAME]);
+            }
+            await mustRun(system, 'copilot', current ? ['plugin', 'update', PLUGIN_NAME] : ['plugin', 'install', PLUGIN_ID]);
+            return result('done', `${current ? 'updated' : 'installed'} ${PLUGIN_ID}`, NEXT);
+        });
+    },
+    remove(system) {
+        return guard(async () => {
+            const plugins = await mustProbeJson(system, 'copilot', ['plugin', 'list', '--json']);
+            if (!plugins.some(isOurs)) {
+                return result('skipped', 'not installed');
+            }
+            await mustRun(system, 'copilot', ['plugin', 'uninstall', PLUGIN_NAME]);
+            return result('done', `uninstalled ${PLUGIN_NAME}`, NEXT);
+        });
+    }
+};

package/dist/hosts/index.js

@@ -1,8 +1,10 @@
+import { antigravity } from './antigravity.js';
 import { claudeCode } from './claude-code.js';
 import { codex } from './codex.js';
+import { copilot } from './copilot.js';
 import { cursor } from './cursor.js';
 import { factory } from './factory.js';
 import { kimi } from './kimi.js';
 import { opencode } from './opencode.js';
 import { pi } from './pi.js';
-export const HOSTS = [claudeCode, codex, cursor, factory, kimi, opencode, pi];
+export const HOSTS = [antigravity, claudeCode, codex, copilot, cursor, factory, kimi, opencode, pi];

package/mcp.pi.json

@@ -6,8 +6,8 @@
       "description": "Postman workspaces, collections, specs, environments, mocks and monitors",
       "headers": {
         "X-Source": "postman-pi-plugin",
-        "X-Plugin-Version": "0.3.0",
-        "User-Agent": "postman-pi-plugin/0.3.0"
+        "X-Plugin-Version": "0.4.0",
+        "User-Agent": "postman-pi-plugin/0.4.0"
       }
     }
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@postman/postman-plugin",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "description": "Postman's API engineering skills for coding agents: a Pi package, and an npx installer that sets up Claude Code, Codex, Cursor, Kimi Code, Factory Droid, OpenCode and Pi.",
   "type": "module",
   "license": "Apache-2.0",

package/skills/ai-readiness/SKILL.md

@@ -1,50 +1,46 @@
 ---
 name: ai-readiness
-description: Scores a Postman collection or an OpenAPI spec for how well an AI agent can discover, understand, call, and recover from errors with it — missing examples, undocumented errors, and ambiguous parameters all cost points. Use when the user asks "is my API agent-ready," "can AI agents use my API," "how agent-friendly is my API," or wants to scan, score, or improve a collection or spec for AI/agent consumption. Covers `postman collection ai-readiness` and `postman spec ai-readiness`.
+description: Use when assessing or improving how well AI agents can discover, call, and recover from errors with an API. Scores an existing Postman collection or OpenAPI spec and turns measured gaps into contract improvements; supports a separate CI readiness threshold. Use for requests such as "is this API ready for agents".
 ---
 
 # AI Readiness
 
-## Overview
-
-An "agent-ready" API is one that an AI agent can discover, understand, call correctly, and recover from errors without human intervention. Most APIs aren't there yet.
-
-Two ways to run this check, same rubric family, different target — pick by what exists:
-
-- `collection ai-readiness <collectionId/path>` scores a Postman collection
-  — by cloud ID, local file path, or a `postman/collections/<name>`
-  local-mode directory.
-- `spec ai-readiness <spec>` scores an OpenAPI specification directly — by
-  cloud ID or local file path — with no collection involved at all.
-
-
-
-## Scoring
-
-The command computes and prints the score itself — read the fields it
-gives you, don't recompute them:
-
-- **`readiness`** (score 0-100 + bucket) is the headline number. Buckets,
-  low to high: **Limited → Fair → Good → Excellent**.
-- **`confidence`** (`high`/`medium`/`low`) says how many signals it
-  could actually measure vs. had to mark `unknown` — a data-quality
-  caveat, not part of the score.
-
-## Interpreting Results
-
-Report the bucket, score, and confidence the command actually printed
-— don't infer a percentage band. Doc coverage is a modifier via its
-adjustment, not a separate gate; call it out by name when it's `low`,
-since recommendations flag that first. Also state which verb ran
-(`collection` vs. `spec` `ai-readiness`), which target was scored
-(local path vs. cloud ID), the output mode, and — if `--min-score` was
-set — the resulting exit code, not just "it passed."
-
-You can ask user if they would like to set this check with a min score guarantee to run on their CI.
-
-## Reference
-
-- `collection-schema-v3` skill — what saved examples and descriptions look
-  like in the git-synced format this command reads.
-- `ci-integration` skill — where `--min-score` fits as a pipeline gate
-  alongside `spec lint`/`collection lint`/`workspace lint`.
+An agent must choose an operation, supply valid inputs, and interpret failures
+from the contract it can see. Postman's readiness check exposes gaps in that
+context—such as missing examples or ambiguous parameters—so improvements live
+in the shared contract instead of being rediscovered in each agent session.
+
+Skip scoring for a typo fix, a one-off endpoint check, or a task that changes
+neither the contract nor agent usability; inspect the relevant fields or use
+**api-testing** instead. Score when prioritizing consumability improvements,
+checking their effect, or enforcing an agreed readiness gate.
+
+1. Score the artifact consumers actually use. `postman collection ai-readiness
+   <path-or-id>` reads a collection, including a local v3 directory;
+   `postman spec ai-readiness <path-or-id>` reads an OpenAPI spec directly.
+   Generating a collection solely to score a spec adds a second artifact
+   without improving the evidence. Use the installed command's `-h` for options.
+2. Use the reported `readiness` score and bucket (Limited, Fair, Good,
+   Excellent). Keep `confidence` separate: low confidence means signals could
+   not be measured, so even a high score may leave consequential unknowns.
+   Report low documentation coverage when flagged; it modifies the score
+   rather than acting as an independent pass/fail gate.
+3. Prioritize gaps that would change a caller's behavior: unclear required
+   inputs, missing auth instructions, or errors with no recovery guidance.
+   Establish the actual behavior before adding descriptions or examples;
+   invented certainty can raise apparent completeness while misleading agents.
+   See **api-documentation** for improving the authoritative contract and
+   **collection-schema-v3** for saved examples.
+4. Re-run against the edited artifact to show which measured gaps closed.
+   A readiness score measures consumability, not live correctness; use
+   **api-testing** when the claim also depends on API behavior.
+5. A `--min-score` gate is useful when the team wants to prevent readiness
+   regressions. Choose the threshold from its baseline and expectations;
+   keep it separate from tests and lint through **ci-integration** so a failure
+   identifies the kind of regression.
+
+## Verification
+
+Report the target, collection/spec mode, actual score, bucket, confidence,
+and remaining gaps. If a threshold ran, include its exit code; a successful
+scan alone does not establish that the threshold passed.

package/skills/api-discovery/SKILL.md

@@ -1,151 +1,70 @@
 ---
 name: api-discovery
-description: Discover and use APIs from the web or Postman. Find and integrate public third-party APIs with Orbit, locate Postman entities with search, and use the Context Graph to investigate dependencies, ownership, runtime behavior, and change impact across an API ecosystem.
+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".
 ---
 
 # API Discovery
 
-## Overview
-
-Use this guide for any task that involves discovering an API — whether it
-lives on the public web or inside Postman as a workspace, collection, request,
-spec, mock, document, or flow. You can find entities across every surface: your
-own private work, anything your team or organization shares, and resources
-owned by external organizations. Beyond finding entities, this guide also
-covers understanding how they relate to one another — for example, "which
-services consume this API?"
-
-Each discovery option serves a distinct purpose:
-
-- **Orbit** → discovers and integrates **public third-party APIs**. No signup
-  or API key, and it uses ~27× less context than loading a vendor OpenAPI spec.
-  Search returns matching endpoints — including what each one
-  *cannot* do — and integrate returns a task brief specific enough to write
-  code against. It accepts both keyword and natural-language queries. Reach for
-  it instead of writing a third-party integration from memory.
-- **`search`** → **finds any Postman entity**, for tasks like "update the tests
-  in my collection and run them" or "where is the documentation for our
-  access-control API?"
-- **`context-graph ask`** → answers organization-wide relationship and impact
-  questions such as "what depends on billing-api?" or "what could this schema
-  change break?"
-
-These three draw on different data sources, so a miss in one is not proof of a
-miss in the others. `search` locates a known Postman resource; the Context
-Graph discovers relationships around a known starting point. Use both when a
-task needs the resource itself and its wider impact.
-
-## Orbit — Public API Discovery
-
-Orbit finds public third-party APIs. It's free, needs no signup or API key, and
-works entirely against publicly available APIs. REST base:
-`https://api.buildwithorbit.ai`. Docs: `https://www.buildwithorbit.ai`.
-
-Reach for Orbit whenever a task needs an external capability — weather,
-payments, invoicing, messaging, geocoding, calendar, and so on — even when the
-user already named a provider. Rather than writing integration code from
-memory, let Orbit hand you the details that matter: paths, auth header names,
-required fields, and the rest. It works in two steps, search then integrate,
-and a typical round trip runs ~2,500 tokens and ~15–20s end to end — against
-~69,000 tokens for a full vendor OpenAPI spec.
-
-Two REST calls, both `POST`:
-
-1. **Search** (`POST /v1/search`) — describe the task, e.g.
-   `{ "q": "send email via SMTP" }`. Returns candidate endpoints, each with an
-   `id` and `resourceType` (pass both back verbatim) and an `evaluateGuide`
-   grading its fit.
-2. **Integrate** (`POST /v1/integrate`) — send the task plus the chosen
-   resources (up to 10). Returns a `taskBrief` with `FIT`, `AUTH`, `BASE URL`,
-   `STEPS`, and `GOTCHAS` — read the GOTCHAS before writing the client.
-
-Full endpoint schemas, request/response shapes, `taskBrief` fields, and error
-handling: [reference/orbit.md](reference/orbit.md).
-
-## `search`
-
-`postman search <type> <query>` finds any Postman entity, searching across
-`requests`, `collections`, `workspaces`, `flows`, `specs`, `mocks`,
-`environments`, or `documents`. The query can be a keyword or natural language,
-and is optional (omit it to list or filter a type outright). Narrow with
-`--ownership` and `--filter`, and add `-o json` for the enriched payload. An
-empty default-scope result is not proof nothing exists — retry with
-`--ownership all` before reporting that.
-
-```bash
-postman search requests "where do we validate a user's email?"
-postman search collections "payments" --ownership external --filter "visibility=public"
-```
-
-Use `postman search <type> -h` for more details — ownership modes, the
-`--filter` / `--filter-json` syntax, filter fields per type, and the exact
-installed-version flags.
-
-## `context-graph`
-
-The Context Graph is a private, authenticated map of an API ecosystem. It
-reconciles Postman specifications, collections, monitors, and mocks; GitHub
-repositories, definitions, and call sites; and New Relic deployments, traffic,
-and telemetry. These become typed entities joined by sourced relationships such
-as `calls`, `depends_on`, `owned_by`, and `monitored_by`.
-
-Use it before a cross-service or potentially breaking change. Name the endpoint,
-schema, service, database, deployment, or shared module being changed; the graph
-discovers the surrounding scope, including runtime callers and repositories not
-checked out locally:
-
-```bash
-postman context-graph ask "What depends on billing-api?" --wait
-postman context-graph ask "What is the likely blast radius of changing this schema?" --wait
-```
-
-Treat the result as a lead, not proof. For consequential work, verify candidates
-against source, API definitions, deployment configuration, or telemetry and
-cite that evidence. Sources are connected through Postman's Agent Context UI
-and refresh nightly; an unconnected or not-yet-ingested source makes absence
-inconclusive.
-
-`--wait` polls the asynchronous API and prints the answer. Without it, `ask`
-returns an ID for `postman context-graph status <askId>`. Use `--json` for the
-structured record; `--timeout`, `--interval`, and `--max-steps` control waiting
-and reasoning.
-
-The query runs against the team derived from the API key; there is no workspace
-or team selector. Authentication uses `--api-key`, `POSTMAN_API_KEY`, or the
-current `postman login` session, in that order.
-
-## After discovery: reusing what was found
-
-Finding another service's workspace does not make it the workspace for the
-current repository. `workspace pull` is for working on the service that owns
-that workspace, from that service's repository. If the service is only a
-dependency, or the user only wants to inspect one of its resources, keep the
-current repository connected to its own workspace and use the dependency
-feature instead.
-
-Use `postman dependency add <type> <name-or-id>` to declare and download the
-selected resource rather than copying it by hand or pulling the other
-service's entire workspace. Supported types are `collection`, `environment`,
-and `mock`. Pass the entity ID returned by `search`, or use the entity name;
-when resolving a name in a specific workspace, add `--workspace
-<workspace-id>`. If the Context Graph identifies only a service or API, locate
-the concrete entity with `search` first.
-
-Dependencies are recorded in `.postman/resources.yaml` and downloaded under
-`postman/.dependencies/`, so the copy works locally straight away. Use
-`postman dependency list` to inspect declarations, `postman dependency
-install` to download declared dependencies after a clone or in CI, `postman
-dependency update` to refresh them from Postman, and `postman dependency
-remove <name-or-id>` to delete a declaration and its downloaded files. The
-`list`, `install`, `update`, and `remove` commands accept `--type <type>`;
-`install` and `update` can also target one declared dependency by name.
-
-## Reference
-
-- [Orbit](reference/orbit.md) — public API discovery: the search/integrate
-  REST endpoints, request/response shape, `taskBrief` fields, and error
-  handling. (Docs at `https://www.buildwithorbit.ai`, REST at
-  `https://api.buildwithorbit.ai`.)
-
-For `postman search`, run `postman search <type> -h` — the CLI's own help is
-per-type, complete, and always matches your installed version.
+Existing contracts and owners' mocks reduce the assumptions an integration
+must invent. Relationship context broadens investigation beyond the checkout:
+passing this service's own tests does not establish that its consumers can
+still use a changed interface.
+
+1. Choose the source by the question:
+
+   | Need | Use |
+   | --- | --- |
+   | Public provider endpoints and integration details | Orbit search, then integrate |
+   | A concrete Postman collection, request, spec, mock, or workspace | `postman search <type> <query>` |
+   | Consumers, ownership, dependencies, or likely change impact | `postman context-graph ask` |
+
+   These sources answer different questions. A miss in one does not establish
+   absence in the others; combine entity search and relationship context when
+   both the resource and its impact matter.
+2. For public APIs, Orbit narrows discovery to task-relevant endpoints and
+   returns integration guidance instead of requiring a whole vendor spec in
+   context. Use it even when the provider is chosen: endpoint details and
+   capability limits still determine whether the integration fits the task.
+   `POST https://api.buildwithorbit.ai/v1/search` accepts a task in
+   `q`; pass the chosen results' `id` and `resourceType` unchanged to
+   `/v1/integrate`. Evaluate fit and limitations before choosing a provider,
+   then use the returned auth, base URL, steps, and gotchas to implement.
+   Read [Orbit's request schemas](reference/orbit.md) for the actual payloads
+   and error handling. Orbit access does not supply a provider's credentials.
+3. For Postman resources, narrow by entity type, ownership, and workspace.
+   Read `postman search <type> -h` for supported filters. An empty result in
+   the default ownership scope is incomplete evidence; consider
+   `--ownership all` or a relevant narrower scope before declaring absence.
+   Inspect the selected resource's owner and content rather than trusting a
+   similar name.
+4. For cross-service changes, ask the Context Graph a concrete question about
+   the endpoint, schema, or service. `--wait` waits for an answer; without it,
+   use the returned ID with `postman context-graph status <askId>`. The graph
+   can connect Postman definitions, repository call sites, and runtime
+   telemetry beyond the current checkout. Its coverage depends on connected
+   and ingested sources, so verify consequential leads against definitions,
+   source, or telemetry before treating them as facts. A newly added call may
+   not be present yet. The query uses the authenticated API key's team, not
+   the repository's workspace binding; changing that binding cannot fix a
+   query against the wrong organization's context.
+5. Use **bootstrap**'s "Owning workspace versus dependency" distinction
+   before importing. For a dependency, `postman dependency add
+   <collection|environment|mock> <name-or-id>` declares and downloads the
+   selected resource without rebinding the repository. Prefer the discovered
+   ID; `--workspace <id>` disambiguates names. If the graph only identified a
+   service, search for its concrete resource first.
+6. Dependency declarations live in `.postman/resources.yaml`, with downloads
+   in `postman/.dependencies/`. `dependency install` restores them after a
+   clone or in CI; `dependency update` refreshes them. Review refreshes when
+   they can change test expectations. Copy a dependency into owned files to
+   customize it, because updating dependencies overwrites downloaded edits.
+   Use `dependency list` and command-specific help for targeted operations.
+
+Use **api-simulation** to exercise the real service against discovered mocks,
+and **ci-integration** to keep the resulting contract checks repeatable in PRs.
+
+## Verification
+
+Report which source answered the question, the resource IDs or evidence it
+returned, what was reused, and any coverage gaps. A list of candidates alone
+is neither an integration nor proof of compatibility.

package/skills/api-discovery/reference/orbit.md

@@ -10,18 +10,21 @@ signup and no API key, and works entirely against publicly available APIs.
 ## Implementation
 
 Two REST calls, both `POST`, both read-only (safe to retry). No auth header —
-send `Content-Type: application/json` and a JSON body. Run search first,
-surface candidates, then integrate the chosen ids.
+send `Content-Type: application/json` and a JSON body. Optionally identify your
+client with `Orbit-Client-Name` (see below). Run search first, surface
+candidates, then integrate the chosen ids.
 
 ```bash
 # Step 1 — search
-curl -sS https://api.buildwithorbit.ai/v1/search \
+curl -sS 'https://api.buildwithorbit.ai/v1/search?limit=10' \
   -H 'Content-Type: application/json' \
-  -d '{ "q": "send email via SMTP", "limit": 10 }'
+  -H 'Orbit-Client-Name: claude/opus-4.8' \
+  -d '{ "q": "send email via SMTP" }'
 
 # Step 2 — integrate (ids come from the search response, verbatim)
 curl -sS https://api.buildwithorbit.ai/v1/integrate \
   -H 'Content-Type: application/json' \
+  -H 'Orbit-Client-Name: claude/opus-4.8' \
   -d '{
     "task": "Send a welcome email when a user signs up",
     "resources": [{ "id": "urn:orbit:endpoint:v1:...", "type": "endpoint" }]
@@ -37,12 +40,22 @@ Implementation notes:
   than making one call per endpoint.
 - Auth, request bodies, `Threading`, and `GOTCHAS` come from live public API
   schemas, so take them from the brief rather than from memory.
+- `Orbit-Client-Name` is an optional request header (both endpoints, max 128
+  chars) that names the calling client/agent for Orbit's anonymous usage
+  analytics. The convention is `client/model`, slash-separated —
+  e.g. `claude/opus-4.8`, `cursor/composer-2.5`, `codex/gpt-5.6-sol` — or a bare
+  client name like `vscode`. Set it to the host agent and model running this
+  plugin. It never affects results and can be omitted.
 
 ## Step 1 — Search (`POST /v1/search`)
 
 Describe the task, not a provider name. Good: `"send an invoice to a customer"`.
 Worse: `"PayPal"`. Provider name is fine to include when it is fixed.
 
+Request body (JSON):
+
+- `q` — the query; max 512 characters.
+
 ```json
 { "q": "send email via SMTP" }
 ```
@@ -51,7 +64,6 @@ Query params:
 
 - `limit` — default 10, max 25.
 - `cursor` — from `meta.nextCursor`; pagination stops at 40 results.
-- `q` — max 512 characters.
 
 Returns `data[]`. Each item has: