@cursor/july 0.1.30 → 0.1.31

package/docs/example-agents/weather-agent.md

@@ -1,16 +1,16 @@
 ---
-title: "Explore the full agentkit surface with a weather agent"
+title: "Explore the full Agent SDK surface with a weather agent"
 description: "Trace tools, MCP, channels, approvals, skills, subagents, schedules, hooks, A/B metrics, and evals through one local agent."
 ---
 
-# Explore the full agentkit surface with a weather agent
+# Explore the full Agent SDK surface with a weather agent
 
 The weather agent is the broadest small example in the repository. It fetches
 live conditions and forecasts, converts units through MCP, writes notes in a
 session workspace, and pauses an alert tool for human approval. The same agent
 also runs from HTTP, Slack, a schedule, and the MCP endpoint.
 
-Use this project when you want to see how agentkit's filesystem pieces fit
+Use this project when you want to see how the Agent SDK's filesystem pieces fit
 together before you design a larger agent.
 
 [Browse the weather agent source.](../../examples/weather-agent/)
@@ -42,7 +42,7 @@ A current-weather question takes this path:
    guessing.
 3. The server tool geocodes the city, fetches Open-Meteo, validates the
    response, and returns normalized fields.
-4. The agent writes a short answer. Agentkit records every event in the
+4. The agent writes a short answer. The Agent SDK records every event in the
    session stream.
 5. The audit hook observes `turn.completed`. If the session joined the A/B
    experiment, the collector updates its metrics too.
@@ -61,16 +61,20 @@ You need:
 - Network access to Open-Meteo.
 - Python 3 for `save_weather_note`.
 
-The project mounts an account-linked Slack channel. Agentkit checks the
+The project mounts an account-linked Slack channel. The Agent SDK checks the
 connection at startup, so sign in even when you plan to call a deterministic
 tool.
 
-The optional approval-enabled Slack app also needs:
+The optional approval-enabled Slack app also needs a token pair.
+`agent-sdk slack create --dir examples/weather-agent` provisions the
+app and writes the tokens for you (see the
+[Slack guide](../guides/slack.md#set-it-up)); with hand-minted tokens,
+export them instead:
 
 ```bash
 export WEATHER_AGENT_SLACK_BOT_TOKEN=xoxb-...
 export WEATHER_AGENT_SLACK_APP_TOKEN=xapp-...
-agentkit slack doctor --prefix WEATHER_AGENT
+agent-sdk slack doctor --prefix WEATHER_AGENT
 ```
 
 Without those two tokens, the dedicated channel stays idle. The
@@ -79,9 +83,9 @@ account-linked channel still works.
 ## Inspect before running
 
 ```bash
-agentkit validate --dir examples/weather-agent
-agentkit info --dir examples/weather-agent --json
-agentkit eval --dir examples/weather-agent --list
+agent-sdk validate --dir examples/weather-agent
+agent-sdk info --dir examples/weather-agent --json
+agent-sdk eval --dir examples/weather-agent --list
 ```
 
 The manifest should report five tools, one skill, one MCP connection, one
@@ -93,37 +97,37 @@ experiment. The eval listing should report eight cases.
 Start with the current-weather server tool:
 
 ```bash
-agentkit call get_weather \
+agent-sdk call get_weather \
   --dir examples/weather-agent \
   --input '{"city":"New York City"}'
 ```
 
-`defineTool` gives the input a Zod schema. Agentkit validates the JSON before
+`defineTool` gives the input a Zod schema. The Agent SDK validates the JSON before
 `execute` runs. The result includes the matched place, condition,
 temperature, humidity, wind, gusts, and precipitation.
 
 Try the forecast:
 
 ```bash
-agentkit call get_forecast \
+agent-sdk call get_forecast \
   --dir examples/weather-agent \
   --input '{"city":"Lisbon","days":5}'
 ```
 
 The tool accepts one to seven days. Shared Open-Meteo code lives under
-`agent/lib/`, so agentkit imports it without discovering another tool.
+`agent/lib/`, so the Agent SDK imports it without discovering another tool.
 
 ## Compare server and agent execution
 
 Most weather tools use the default `execution: "server"`. Their TypeScript
 runs inside the serve host and can reach `ctx.host` services.
 
-`save_weather_note` uses `execution: "agent"` instead. Agentkit materializes
+`save_weather_note` uses `execution: "agent"` instead. The Agent SDK materializes
 its script into the agent environment. The script reads JSON from stdin and
 appends to `weather-notes.md` in that session's workspace:
 
 ```bash
-agentkit run --dir examples/weather-agent \
+agent-sdk run --dir examples/weather-agent \
   --message "Save a note that Boston is cold and windy."
 ```
 
@@ -131,14 +135,14 @@ Each session gets its own workspace. Saving a note doesn't edit the authored
 example.
 
 This split matters on cloud. Server tools are local-runtime only. For a cloud
-turn, agentkit includes an agent tool's catalog and script body in the first
+turn, the Agent SDK includes an agent tool's catalog and script body in the first
 prompt. The cloud model writes and invokes the script in its VM; the serve
 host doesn't materialize it there.
 
 ## Use one MCP connection in three places
 
 `agent/mcp-connections/units.ts` starts a local stdio server. The filename
-makes its server name `units`. Agentkit exposes it to:
+makes its server name `units`. The Agent SDK exposes it to:
 
 - the model as MCP tools,
 - server tools through `ctx.host.mcp`, and
@@ -147,7 +151,7 @@ makes its server name `units`. Agentkit exposes it to:
 `convert_temperature` demonstrates the server-tool path:
 
 ```bash
-agentkit call convert_temperature \
+agent-sdk call convert_temperature \
   --dir examples/weather-agent \
   --input '{"value":72,"from":"F"}'
 ```
@@ -155,7 +159,7 @@ agentkit call convert_temperature \
 The custom channel demonstrates the handler path. Start the dev server:
 
 ```bash
-agentkit dev examples/weather-agent
+agent-sdk dev examples/weather-agent
 ```
 
 Then call MCP deterministically through `/convert`:
@@ -201,7 +205,7 @@ authentication, and asynchronous handlers.
 playground and the model's tool call parks before `execute`:
 
 ```bash
-agentkit dev examples/weather-agent
+agent-sdk dev examples/weather-agent
 ```
 
 Open the printed playground URL, ask:
@@ -216,12 +220,12 @@ The example tool returns a placeholder success object. It doesn't contact
 Slack, PagerDuty, or an ops board. Replace its `execute` body with your own
 sink before adapting it.
 
-Use a model turn for this proof. A deterministic `agentkit call` runs the
+Use a model turn for this proof. A deterministic `agent-sdk call` runs the
 tool body directly and doesn't demonstrate the parked approval flow.
 
 ## Load procedures and delegate research
 
-The forecast skill gives the root agent an on-demand procedure. Agentkit
+The forecast skill gives the root agent an on-demand procedure. The Agent SDK
 advertises the skill's description, then the harness loads its content when
 the request matches.
 
@@ -230,7 +234,7 @@ parent when to delegate. It inherits the parent's execution surface, but
 gets its own instructions:
 
 ```bash
-agentkit run --dir examples/weather-agent \
+agent-sdk run --dir examples/weather-agent \
   --message "Compare record summer temperatures across Paris, London, and Rome."
 ```
 
@@ -270,8 +274,8 @@ policy.
 List and run the evals:
 
 ```bash
-agentkit eval --dir examples/weather-agent --list
-agentkit eval --dir examples/weather-agent --json
+agent-sdk eval --dir examples/weather-agent --list
+agent-sdk eval --dir examples/weather-agent --json
 ```
 
 Six cases cover current weather and forecasts against live Open-Meteo. Two

package/docs/guides/agent-to-agent.md

@@ -34,7 +34,7 @@ channel, bind to the calling principal, and show up in the playground
 and `GET /v1/sessions` like any other session.
 
 Any MCP client can attach to this endpoint. It isn't only for other
-agentkit agents.
+Agent SDK agents.
 
 ## Wire a peer MCP connection
 
@@ -57,8 +57,8 @@ delegation, except the peer is a full agent that keeps its own
 instructions, tools, MCP connections, and sessions.
 
 ```bash
-agentkit serve --dir ./agents --dev
-agentkit chat --url http://127.0.0.1:3000/concierge \
+agent-sdk serve --dir ./agents --dev
+agent-sdk chat --url http://127.0.0.1:3000/concierge \
   --message "What's the weather in Paris right now?"
 # concierge → weather.ask → weather-agent's own session/tools → reply
 ```
@@ -81,7 +81,7 @@ and `eval` use work too. Local-runtime turns (and host-side
 `ctx.host.mcp` or channel-handler calls) reach the peer over loopback,
 which works under the default auth. Cloud-runtime turns execute on a VM
 that cannot reach this host's loopback address: pass
-`--public-url https://agentkit.example.com` (or
+`--public-url https://agent-sdk.example.com` (or
 `serve(dir, { publicUrl })`) so peers resolve to a reachable URL.
 Without one, peers are omitted from cloud turns and the server warns at
 startup. With `--bearer-token`, the token is attached to peer calls

package/docs/guides/cloud-runtime.md

@@ -47,7 +47,7 @@ export default defineAgent({
 });
 ```
 
-The host must be signed in (`agentkit login` or `CURSOR_API_KEY`).
+The host must be signed in (`agent-sdk login` or `CURSOR_API_KEY`).
 
 > [!IMPORTANT]
 > Cloud agents run against the Cursor backend under the signed-in
@@ -69,7 +69,7 @@ mapping shifts:
 | `sandbox/workspace/**` | seeded into the session workspace | ignored |
 | Tool approvals (`needsApproval`) | supported | not supported |
 
-`agentkit validate` warns when `runtime: "cloud"` is combined with
+`agent-sdk validate` warns when `runtime: "cloud"` is combined with
 local-only capabilities. Those warnings match this table.
 
 Two more behaviors are cloud-specific. Sessions persist a separate SDK
@@ -106,7 +106,7 @@ These come from running a PR driver against real PR traffic:
 
 ## Verify cloud agents
 
-`agentkit run` and `eval` work unchanged. The trajectory records the
+`agent-sdk run` and `eval` work unchanged. The trajectory records the
 same event vocabulary plus `agent.bound` with the cloud URL, so you can
 open the cloud conversation for any session. Cloud turns take minutes.
 Pass generous `--timeout-ms` values, and keep curl timeouts long when

package/docs/guides/github.md

@@ -18,7 +18,7 @@ The companion skill for coding agents is
 Connect GitHub in Cursor for the repositories you care about (Settings or
 [cursor.com/dashboard](https://cursor.com/dashboard)). That gives your
 account access and lets Cursor receive the repo's webhooks. Sign the host
-in (`agentkit login` or `CURSOR_API_KEY`), then opt the channel into the
+in (`agent-sdk login` or `CURSOR_API_KEY`), then opt the channel into the
 Cursor account connection:
 
 ```ts
@@ -34,7 +34,7 @@ export default githubChannel({
 
 `cursorAccount` starts the event relay and mints one short-lived GitHub
 credential scoped to those repositories. `ctx.github`, `ctx.host.github`,
-and child `gh` commands share it. Agentkit refreshes the credential before
+and child `gh` commands share it. The Agent SDK refreshes the credential before
 expiry. No GitHub App key, PAT, or separate `gh auth login` is needed on
 the host.
 
@@ -57,7 +57,7 @@ To keep repository scope in deployment config instead, use
 `cursorAccount: true` and pass it at serve time:
 
 ```bash
-agentkit serve --dir . --cursor-events --repo owner/repo
+agent-sdk serve --dir . --cursor-events --repo owner/repo
 ```
 
 Repeat `--repo` for each repository. The stream and credential are
@@ -150,13 +150,13 @@ the same delivery.
 
 ```bash
 # Replay a pull_request delivery for a PR
-agentkit github replay https://github.com/owner/repo/pull/123 --dir .
+agent-sdk github replay https://github.com/owner/repo/pull/123 --dir .
 
 # Replay everything the channel listens for, with CI failing
-agentkit github replay owner/repo#123 --dir . --events '*' --conclusion failure
+agent-sdk github replay owner/repo#123 --dir . --events '*' --conclusion failure
 
 # Inspect payloads without POSTing, and snapshot them as fixtures
-agentkit github replay owner/repo#123 --dir . --events '*' --dry-run --out fixtures/github
+agent-sdk github replay owner/repo#123 --dir . --events '*' --dry-run --out fixtures/github
 ```
 
 `--events` defaults to `pull_request`, and `'*'` means the channel's

package/docs/guides/human-in-the-loop.md

@@ -116,7 +116,7 @@ approvals with dry-run defaults for destructive integrations: post real
 PR reviews only behind an explicit env flag like `MY_AGENT_LIVE=1`, no
 matter who approved.
 
-Deterministic tool calls (`agentkit call`, `POST /v1/tools/:name`)
+Deterministic tool calls (`agent-sdk call`, `POST /v1/tools/:name`)
 execute directly without parking. There the human is the caller.
 Approval parking applies to model-initiated calls.
 

package/docs/guides/mcp-oauth.md

@@ -1,6 +1,6 @@
 ---
 title: "Host MCP OAuth"
-description: "Authorize defineConnection({ url, oauth: true }) with agentkit mcp oauth, store tokens locally, and push MCP_OAUTH_* secrets to hosted deployments."
+description: "Authorize defineConnection({ url, oauth: true }) with agent-sdk mcp oauth, store tokens locally, and push MCP_OAUTH_* secrets to hosted deployments."
 ---
 
 # Host MCP OAuth
@@ -17,7 +17,7 @@ The companion skill is
 ## What can host MCP OAuth do?
 
 - Authorize `defineConnection({ url, oauth: true })` with a browser PKCE
-  flow (`agentkit mcp oauth <connection>`)
+  flow (`agent-sdk mcp oauth <connection>`)
 - Keep tokens in `~/.config/agent-serve/mcp-auth.json`, bound to that
   connection's resource URL
 - Upsert deployment secrets with `--store` so hosted engines seed the
@@ -56,7 +56,7 @@ export default defineConnection({
 
 Rules of the road:
 
-- `oauth: true` is required for `agentkit mcp oauth`
+- `oauth: true` is required for `agent-sdk mcp oauth`
 - `hostOnly: true` hides the server from the model; `ctx.host.mcp` and
   channel handlers still see it
 - Declare expected secret names on the agent when you plan to `--store`:
@@ -86,12 +86,12 @@ underscores (`inventory` → `MCP_OAUTH_INVENTORY_…`).
 From the agent project (Node 22.13+, not Bun):
 
 ```bash
-agentkit mcp oauth inventory
+agent-sdk mcp oauth inventory
 ```
 
 What happens:
 
-1. agentkit loads `agent/mcp-connections/inventory.ts` and checks
+1. The Agent SDK loads `agent/mcp-connections/inventory.ts` and checks
    `oauth: true`
 2. It opens the authorization URL in your browser
 3. The callback lands on `http://localhost:8787/callback`
@@ -107,7 +107,7 @@ connection URL (tokens are bound to the resource URL).
 Authorize once, then push secrets to the deployment:
 
 ```bash
-agentkit mcp oauth inventory --store
+agent-sdk mcp oauth inventory --store
 # optional:
 #   --slug my-agent
 #   --team <cursor-team-id>
@@ -121,9 +121,9 @@ agentkit mcp oauth inventory --store
 | `MCP_OAUTH_<NAME>_REFRESH_TOKEN` | refresh token when the server returns one |
 | `MCP_OAUTH_<NAME>_CLIENT_ID` | dynamic client id when registration returned one |
 
-You must be signed in (`agentkit login`) with permission to set secrets
+You must be signed in (`agent-sdk login`) with permission to set secrets
 on that slug. Secrets apply on the **next** deploy; run
-`agentkit deploy` (or wait for your usual deploy path) after `--store`.
+`agent-sdk deploy` (or wait for your usual deploy path) after `--store`.
 
 On the engine, when `mcp-auth.json` is empty, serve seeds the OAuth
 provider from those env vars so host MCP calls work without a browser
@@ -151,7 +151,7 @@ tool instead.
 | --- | --- |
 | `must be defineConnection({ url, oauth: true })` | Add `oauth: true` on that connection, or pick the right connection name |
 | Callback never completes | Keep port `8787` free; finish the browser login on this machine |
-| Hosted calls unauthorized after `--store` | Confirm secrets with `agentkit secrets list <slug>`, then redeploy |
+| Hosted calls unauthorized after `--store` | Confirm secrets with `agent-sdk secrets list <slug>`, then redeploy |
 | Tokens ignored after URL change | Expected: resource URL binding drops stale entries. Re-run `mcp oauth` |
 
 ## What's next

package/docs/guides/slack.md

@@ -1,14 +1,15 @@
 ---
 title: "Slack"
-description: "Put the agent in Slack over Socket Mode: manifests, tokens, doctor, engagement rules, access policy, and approval buttons."
+description: "Put the agent in Slack over Socket Mode: Add to Slack provisioning, manifests, tokens, doctor, engagement rules, access policy, and approval buttons."
 ---
 
 # Slack agents
 
 The Slack channel puts your agent in Slack over Socket Mode: no public
 Request URL, streaming replies in threads, tool "thinking" steps,
-suggested prompts, and opt-in approval buttons. Setup is four short
-phases. Two are yours, and two need a human with Slack admin access.
+suggested prompts, and opt-in approval buttons. Cursor's **Add to
+Slack** provisioning handles the setup in one CLI command or one
+dashboard click; the manual manifest flow remains as a fallback.
 
 The companion skill is
 [`skills/setup-slack/SKILL.md`](../../skills/setup-slack/SKILL.md).
@@ -59,7 +60,7 @@ export default slackChannel({
 });
 ```
 
-Sign the host in (`agentkit login` or `CURSOR_API_KEY`), then mention the
+Sign the host in (`agent-sdk login` or `CURSOR_API_KEY`), then mention the
 agent in Slack as `@Cursor Weatherbot …`. Thread replies and DMs keep going to
 the same agent. Messages appear as the Cursor app under that agent's name
 and icon, with live updates as the turn progresses.
@@ -98,22 +99,88 @@ export default slackChannel({
 
 ## Set it up
 
-### Generate the app assets
+Start with Cursor's **Add to Slack** provisioning: Cursor creates and
+installs a dedicated Slack app for the agent and delivers its tokens,
+so nobody visits [api.slack.com](https://api.slack.com/apps) or copies
+an `xoxb-…` / `xapp-…` pair by hand. Use the CLI for local development
+and the dashboard for hosted deployments. Fall back to the
+[manual manifest flow](#manual-setup-fallback) only when provisioning
+reports the feature is not enabled for your account.
 
-One command generates the channel file, the app manifests, and the env template.
+### Provision with the CLI
+
+One command runs the whole setup:
+
+```bash
+agent-sdk slack create --dir .          # dev app (default)
+agent-sdk slack create --dir . --prod   # prod app
+```
+
+`slack create` needs a signed-in host (`agent-sdk login` or
+`CURSOR_API_KEY`). It scaffolds `agent/channels/slack.ts` when the file
+is missing, connects your Slack workspace through a browser consent
+page when it isn't connected yet (a one-time authorization per user and
+workspace), creates and installs the agent's dedicated Socket Mode app,
+writes `<PREFIX>_SLACK_BOT_TOKEN` and `<PREFIX>_SLACK_APP_TOKEN` into
+`<dir>/.env.local`, and finishes with a `doctor` pass. Then serve and
+smoke it as described [below](#wire-the-env-and-verify); the tokens are
+already in place.
+
+If the workspace requires admin approval for new apps, `create` prints
+the Slack approval page for a workspace admin. Re-run
+`agent-sdk slack create` after the approval to finish the install and
+mint the tokens.
+
+Useful companions: `--slack-team T0123ABCD` picks a workspace when
+several are connected, `--icon <https-url-or-file>` sets the app icon,
+`agent-sdk slack destroy` deletes the provisioned app, and
+`agent-sdk slack icon <source>` updates the icon later. A re-run of
+`create` refuses to overwrite manifest edits made by hand in Slack;
+pass `--force` to overwrite them.
+
+### Provision from the dashboard (hosted deployments)
+
+For a [Cursor-hosted deployment](../deployment.md#cursor-managed-hosting),
+provision from
+[cursor.com/dashboard](https://cursor.com/dashboard): open **Deployed
+Agents**, select the deployment, switch to the **Details** view, and
+expand the **Slack** row under **Integrations**.
+
+1. Click **Add to Slack** and approve the authorization in the tab that
+   opens. This is a one-time consent per user and workspace.
+2. Pick the bot name (and the workspace, when several are connected)
+   and click **Create Slack app**. Cursor creates and installs the app,
+   then stores its tokens as deployment secrets; the values are never
+   shown. The **Advanced** disclosure sets the env-var prefix, so the
+   secret names match what your `slackChannel({ envPrefix })` reads.
+3. If the workspace requires admin approval, the row shows **Waiting
+   for admin approval** with an **Approve in Slack** button that opens
+   Slack's pending-request page. After an admin approves, pick
+   **Retry** from the row's menu.
+4. Click **Redeploy** when the banner appears. The running agent keeps
+   its old environment until the next deploy.
+
+The row's menu also covers later care: rename the app, set its icon,
+rotate its tokens, remove it from Slack, or disconnect the workspace.
+
+### Manual setup (fallback)
+
+When Add to Slack is not enabled for your account, create the apps by
+hand. Generate the channel file, the app manifests, and the env
+template:
 
 ```bash
-agentkit slack init --dir . --name "My Agent"
+agent-sdk slack init --dir . --name "My Agent"
 ```
 
 This writes `agent/channels/slack.ts` (with an `envPrefix` derived from
 the directory name), importable app manifests at
-`.agentkit/slack/manifest.{dev,prod}.json`, and
-`.agentkit/slack/env.example`. Use `--no-prefix` for the shared
+`.agent-serve/slack/manifest.{dev,prod}.json`, and
+`.agent-serve/slack/env.example`. Use `--no-prefix` for the shared
 `SLACK_*` variables on single-agent hosts, `--prefix CUSTOM` to
 override, and `--channel-posts` if you plan to watch channels.
 
-### Create the apps (human, Slack admin)
+#### Create the apps (human, Slack admin)
 
 This phase needs a human with permission to create Slack apps.
 
@@ -123,7 +190,7 @@ This phase needs a human with permission to create Slack apps.
 3. Repeat with `manifest.prod.json`. Dev and prod are separate Slack
    apps with separate tokens.
 
-### Install and mint tokens (human)
+#### Install and mint tokens (human)
 
 For each app: **Install to Workspace** and copy the Bot User OAuth Token
 (`xoxb-…`), then under **Basic Information → App-Level Tokens** create a
@@ -131,7 +198,9 @@ token with scope `connections:write` and copy it (`xapp-…`).
 
 ### Wire the env and verify
 
-Export the tokens in the shell that runs `serve`, using the names from
+`agent-sdk slack create` already wrote the tokens to `.env.local`, so
+after provisioning skip straight to `doctor`. After a manual setup,
+export the tokens in the shell that runs `serve`, using the names from
 `env.example`, or put them in the agent directory's `.env.local` —
 `serve`/`dev`/`slack doctor` load that file (real environment variables
 always win over it):
@@ -142,15 +211,15 @@ export MY_AGENT_SLACK_APP_TOKEN=xapp-…
 ```
 
 ```bash
-agentkit slack doctor --prefix MY_AGENT
+agent-sdk slack doctor --prefix MY_AGENT
 ```
 
 Proceed when `app_token`, `connections_open`, `bot_token`, and
 `auth_test` are all green. Then serve and smoke it:
 
 ```bash
-agentkit serve --dir . --dev
-# expect: [agentkit/slack] Socket Mode connected
+agent-sdk serve --dir . --dev
+# expect: [agent-sdk/slack] Socket Mode connected
 ```
 
 Invite the bot to a channel and @mention it (or DM it). Expect the
@@ -262,12 +331,16 @@ Two habits matter most.
 The `slack` subcommands cover setup end to end.
 
 ```bash
-agentkit slack setup                     # guided checklist
-agentkit slack init --dir . --name "My Agent"
-agentkit slack init --dir . --no-prefix  # shared SLACK_* vars
-agentkit slack init --dir . --channel-posts
-agentkit slack manifest --env both       # regenerate manifests
-agentkit slack doctor --prefix MY_AGENT  # token / connectivity checks
+agent-sdk slack setup                     # guided checklist
+agent-sdk slack create --dir .            # provision via Add to Slack (dev app)
+agent-sdk slack create --dir . --prod     # prod app
+agent-sdk slack destroy --dir .           # delete the provisioned app
+agent-sdk slack icon ./icon.png --dir .   # set the provisioned app's icon
+agent-sdk slack init --dir . --name "My Agent"
+agent-sdk slack init --dir . --no-prefix  # shared SLACK_* vars
+agent-sdk slack init --dir . --channel-posts
+agent-sdk slack manifest --env both       # regenerate manifests
+agent-sdk slack doctor --prefix MY_AGENT  # token / connectivity checks
 ```
 
 ## What's next

package/docs/guides/webhooks.md

@@ -371,7 +371,7 @@ there. When something looks wrong, read the session's `events.ndjson`.
 The stream is the record of what happened.
 
 For GitHub specifically, don't hand-roll fixtures.
-`agentkit github replay` synthesizes real-shaped, signed payloads
+`agent-sdk github replay` synthesizes real-shaped, signed payloads
 from any PR you can read. See the [GitHub guide](./github.md).
 
 ## What's next

package/docs/hillclimbing.md

@@ -52,11 +52,11 @@ Agree on four things before you edit:
 3. **Success criteria**: what better means this round
 4. **The freeze line**: what must not change
 
-Pin the input first. A moving fixture is noise. For GitHub agents, use `agentkit github replay` (see the [GitHub guide](./guides/github.md)). For a single tool without a model turn, use `agentkit call`. For a chat turn, use `agentkit run --dir . --message "…"`.
+Pin the input first. A moving fixture is noise. For GitHub agents, use `agent-sdk github replay` (see the [GitHub guide](./guides/github.md)). For a single tool without a model turn, use `agent-sdk call`. For a chat turn, use `agent-sdk run --dir . --message "…"`.
 
 ## How do I run one hillclimb round?
 
-**Measure.** Hit the agent the way a user would: playground, channel HTTP, or Slack in `--dev`. Or ask the hillclimb skill to do it. `agentkit run` returns a JSON trajectory and writes a trace under `.agentkit/traces/`.
+**Measure.** Hit the agent the way a user would: playground, channel HTTP, or Slack in `--dev`. Or ask the hillclimb skill to do it. `agent-sdk run` returns a JSON trajectory and writes a trace under `.agent-sdk/traces/`.
 
 **Reflect.** Score the trajectory, not impressions. Was the answer right? Did the model thrash (too many tools, fat evidence, grep loops)? Did it invent work the host should have prepared? Name the single dominant problem for this round in one sentence. Example: "Full-file dumps trigger grep loops."
 
@@ -72,7 +72,7 @@ Pin the input first. A moving fixture is noise. For GitHub agents, use `agentkit
 
 ## How do I lock a hillclimb improvement with an eval?
 
-Every kept change needs an eval that would have failed before the change: a tool-choice gate, an `action.result` count bound, or an output-shape check. Run `agentkit eval --dir . --json` between rounds. Never weaken an existing gate to pass the round.
+Every kept change needs an eval that would have failed before the change: a tool-choice gate, an `action.result` count bound, or an output-shape check. Run `agent-sdk eval --dir . --json` between rounds. Never weaken an existing gate to pass the round.
 
 Details live in [Evals](./evals.md). The evals skill will author the case with you.