@cursor/july 0.1.92 → 0.1.94

package/docs/example-agents/oncall.md

@@ -1,217 +0,0 @@
----
-title: "Investigate every alert in its own Slack thread"
-description: "Watch a bot-fed alerts channel, react when the agent locks in, coalesce thread chatter behind a quiet window, and let the agent schedule its own re-checks."
----
-
-# Investigate every alert in its own Slack thread
-
-This agent is an on-call teammate. Alert feeds post into an alerts channel
-as bots. Each new alert dispatches an investigation session pinned to that
-post's thread: the agent reacts 👀 the moment it locks in, investigates
-immediately, and posts brief findings backed by evidence it observed.
-Replies in the thread reach it only after the thread has been quiet for
-about a minute, and reminder tools let it wake itself later to re-check a
-baseline or confirm an alert cleared.
-
-Use this example when alerts land in Slack and you want one thread-scoped
-investigation per alert, with an agent that paces its own engagement
-instead of answering every message.
-
-[Browse the current alert-investigator source.](../../examples/oncall/)
-
-## Follow an alert
-
-1. An alert feed (Alertmanager, PagerDuty, Datadog) posts a new top-level
-   message in the watched alerts channel.
-2. The channel watch accepts it. `includeBotPosts` lets bot authors
-   through; the agent's own posts always stay dropped.
-3. The handler reacts 👀 on the alert post and sets "Investigating…"
-   typing. The reaction is the lock-in signal: this alert has an owner.
-4. The Agent SDK creates a session keyed to the alert's thread and dispatches
-   immediately. New alerts get no debounce.
-5. The agent reads the alert, gathers evidence, and posts findings to the
-   thread once it has a hypothesis.
-6. People discuss in the thread. Replies buffer per thread and dispatch as
-   one coalesced follow-up after roughly a minute of quiet.
-7. The agent arms reminders for anything that needs time and posts interim
-   updates when new evidence changes the picture.
-
-Mentions and DMs skip the watch entirely and behave like ordinary chat.
-
-## Map the files
-
-| File | Purpose |
-| --- | --- |
-| [`agent/agent.ts`](../../examples/oncall/agent/agent.ts) | Names the agent and keeps harness workspaces outside any monorepo checkout. |
-| [`agent/instructions.md`](../../examples/oncall/agent/instructions.md) | Engagement rules, the investigation loop, and the message discipline. |
-| [`agent/channels/slack-app.ts`](../../examples/oncall/agent/channels/slack-app.ts) | Dedicated Socket Mode app: watch configuration and handler wiring. |
-| [`agent/lib/alert-watch.ts`](../../examples/oncall/agent/lib/alert-watch.ts) | The engagement policy: lock in on new alerts, coalesce replies. |
-| [`agent/lib/thread-debounce.ts`](../../examples/oncall/agent/lib/thread-debounce.ts) | Per-thread quiet window. |
-| [`agent/lib/alerts.ts`](../../examples/oncall/agent/lib/alerts.ts) | Dispatch classification, prompt building, and thread addressing. |
-| [`agent/lib/slack-api.ts`](../../examples/oncall/agent/lib/slack-api.ts) | Reactions and thread posts on this agent's own token pair. |
-| [`agent/tools/reminders_create.ts`](../../examples/oncall/agent/tools/reminders_create.ts) | Self-scheduled wakes bound to the thread (plus `reminders_list` and `reminders_cancel`). |
-| [`agent/tools/post_thread_update.ts`](../../examples/oncall/agent/tools/post_thread_update.ts) | Interim updates to the thread mid-turn. |
-| [`agent/storage.ts`](../../examples/oncall/agent/storage.ts) | Persists sessions and events with `cursorHostedStorage`. |
-| [`evals/evals.config.ts`](../../examples/oncall/evals/evals.config.ts) | Caps eval run concurrency. |
-| [`evals/smoke.eval.ts`](../../examples/oncall/evals/smoke.eval.ts) | Checks identity and the reminder-tool route. |
-
-## Let bot posts through the watch
-
-Channel watching drops bot-authored posts by default so two agents can
-never feed each other. Alert channels invert the assumption: the posts
-worth watching come from bots. `channelPosts.includeBotPosts` opts in per
-channel:
-
-```ts
-engagement: {
-  channelPosts: {
-    allow: ["#alerts"],
-    posts: "all",
-    includeBotPosts: true,
-  },
-},
-```
-
-Loop safety survives the opt-in. The pack matches the watching app's own
-posts by the `bot_id` and bot user id from `auth.test` and drops them, so
-the agent's findings never re-dispatch it. Posts that mention the bot stay
-on the mention path.
-
-`posts: "all"` also delivers thread replies. The handler, not the pack,
-decides their pace.
-
-## Pace the engagement
-
-The example runs two rhythms:
-
-- A new alert dispatches immediately.
-- Thread replies produce one engagement per lull.
-
-The pack's `debounceMs` is per message; it exists to let edits settle. This
-agent needs a per-thread window instead, so the handler owns it
-([`lib/thread-debounce.ts`](../../examples/oncall/agent/lib/thread-debounce.ts)).
-Every reply restarts a 60-second timer keyed by thread. Superseded waiters
-resolve `null` and the handler returns `null` for them. When the thread
-goes quiet, the newest waiter receives the whole batch and dispatches one
-follow-up that lists every message with mentionable attribution.
-
-Two details make the window matter. A follow-up that arrives while a turn
-runs preempts that turn (latest message wins), so engaging per message
-would keep cancelling the investigation. And @mentions bypass the window
-through Slack's mention path, so a person who needs the agent now still
-gets it now.
-
-## Schedule your own re-checks
-
-Investigations rarely finish in one pass. A baseline comparison needs 20
-minutes of data. An alert that cleared may re-fire. The example hands the
-model three tools over `host.reminders`:
-
-- `reminders_create` arms a one-shot (`delay: "20m"`) or recurring
-  (`every: "30m"` with a plain-language stop condition) wake bound to the
-  thread's conversation.
-- `reminders_list` shows the thread's standing watches.
-- `reminders_cancel` disarms one, and refuses ids that belong to another
-  thread's conversation.
-
-When a reminder fires, its prompt returns to the same session as a
-follow-up turn, and the reply lands in the alert thread. The instructions
-keep wake prompts generic (re-read live state instead of replaying stale
-numbers) and wake replies to one line, for example "re-checked p99 on
-api-gateway: 120ms, back at baseline, cancelling the watch."
-
-Keep these tool filenames if you copy the design: the framework's reminder
-fire prompt tells the model to call `reminders_cancel` by name when a stop
-condition is set.
-
-## Alert people mid-investigation
-
-The final reply of each turn posts to the thread on its own.
-`post_thread_update` covers evidence that shouldn't wait for the turn to
-finish: it posts a one-or-two-sentence update through the agent's token,
-with `<@USERID>` mentions for the people who need to act. The instructions
-restrict it to changes in hypothesis, severity, or blast radius. Progress
-narration doesn't qualify.
-
-## Connect the Slack app
-
-Channel watching is Socket Mode only, so this example uses a dedicated
-app:
-
-```bash
-agent-sdk slack create --dir examples/oncall --name "Oncall" --channel-posts
-agent-sdk slack doctor --prefix ONCALL
-```
-
-`--channel-posts` prefills channel-watch events (`message.channels` /
-`message.groups`). Invite the bot to each watched channel after the
-wizard finishes.
-
-`ONCALL_ALERTS_CHANNELS` sets the watch list as comma-separated ids or
-`#names`. It defaults to `#alerts`.
-
-Wire observability MCP servers under `agent/mcp-connections/` so evidence
-gathering reaches your logs, metrics, and dashboards. The example ships
-none; without them the agent works from the alert text, its links, and the
-thread.
-
-## Validate and start the server
-
-```bash
-agent-sdk validate --dir examples/oncall
-agent-sdk info --dir examples/oncall --json
-agent-sdk dev examples/oncall
-```
-
-The info output lists four server tools and the watched channel on the
-`slack-app` channel. Missing tokens leave that channel idle without
-stopping the server.
-
-In dev mode, reminder timers don't auto-fire. List and fire them by hand
-through the dev routes described in
-[Schedules and reminders](../reference/schedules.md#dispatch-and-dev-mode).
-
-## Test the policy without Slack
-
-The engagement policy is plain code with unit tests:
-
-```bash
-pnpm exec vitest run examples/oncall
-```
-
-The integration test drives a synthetic Events API delivery through the
-real parse, watch, and dispatch plumbing. It asserts a bot alert
-dispatches pinned to its thread after the lock-in reaction, the agent's
-own posts never loop, and replies coalesce behind the quiet window.
-
-The smoke eval spends a model turn:
-
-```bash
-agent-sdk eval --dir examples/oncall smoke --json
-```
-
-It checks identity and the reminder-tool route lexically. It doesn't prove
-Slack delivery or reaction behavior; the unit tests cover the dispatch
-side, and a live check needs the dedicated app connected.
-
-## Build an alert investigator
-
-Use this structure when a bot feed should drive thread-scoped work:
-
-1. Watch the feed channel with `includeBotPosts: true` and a narrow
-   allowlist.
-2. Acknowledge on the triggering post before dispatching, so people see
-   ownership without opening the thread.
-3. Dispatch new items immediately; coalesce thread chatter behind a
-   per-thread quiet window.
-4. Give the agent reminder tools for anything that needs time, and make
-   cancel discipline part of the instructions.
-5. Keep every posted message brief and tied to evidence the agent saw.
-
-## Where to go next
-
-- [Slack](../guides/slack.md)
-- [Schedules and reminders](../reference/schedules.md)
-- [Tools](../reference/tools.md)
-- [Playbook router](./benny.md) for the human-post variant of channel
-  watching

package/docs/example-agents/security-reviewer.md

@@ -1,270 +0,0 @@
----
-title: "Run staged security reviews from GitHub events"
-description: "Orchestrate parallel reviewer agents, streamed triage, deterministic stages, live playground progress, durable sessions, and severity A/B metrics."
----
-
-# Run staged security reviews from GitHub events
-
-Security Reviewer turns a pull request into a staged host-side review. One
-tool prepares the diff and selects modules. A second fans out specialized
-reviewers and triages candidates as they arrive. A third deduplicates the
-confirmed findings, writes artifacts, and may publish a GitHub review.
-
-Use this example when the workflow needs several model workers, but the host
-must own orchestration, progress, artifacts, and the final write.
-
-Source lives under [`factory/security-reviewer/`](../../../../factory/security-reviewer/) (factory agent, not under `examples/`).
-
-Want one model turn and one comment? Scaffold the
-[security-reviewer template](../templates/security-reviewer.md).
-
-[Browse the Security Reviewer source.](../../../../factory/security-reviewer/)
-
-## Run a three-stage host pipeline
-
-Security Reviewer is a pipeline, not one long agent turn:
-
-| Stage | Tool | Result |
-| --- | --- | --- |
-| Prepare | `prepare_review` | Fetch metadata and diff, create a `runId`, and select security modules. |
-| Review and triage | `run_reviewers` | Run module reviewers in parallel and start triage as each candidate arrives. |
-| Finalize | `finalize_review` | Apply thresholds, deduplicate findings, write artifacts, and optionally post a review. |
-
-`run_triage` remains available as a compatibility stage. In the normal flow,
-triage has already completed inside `run_reviewers`, so it reports existing
-results. If candidates exist without triage output, it starts triage workers
-and writes their state.
-
-The configured root agent chooses and sequences tools in chat. The review
-workers use a model selected by the host pipeline. They are
-created programmatically with the agent SDK, not discovered from
-`agent/subagents/`.
-
-## Follow a GitHub review
-
-1. A pull request event starts a review and opens a playground session.
-2. The playground shows reviewer and triage progress.
-3. Confirmed findings appear in the PR review.
-4. A GitHub Check reports completion or a processing failure.
-
-## Map the framework features
-
-| Capability | Source | Role |
-| --- | --- | --- |
-| Root agent | [`agent/agent.ts`](../../../../factory/security-reviewer/agent/agent.ts), [`agent/instructions.md`](../../../../factory/security-reviewer/agent/instructions.md) | Configure local chat and explain the three-stage contract. |
-| Server tools | [`agent/tools/`](../../../../factory/security-reviewer/agent/tools/) | Expose each review stage to chat and host orchestration. |
-| GitHub channel | [`agent/channels/github.ts`](../../../../factory/security-reviewer/agent/channels/github.ts) | Filter wakes, run background tasks, and publish status. |
-| Progress channel | [`agent/channels/asr-progress.ts`](../../../../factory/security-reviewer/agent/channels/asr-progress.ts) | Serve live reviewer and triage state by `runId`. |
-| Playground renderer | [`agent/playground/tools/run_reviewers.tsx`](../../../../factory/security-reviewer/agent/playground/tools/run_reviewers.tsx) | Replace the generic tool chip with live module rows. |
-| SDK review pipeline | [`review-stages.ts`](../../../../factory/security-reviewer/agent/lib/review-stages.ts), [`@anysphere/security-review-lib`](../../../../packages/security-review-lib/src/index.ts) | Select modules, call model workers, triage, deduplicate, and write artifacts. |
-| Storage | [`agent/storage.ts`](../../../../factory/security-reviewer/agent/storage.ts) | Persist framework sessions with `cursorHostedStorage` (lazy restore). |
-| A/B | [`agent/ab.ts`](../../../../factory/security-reviewer/agent/ab.ts) | Compare all-severity versus high-only GitHub comments. |
-| Eval | [`evals/`](../../../../factory/security-reviewer/evals/) | Check stage-tool presence against a pinned sample. |
-
-There is no Slack channel, authored skill, discovered subagent, MCP
-connection, schedule, reminder, hook, tool approval, or cloud runtime.
-
-## Prepare the host
-
-You need:
-
-- Node 22.13 or newer.
-- An agent-runtime credential for the root turn and review workers.
-- GitHub read access for preparation.
-- GitHub write access for webhook-driven reviews and Checks.
-
-The pipeline exposes settings for:
-
-- the worker model,
-- reviewer and triage parallelism,
-- reviewer, triage, duplicate-gate, and final-dedupe timeouts, and
-- prior-comment loading.
-
-The active names live beside the orchestration in
-[`review-stages.ts`](../../../../factory/security-reviewer/agent/lib/review-stages.ts).
-
-## Validate the discovered agent
-
-```bash
-agent-sdk validate --dir ../../factory/security-reviewer
-agent-sdk info --dir ../../factory/security-reviewer --json
-agent-sdk eval --dir ../../factory/security-reviewer --list
-```
-
-`validate` should pass. `info` and `eval --list` should match the capabilities
-mapped above.
-
-## Know the chat path's write boundary
-
-In chat, the root instructions ask the model to use this order:
-
-```text
-prepare_review -> run_reviewers -> finalize_review
-```
-
-They also ask the model to set `postComment: true` only on request. This is
-prompt policy, not a deterministic safety gate. The model chooses tool
-arguments, and `finalize_review` has no human approval. Use the direct stage
-calls below when a no-post proof must be enforced.
-
-## Call stages directly without publishing
-
-Call each stage and pass `postComment: false` yourself:
-
-```bash
-agent-sdk call prepare_review \
-  --dir ../../factory/security-reviewer \
-  --input '{"prUrl":"https://github.com/owner/repo/pull/123"}'
-
-agent-sdk call run_reviewers \
-  --dir ../../factory/security-reviewer \
-  --input '{"runId":"<run-id>"}'
-
-agent-sdk call finalize_review \
-  --dir ../../factory/security-reviewer \
-  --input '{"runId":"<run-id>","postComment":false}'
-```
-
-Review state lives under the project's run-artifact directory, so later
-stages can open the prepared `runId`.
-
-> [!CAUTION]
-> `finalize_review` with `postComment: true` writes to GitHub. The webhook
-> path always requests that write. Chat instructions alone don't prevent it.
-
-## Watch parallel work in the playground
-
-Run the dev server:
-
-```bash
-agent-sdk dev ../../factory/security-reviewer
-```
-
-Open the printed playground and start a review. The custom
-`run_reviewers` renderer polls the progress channel's `GET /:runId` route.
-
-It refreshes every 500 ms while the stage runs. Each row shows a reviewer
-module's state, candidates, reviewed areas, and failure. A second section
-shows triage jobs and confirmed or rejected counts.
-
-This is an authored playground extension. The Agent SDK discovers it by the tool
-name, so the generic `run_reviewers` chip becomes a domain-specific view
-without changing the framework playground.
-
-## Fan out reviewers while triage starts
-
-Module selection uses repository and path rules. The current module set
-covers:
-
-- agent tooling trust boundaries,
-- privileged service RPCs,
-- product-specific security risks,
-- dependency and supply-chain changes,
-- deployment and infrastructure code,
-- filesystem and workspace boundaries,
-- privacy, and
-- general security review.
-
-Selected modules may run more than once. Candidates pass through a duplicate
-gate, then bounded triage. Reviewer or triage failures can produce partial
-results. A final dedupe failure stops finalization.
-
-The pipeline writes JSONL journals as work completes. Final artifacts include
-the review bundle, patch, reviewer outputs, candidates, triage decisions,
-findings, accounting, and audit events.
-
-## Separate session storage from review artifacts
-
-`defineStorage` + `cursorHostedStorage` sends Agent SDK session and event records
-to Cursor-hosted Bugbot storage through the control-plane proxy. Security
-Reviewer sets `restore: "off"` so startup doesn't load old review sessions in
-bulk. A continuation lookup can still fetch a needed session.
-
-The staged review files are separate from session storage. Session-store
-durability doesn't preserve those files. All stages for one `runId` must see
-the same filesystem.
-
-This split is useful when conversation history needs shared durability but
-large review artifacts belong on attached storage or an object store.
-
-## Compare live comment variants
-
-The comment-severity experiment uses sticky session assignment with a 5%
-holdout:
-
-- `control` posts every finding.
-- `treatment` posts only high and critical findings.
-
-Finalization enforces the comment filter. The treatment also adds an
-instruction overlay asking chat and playground summaries to lead with high
-and critical findings. Full artifacts, `finalResponse`, and finding counts
-still include every finding. Stage-tool counters appear in the
-playground A/B view. Local sample and snapshot files persist under
-`.agent-serve/`.
-
-When a treatment session has only low or medium findings, the filtered review
-body currently says no vulnerabilities were found even though artifacts and
-status retain findings. Account for that mismatch before using this
-experiment as a publishing policy.
-
-Eval sessions skip A/B enrollment.
-
-## Test the GitHub channel carefully
-
-The channel uses the host's Cursor account repository scope. It wakes on
-`opened` and `synchronize`, skips drafts, and posts its own GitHub Check.
-
-Inspect its event surface:
-
-```bash
-agent-sdk github events \
-  --dir ../../factory/security-reviewer \
-  --json
-```
-
-Replay reaches the full publishing path:
-
-```bash
-TEST_PR_URL=https://github.com/your-org/allowlisted-test-repo/pull/123
-agent-sdk github replay \
-  "$TEST_PR_URL" \
-  --dir ../../factory/security-reviewer \
-  --action opened
-```
-
-Set `TEST_PR_URL` to a PR in the channel's configured repository allowlist.
-Run the command only against a PR intended for test reviews. It posts a
-GitHub Check and may post findings.
-
-## Inspect the eval before running it
-
-```bash
-agent-sdk eval --dir ../../factory/security-reviewer --list
-```
-
-The case gates the review flow and prevents comment posting. It still fetches
-the live PR, so it needs GitHub access.
-
-## Build another staged pipeline
-
-Use staged host orchestration when:
-
-- each phase needs its own timeout and artifact,
-- model workers should run in bounded parallel,
-- later work can start as soon as partial results arrive,
-- a webhook must acknowledge before the work finishes, or
-- operators need live progress beyond one tool spinner.
-
-Keep external writes in finalization. Pass a `runId` between stages, journal
-progress before publishing, and make partial-worker failures visible in the
-result.
-
-## Where to go next
-
-- [GitHub](../guides/github.md)
-- [Tools](../reference/tools.md)
-- [Channels](../reference/channels.md)
-- [Playground](../reference/playground.md)
-- [Storage](../storage.md)
-- [Live A/B metrics](../ab.md)
-- [Evals](../evals.md)

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

@@ -1,147 +0,0 @@
----
-title: "Put a minimal agent in Slack"
-description: "Use account-linked Slack routing, thread continuity, identity, and suggested prompts with one small channel."
----
-
-# Put a minimal agent in Slack
-
-Slack agent is the smallest channel example. It has one runtime config, one
-instruction file, and one authored channel. A teammate mentions the agent,
-the local runtime harness runs a turn, and the answer
-returns to the same Slack thread.
-
-Use it to learn the minimum needed for a Slack agent before adding tools,
-workflows, or a dedicated app.
-
-[Browse the Slack agent source.](../../examples/slack-agent/)
-
-## Keep the Slack channel small
-
-Slack agent delegates transport details to the host connection. The authored
-file selects the account-linked transport, gives the agent a single-token
-router name and icon, and supplies suggested prompts.
-
-The complete channel lives in
-[`agent/channels/slack.ts`](../../examples/slack-agent/agent/channels/slack.ts).
-The framework supplies message intake, thread-scoped sessions, delivery,
-status updates, and suggested prompts.
-
-## Follow a Slack message
-
-1. A user mentions the agent or sends the host app a direct message naming
-   it.
-2. The Slack relay selects this channel by its single-token `agentName`.
-3. The Agent SDK maps the Slack channel and thread timestamp to a continuation
-   key.
-4. The local harness runs with
-   [`instructions.md`](../../examples/slack-agent/agent/instructions.md).
-5. The response returns to the triggering thread.
-6. A later message in the same thread resumes the durable session.
-
-The prompt asks for concise threaded replies. It doesn't define domain policy
-or tool routing.
-
-## Map the Slack agent files
-
-| File | Purpose |
-| --- | --- |
-| [`package.json`](../../examples/slack-agent/package.json) | Declares the example package and Agent SDK dependency. |
-| [`agent/agent.ts`](../../examples/slack-agent/agent/agent.ts) | Names the agent and selects the model. The omitted `runtime` defaults to local. |
-| [`agent/instructions.md`](../../examples/slack-agent/agent/instructions.md) | Sets the always-on response style. |
-| [`agent/channels/slack.ts`](../../examples/slack-agent/agent/channels/slack.ts) | Connects the signed-in host account to Slack. |
-| [`agent/storage.ts`](../../examples/slack-agent/agent/storage.ts) | Persists sessions and events with `cursorHostedStorage`. |
-
-There are no authored tools, skills, MCP connections, subagents, schedules,
-hooks, A/B experiments, or evals. This small surface is the lesson.
-
-## Connect the host
-
-You need:
-
-- Node 22.13 or newer.
-- An agent-runtime credential.
-- Slack connected through the selected channel transport.
-
-Sign in and confirm the active account:
-
-```bash
-agent-sdk login
-agent-sdk whoami
-```
-
-The selected transport owns Slack credential setup. See the
-[Slack guide](../guides/slack.md) for account-linked and dedicated-app
-options.
-
-## Validate and start the server
-
-```bash
-agent-sdk validate --dir examples/slack-agent
-agent-sdk info --dir examples/slack-agent --json
-agent-sdk dev examples/slack-agent
-```
-
-The dev command prints the playground URL. It also mounts the Slack channel
-and waits for relayed messages.
-
-In Slack, address the configured host app and router name, then send:
-
-> `<host-app mention> <router name>` Explain the Agent SDK in three bullets.
-
-Reply in the generated thread:
-
-> Make the second bullet simpler.
-
-The second message reaches the same session. You can open that session in the
-playground to inspect the received message, model events, final reply, and
-usage.
-
-## Test without Slack
-
-Every project gets the built-in HTTP channel even when no HTTP file exists.
-Run a one-shot turn through it:
-
-```bash
-agent-sdk run --dir examples/slack-agent \
-  --message "Explain the Agent SDK simply."
-```
-
-The same project also exposes an MCP endpoint. Since this agent has no server
-tools, its MCP surface contains `ask` and `check`, but not `call_tool`.
-
-These automatic surfaces let you test the prompt from the CLI and let another
-agent delegate to it later. The authored Slack channel only changes how work
-arrives and where replies go.
-
-## Know when to add a dedicated app
-
-An account-linked Slack transport is a fit for mentions, direct messages, thread
-continuity, and agent-branded replies. Move to a dedicated Socket Mode channel
-when you need:
-
-- top-level channel watching,
-- interactive approval buttons,
-- a separate bot identity, or
-- Slack app events unsupported by the account-linked relay.
-
-Compare this example with [Playbook router](./benny.md), which adds allowlisted channel
-watching, and [Weather agent](./weather-agent.md), which adds approval buttons
-through a second Slack channel.
-
-## Turn the channel into your own Slack agent
-
-Copy the three authored files, then change:
-
-- `name` in `agent.ts` for the harness identity,
-- `agentName` in `slack.ts` for the single-token router name,
-- the instructions for your domain, and
-- suggested prompts for the tasks teammates should try.
-
-Keep `agentName` free of whitespace. Use PascalCase for multiword names.
-
-## Where to go next
-
-- [Slack](../guides/slack.md)
-- [Channels](../reference/channels.md)
-- [Sessions and streaming](../reference/sessions.md)
-- [Playground](../reference/playground.md)