Three pages told readers Node 18 was enough. Node 18 reached end of life
on 2025-04-30, and #7108 raised every published package to
`engines.node: ">=20"`, so the guidance was wrong on both counts.
The AWS Lambda page keeps the AWS fact that response streaming works from
Node 18, but now states the floor `@copilotkit/runtime` actually needs.
Its own examples already deploy `nodejs22.x`.
Every other Node claim across shell-docs already said 20 or later.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
## Problem
The discontinued AG-UI protocol mirror remained published on
docs.copilotkit.ai. Its sitemap advertised pages owned by the separate
AG-UI repository, including eight routes that returned 500.
## Why
The protocol documentation is maintained at docs.ag-ui.com. Keeping an
unsynchronized duplicate on the CopilotKit host created broken
user-facing URLs and misleading search results.
## Fix
Remove the vendored `/ag-ui/*` content, renderer, sitemap/search/LLM
enumeration, and mirror-specific tests. Retain CopilotKit's own AG-UI
integration documentation under `/backend/ag-ui` and
`/agentic-protocols/ag-ui`.
Validation: `npm run typecheck`; focused Vitest suite (39 tests).
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* AG-UI protocol documentation has been removed from the documentation
site.
* AG-UI documentation updates are now directed to the upstream protocol
project.
* Related guides, SDK references, drafts, roadmap, integrations, and
contribution pages are no longer available here.
* **Search & Navigation**
* AG-UI pages no longer appear in search indexes, sitemap listings, or
LLM-generated documentation content.
* Documentation routing now resolves supported content areas without the
former AG-UI route.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
The Mastra doc test declared @ag-ui/mastra without a version while pinning the
AG-UI client and core packages at 0.0.57. Version 1.1.3 of the adapter raised
its peer requirement to 0.0.58, so a fresh install started resolving to it and
failing on ERESOLVE.
Bumping the two pinned packages instead clears that conflict but introduces a
worse one: the runtime pinned alongside them still carries 0.0.57, so two
copies of AbstractAgent end up in the tree and the doc's own type check fails
on the mismatch. Pinning the adapter at the last release whose peer accepts
0.0.57 keeps one copy of each package. Verified locally: 22 passed, 0 failed.
The failure banner lived inside the element the interrupt hook renders, and the
hook caches that element, so a picker already on screen never saw an updated
prop. One rejected resume left the flag set, and the next booking showed a
failure the moment a slot was selected, before its own resume had started.
The banner now lives outside the hook-owned element and the flag clears as the
first step of a new selection, so the card only ever reports its own outcome.
That makes the prop the card took for this purpose unreachable, so the prop and
the branch it fed are gone rather than left as dead state.
The cancel specs read the resumed run's final text as soon as a new assistant
bubble appeared. A bubble shows up when streaming starts, and the guard is a
negative assertion, so a response streaming "B" before "Booked: ..." would pass
while it was still one character long. Each cancel test now waits for the run
to finish first. Confirmed the wait is doing work rather than passing on
arrival: probing the same control right after the bubble appears finds it
enabled, so the assertion that follows genuinely blocks until the run ends.
Verified live against a real model on both columns, 8 of 8 each.
The prompt a developer copies from the Inspector, the docs hero and the feature
cards opened with two sentences of instruction to the coding agent: identify
yourself with a slug, and pass it as a flag. It is the one piece of text a human
reads, decides on and pastes, and most of it was addressed to something else.
Help me get started with CopilotKit. Run this command and follow the
instructions:
npx --yes copilotkit@latest onboard start --run <run-id>
Identification moves into the prompt graph, which is the surface that talks to
the agent for the rest of the run: `onboard identify --coding-agent <slug>` is
run by `authenticate/start` (Intelligence OSS-1157). The CLI still accepts
`--coding-agent` on `start`, so this wording and the old wording both work and
neither repository has to land first.
The feature prompts keep their standing permission for the CLI session check.
That sentence is the developer granting something by copying the text, and the
graph cannot grant it to itself, so only the identification half is cut.
Kept byte-identical across the Inspector template, the docs constant, and
Intelligence's own `createCodingAgentOnboardingPrompt`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The parity notes described the interrupt reason channel and the resume envelope
as live differences between the two bridges. Both are closed as of the released
versions this branch pins: the TypeScript bridge now carries the reason under
the interrupt's metadata and wraps a resolved answer the same way Python does.
Checked against the released packages rather than their changelogs.
The reading code still accepts the older shapes so the demos keep working
against an earlier bridge, which is why the note now explains the normalisation
as backwards compatibility rather than as a divergence to work around.
Takes ag_ui_strands 0.4.0 and @ag-ui/aws-strands 0.3.0, the releases of the
alphas this branch was already tracking. Their companion requirements are the
ones already pinned here: the Python bridge needs ag-ui-protocol 0.1.22 and the
TypeScript one needs the AG-UI core packages at 0.0.59.
Verified against a live model on both columns with the released versions in the
containers: python 138 passed, typescript 141 passed. The multimodal round trip
that the TypeScript bridge used to break is fixed at both levels, returning the
user message with its parts intact for inline data, url and pdf sources, and
rendering the image and the document chip in the demo.
The remaining failures are the same 46 on both columns. They are specs that
assert the wording aimock's fixtures author, so they cannot pass against a real
model: one expects a humidity reading of 55% where the model answered 77%,
another expects a greeting quoted verbatim from the fixture. An identical
failure set across two independently written bridges is the evidence that the
cause is the specs rather than either bridge.
Hide the running footer when the activity is completed, failed,
cancelled, or paused. Keep the activity renderer array stable
across page renders.
Verified the only renderer registration and existing status mapping;
no public API changes. Browser regression checks failed before the
changes and passed afterward with the real CopilotKit/Mastra runtime
and a deterministic model.
Both alphas need a companion bump the showcase owns, and neither container
starts without it: the Python bridge requires ag-ui-protocol 0.1.22, and the
TypeScript canary requires the AG-UI core packages at 0.0.59.
The Python agent picked its model from a hardcoded literal while the TypeScript
one already read MODEL_ID, so the Python column could not be pointed at another
model without a rebuild. It now reads the same variable, resolved at call time
because the server imports the module before it loads the environment file.
The interrupt pick-path specs asserted the fixture's exact wording, which made
them aimock-only, so a live run could never exercise them. Rewriting them to
count assistant bubbles turned out to be worse than the problem: a resume that
loses the user's answer still narrates "user did not pick a time", so the count
passed on a deliberately broken resume. Verified by breaking the tool's resume
read, rebuilding, and watching the suite stay green.
They now assert the slot the user actually picked and the absence of the
did-not-pick branch. That pins the data rather than the phrasing, so a live
model saying "Monday at 9:00 AM" passes while a lost answer fails. Confirmed
both ways against a real model: 8 of 8 pass on the real code, and the two
pick-path specs fail on the broken one. The cancel paths keep the regression
guard that matters, the absence of a booking confirmation, and drop the
fixture-worded positive that a live model has no reason to reproduce.
## Problem
The documentation does not clearly establish the Google ADK agent-side
path for `useAgentContext`. The hook reference points generically to
integration guides, while the existing ADK setup uses
`state["copilotkit"]["context"]`, which is not where the adapter stores
the AG-UI request context.
## Why
Reproduced using the actual adapter and ADK Runner with an instruction
provider and a deterministic local model. Given
`RunAgentInput.context=[{description: "Incident records", value:
"[{\"id\":\"INC-1041\"}]"}]` and empty request state:
```text
state["copilotkit"]["context"]: []
state[CONTEXT_STATE_KEY] (_ag_ui_context):
[{"description": "Incident records", "value": "[{\"id\":\"INC-1041\"}]"}]
```
## Fix
Document the public `CONTEXT_STATE_KEY` export in the hook reference and
link directly to the ADK context guide. Replace that guide's setup with
a standalone instruction-provider example using the correct state key.
Preserve the Gemini final-text termination safeguard with a fully
defined callback in the same example. Explain the string values, parsing
structured values, callback/tool access, and the distinction between
exposing frontend tools and including context in model instructions.
Validation: regenerated the setup-content bundle through Nx, extracted
and executed its Python example, and drove the documented instruction
provider through the real adapter/Runner. It delivered `INC-1041` into
the model request's system instruction and completed with text events
and `RUN_FINISHED`. This is a deterministic integration reproduction,
not a live Gemini/browser test. `git diff --check` passes.
Targeted shell-docs checks: **26 passed across 3 files**
(`setup-content`, `setup-concept`, and `frontend-tools-setup-coverage`),
run through Nx after generating the normal docs prerequisites.
The context example also passes nine copied-code callback checks
(registration, final text, partial/thinking output, tool calls, and
private-context compatibility). The bundled context-to-model execution
check and 26 targeted docs tests pass after this correction.
## Problem
A Next.js app in `web/` cannot read an Intelligence key stored in a
shared repository-root `.env` without explicit environment loading. The
runtime connection guide reads `process.env.CPK_INTELLIGENCE_API_KEY`
without explaining this layout.
## Why
Next.js loads app-local env files. A sibling agent's root env-file
configuration does not load that file for the Next.js process.
TypeScript's non-null assertion does not supply the key.
## Fix
Document an explicit `node --env-file=../.env` Next.js startup command,
the app-local alternative, and hosted server environment settings. One
docs file; no runtime path guessing or secret handling change.
Validation with a synthetic key and Next.js's actual `@next/env` loader:
loading the nested app directory leaves the root key undefined. Starting
the same check with `node --env-file=../.env` exposes the key to that
loader. MDX compilation and git whitespace checks pass. Full docs build
and hosted Intelligence connection were not run; no real credentials
were used.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added guidance for configuring environment variables in Next.js
applications located in subdirectories.
* Documented how to explicitly load shared root `.env` files, including
a Node.js 20.6+ command example.
* Clarified app-local and hosted deployment environment configuration.
* Explained that the environment key must be loaded before initializing
the intelligence integration.
* Noted that TypeScript’s non-null assertion does not load or validate
environment variables.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
The Google ADK frontend-tool setup, embedded in
`/google-adk/generative-ui/tool-based`, imports `get_model` and
`stop_on_terminal_text` from an undefined `agents.shared_chat` module.
This prevents copying the example into a new project.
## Why
The setup snippet was extracted from a showcase agent and carried its
repository-local helper dependency. Installing `ag-ui-adk` does not
provide that module or export `stop_on_terminal_text`.
Reproduction: executing the extracted setup with installed ADK
dependencies in an empty project raises `ModuleNotFoundError: No module
named 'agents'`; `hasattr(ag_ui_adk, 'stop_on_terminal_text')` is false.
## Fix
Make the two shared setup snippets standalone: use public `LlmAgent` and
`AGUIToolset` imports and an explicit model name. Define and register
the termination callback inline, preserving its final-text, streaming,
pending-tool, and private-context guards without undefined helper
imports. Showcase runtime agents are unchanged.
Validation: regenerated the production setup-content bundle through Nx,
then extracted and executed both bundled Python examples in an isolated
Python environment. Both construct an agent with `AGUIToolset`
successfully. `git diff --check` passes. The two authored setup inputs
and a Python regression test change; generated data is not committed.
The copied examples and canonical callback pass 26 Python checks,
covering callback registration, final text, partial/thinking output,
pending tool calls, and missing private ADK context.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Rewrote Google ADK integration setup instructions with clearer
examples for enabling CopilotKit frontend tools and generative UI
components.
- Updated agent configuration guidance to use `AGUIToolset()` in the
agent’s tools list.
- Replaced referenced demo components with inline Python examples.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
A completed tool card can still show placeholder details when its
renderer reads output fields from the tool inputs.
## Why
`useRenderTool` keeps `parameters` (inputs) separate from `result` (the
completed output string). Completion does not replace inputs with
output, and declaring a field in the parameters schema does not populate
it from the result. The guide showed a working example but did not
explain this distinction.
## Fix
Add one explanation beside the existing per-tool example, including the
exact completed-placeholder symptom and how to read JSON output. No API
or runtime changes.
Reproduction against the real `useRenderTool` registration and
`useRenderToolCall` resolver (only surrounding context mocked), using
identical input and result messages:
```html
<article>
<p data-testid="before">complete: Placeholder detail</p>
<p data-testid="after">complete: Sunny, 22 C</p>
</article>
```
The first card reads an absent input field; the second parses `result`.
A temporary Nx reproduction target ran the existing resolver tests plus
this case: **9 tests passed**. The temporary harness is not shipped in
this docs-only PR. MDX parsing and `git diff --check` passed. Full docs
build not run.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Clarified how tool inputs and completed outputs are represented when
using tool rendering.
- Added guidance for parsing JSON results and distinguishing input
parameters from output data.
- Documented how to diagnose placeholder data that appears after tool
execution completes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
The LangGraph TypeScript app-context example reads
`state.copilotKit.context`, but the SDK schema and CopilotKit runtime
adapter supply lowercase `copilotkit`.
## Why
The TypeScript spelling differs from the actual state field. Following
the example throws before it can consume frontend context.
## Fix
Correct the expression and explain the lowercase state key. One docs
file; no runtime behavior change.
Validation: sent a synthetic colleague through the real CopilotKit
LangGraph adapter's state merge and a compiled LangGraph node using the
expression extracted from this page. Before: `TypeError: Cannot read
properties of undefined (reading 'context')`. After: the node reads
colleague `Ada`. MDX syntax compilation passes after stripping snippet
imports, as the docs loader does. Git whitespace and commit hooks pass.
No hosted browser/model call was needed for this deterministic
reproduction; full docs build was not run.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Clarified that the CopilotKit state key is lowercase `copilotkit` in
Python and TypeScript integrations.
- Updated the TypeScript example to access context using the correct
lowercase state key.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
An onboarding run using CLI 4.9.1 installed unversioned Zod alongside
`@copilotkit/sdk-js` 1.71.0 and hit npm `ERESOLVE`.
## Why
The SDK's declared Zod peer range accepts only v3. Unversioned installs
select v4. The LangGraph quickstart, also served at
`/langgraph-typescript/quickstart.md`, does not explain this constraint.
## Fix
Add a version-scoped installation note with `npm install
@copilotkit/sdk-js@1.71.0 zod@3`, equivalent package-manager guidance,
and a note for existing Zod 4 applications. This avoids expanding SDK
compatibility in a documentation fix.
Reproduction in a clean temporary directory using published packages:
```text
npm install --package-lock-only --ignore-scripts --no-audit --no-fund @copilotkit/sdk-js@1.71.0 zod@4
ERESOLVE: Found zod@4.6.1; SDK requires ^3.23.3 || ^3.24.0 || ^3.25.0
npm install --package-lock-only --ignore-scripts --no-audit --no-fund @copilotkit/sdk-js@1.71.0 zod@3
up to date in 2s (exit 0)
```
LangGraph quickstart MDX compilation and `git diff --check` pass. Full
docs build not run. No SDK runtime behavior changes or claims of Zod 4
support.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added a prerequisite note for TypeScript users integrating LangGraph
agents.
* Clarified the required Zod version when installing the CopilotKit SDK.
* Added guidance to avoid bypassing dependency conflicts with
force-install options.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
The app can show a runtime error when the browser loads before
`/api/copilotkit/info` is ready. Reloading after startup clears it.
## Why
A listening SPA server does not prove the separate runtime has
registered its routes and agents. The SPA guide told readers to start
both processes and open the browser without a readiness check.
## Fix
Check `/api/copilotkit/info` for a successful response containing the
configured agent before opening the SPA. Explain how this also applies
when a dev script launches both processes, and how to recover if the
browser was already opened.
This is a surgical startup-guide fix. It does not add or change core
reconnect behavior.
Reproduced against production `CopilotKitCore` with a real localhost
HTTP server. The endpoint starts with 404, then returns valid runtime
info:
```text
Failed to load runtime info (.../api/copilotkit/info): Runtime info request failed with status 404
BEFORE: /info is now HTTP 200, but the already-mounted client remains error.
AFTER: checking /info before mounting connects on the first load.
```
A temporary Nx test asserted the early client's error, successful HTTP
readiness, continued error during the observed 300 ms interval, and a
connected client when created after readiness: **1 test passed**. No
fetch mocks, credentials, or model calls; this verifies the core
connection sequence, not a full browser/Mastra onboarding run. The
temporary harness is not shipped in this docs-only PR.
Validation: localhost reproduction passed, edited MDX parsed, and `git
diff --check` passed. Full docs build not run.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Updated the React SPA quickstart with a runtime readiness check before
opening the app.
- Added guidance to wait for the runtime’s `default` agent to appear in
the response.
- Clarified that a running Vite server does not guarantee runtime
readiness.
- Added recovery guidance to reload the app if its initial runtime
connection fails.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
An onboarding run reported a type error from passing `agent` to the v2
`CopilotKitProvider` when connecting a React SPA to LangGraph.
## Why
The integration quickstart shows the legacy `CopilotKit
agent="sample_agent"` API, while the SPA guide introduces
`CopilotKitProvider`. The SPA guide only demonstrates the default agent
and sends readers back to integration guides for external agents,
leaving this mapping unstated.
The report's precise claim that the SPA page itself passes `agent` could
not be reproduced: both its current source and live Markdown omit that
prop. The type error itself is reproducible against published 1.71.0
declarations.
## Fix
Add one named-agent example with `agentId="sample_agent"`, matching the
runtime registration, and explain when to omit it. No provider behavior
changes.
Validation using published `@copilotkit/react-core@1.71.0` declarations:
```text
const props: CopilotKitProviderProps = { children: null, runtimeUrl: 'http://localhost:8200/api/copilotkit', agent: 'sample_agent' };
TS2561: 'agent' does not exist in type 'CopilotKitProviderProps'. Did you mean 'agentId'?
```
Changing only `agent` to `agentId` passes `tsc --noEmit --skipLibCheck
--module esnext --moduleResolution bundler`. The React SPA MDX compiles
and `git diff --check` passes. Full docs build not run.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Added guidance for configuring `CopilotKitProvider` with a named
`agentId`.
- Included a `sample_agent` configuration example.
- Clarified that `agentId` is the supported provider property.
- Documented that the legacy `agent` property is invalid.
- Explained that `agentId` should be omitted when using the `default`
agent.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
`useAgent({ agentId, runtimeAgentId, threadId })` — a private proxied agent
pinned to one thread — shipped in v1.64.2 (27827adee2, type-enforced by
acdd9a9ef5) and has never been documented. `runtimeAgentId` appeared in no
docs page, and none of the 122 object-form `useAgent({...})` call sites in the
content tree passed a `threadId`.
The only writeup lived in the bundled react-core skill, which #7029 deleted.
That skill also had it wrong — it showed `useAgent({ agentId, threadId })`,
which is a compile error, and attributed per-thread isolation to `clone()`
rather than to `registerProxiedAgent`. deepshekhardas had corrected exactly
that in #6636, against the file #7029 removed; the prose here follows his
correction.
Adds to `reference/hooks/useAgent`:
- a "Two valid shapes" section, since the type admits nothing between binding
to a shared agent and binding a private one to a thread, and the reason
partial combinations are rejected (a runtime agent is a singleton, so a
per-hook threadId written onto it lets two hooks sharing an `agentId`
clobber each other's thread)
- `runtimeAgentId`, `threadId` and `throttleMs` property entries; all three
were absent, and the `agentId` entry now notes that in the thread-scoped
shape it is a *local* id that must not already be taken
Adds to the Headless Threads guide a "Driving one agent per thread" section,
because that is where someone building a multi-thread UI looks, and it was the
discovery path the reporter of #6125 was missing.
Refs #6125, #6636
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
## What
Replaces nine packaged knowledge skills with two entry points.
| | |
| --- | --- |
| `copilotkit` | The `copilotkit-docs` MCP server: four search tools and
two explore tools, which corpus answers which question, and the
instruction not to answer from memory. |
| `copilotkit-cli` | The CLI, led by `copilotkit verify --json`. |
**Deleted:** `copilotkit-setup`, `copilotkit-develop`,
`copilotkit-integrations`, `copilotkit-debug`, `copilotkit-upgrade`,
`copilotkit-agui`, `copilotkit-contribute`, `copilotkit-self-update`,
and the three package-generated skills (`react-core`, `runtime`,
`a2ui-renderer`).
Net: **-28,851 / +335 lines.**
**Kept, and out of scope here:** `setup-slack-channel`,
`channels-setup`, `copilotkit-channels`, `inspector-docs`,
`inspector-workbench`, `intelligence-docs`. The first three are
procedures rather than knowledge; the last three are internal
maintenance, not part of the public product. Their disposition is a
separate call.
## Why
The packaged skills had become a second copy of the documentation, and a
copy goes stale silently.
- `runtime` and `react-core` were roughly 60% transcribed API surface.
Of the remaining "Common Mistakes" prose, most already existed on a docs
page.
- Four claims in the deleted skills contradicted the source they cited.
One of them reached a shipped PR (#7005) before it was caught, and had
to be corrected in `14231a6169` — the skill asserted that server tools
cannot render UI because the browser never sees a tool-call start event,
which `packages/runtime/src/agent/index.ts:1519,1584` contradicts.
- `copilotkit-debug` was 1,289 lines of hand-written triage. Since
#1180, `copilotkit verify` covers version skew, CORS, and transcription
directly, which is most of what those lines described.
- Nothing in telemetry or in the issue tracker suggests the
per-lifecycle split was load-bearing for anyone.
The gotchas worth keeping were moved onto docs pages first, in #6993,
#6997 and #7021's predecessors, so this PR removes rather than discards.
## Also in this PR
- `skills` dropped from the `files` field of `@copilotkit/react-core`,
`@copilotkit/runtime` and `@copilotkit/a2ui-renderer`, so the tarballs
stop carrying a copy.
- `RESERVED_LIFECYCLE_SLUGS` in `scripts/sync-plugin-skills.ts` goes
from 14 entries to 8.
- `.claude-plugin/plugin.json` and `marketplace.json` descriptions no
longer advertise the deleted lifecycle.
- `/build-with-agents` (56,393 distinct viewers in 90 days) named three
deleted skills in a table and told the reader to "Use the
copilotkit-setup skill to get started". Rewritten for the two-skill
model.
- `README.md` and the two stale cross-references in
`copilotkit-channels/SKILL.md` updated.
- One dead `skills/copilotkit-setup/SKILL.md` entry removed from
`ALIAS_ALLOWLIST` in `scripts/validate-intelligence-env-names.ts`.
`scripts/__tests__/public-skill-drift.test.ts` guarded specific wording
inside files that no longer exist. It is now a link guard instead: every
`docs.copilotkit.ai` path a packaged skill names has to resolve to a
page in this repo, and the two entry points have to stay free of a
transcribed API surface (asserted as: no `sources.md` other than the
channels skill's).
## Supersedes
Closed in favour of this one, with a comment on each: #7017 (the CLI
skill, whose content seeded `copilotkit-cli`), #7021, #7023.
## Needs a decision from someone else
- **#5689** (@onsclom) is a skill-lift eval for `copilotkit-setup`,
which this PR deletes. No file overlap, so it will not conflict, but the
eval target is gone. Austin's call whether to retarget it at
`copilotkit` or drop it.
- **#6636** (community, for #6125) fixes
`packages/react-core/skills/react-core/references/agent-access.md`, the
one file it touches, which this PR deletes. Needs a reply to the author
explaining why, not a silent close.
- **Install-command drift, unresolved.** `README.md` and
`showcase/.../cli/cli.mdx` say `npx copilotkit@latest skills install`;
`/build-with-agents` says `npx skills add CopilotKit/CopilotKit/skills
-y`. Both commands work. Picking one retires a shipped CLI command,
which belongs in the Intelligence repo, so this PR leaves both in place
and changes only the prose around them.
## Testing
The worktree has no `node_modules`, so `lefthook` could not resolve
`tsx`, `oxlint` or `nx` and the commit used `--no-verify`. Every gate
the hook would have run was run by hand against the repo's own binaries,
and the pre-commit failure output was the "command not found" line in
each case, not a gate verdict.
`pnpm check:plugin-skills` — the mirror gate, which also enforces orphan
deletion:
```
$ tsx scripts/sync-plugin-skills.ts --check
plugin skill mirror in sync
```
`pnpm check:intelligence-env-names`:
```
$ tsx scripts/validate-intelligence-env-names.ts
Intelligence env var names and hosts are canonical.
```
Both script suites:
```
$ vitest run scripts/__tests__/public-skill-drift.test.ts scripts/__tests__/sync-plugin-skills.test.ts
Test Files 2 passed (2)
Tests 16 passed (16)
```
**Mutation-checked the new link guard**, so it is not passing for the
wrong reason. Appending `See
[nope](https://docs.copilotkit.ai/this-page-does-not-exist).` to
`skills/copilotkit/SKILL.md`:
```
⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯
+ "skills/copilotkit/SKILL.md: /this-page-does-not-exist",
Test Files 1 failed (1)
Tests 1 failed | 3 passed (4)
```
Restored, back to 4 passed. The guard already caught one real mistake of
mine while I was writing the skill: I had linked `/custom-look-and-feel`
from the nav list without checking, and the page is
`/custom-look-and-feel/css`.
`oxfmt` on the four changed TypeScript files: no changes. Both plugin
manifests re-parsed as JSON after editing.
MDX: `build-with-agents.mdx` changes are prose, one table body and one
fence body. Its JSX tag inventory is byte-identical to `origin/main`:
```
$ diff <(git show origin/main:$f | grep -o '</\?[A-Z][A-Za-z]*' | sort | uniq -c) \
<(grep -o '</\?[A-Z][A-Za-z]*' $f | sort | uniq -c) && echo IDENTICAL
IDENTICAL
```
`https://docs.copilotkit.ai/build-with-agents` returns 200, so the new
README link resolves.
Not run: the showcase docs build, which needs the per-entry
`node_modules` symlinks and the pretest generators this worktree does
not have. CI covers it.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added `copilotkit` skill for searching current documentation and
source.
- Added `copilotkit-cli` skill for project verification, onboarding,
authentication, scaffolding, and CLI commands.
- Added guidance to use `copilotkit verify` to validate project wiring.
- **Documentation**
- Updated marketplace, plugin, README, and agent-building guidance for
the new skills.
- Updated channel guidance to reference CLI-based setup.
- **Removals**
- Removed legacy setup, development, integration, debugging, upgrade,
contribution, and self-update skills.
- Package distributions no longer include bundled skill documentation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What does this PR do?
Points the Inspector's seven per-feature "Copy setup prompt" buttons at
the CLI's seven `--intent` feature routes, and retires the prose that
duplicated them.
Intelligence#994 shipped `onboard start --intent <slug>` and seven
feature routes. Nothing emitted the flag, so the only way to reach a
route was to type it by hand — and the Inspector had already solved the
same problem its own way, with a per-feature template of its own. Two
implementations of feature onboarding for the same seven outcomes, and
the routes had no caller at all.
**What changed**
* Home's feature buttons emit `onboard start --run <id> --coding-agent
<slug> --intent <slug>`.
* `homeFeatureImplementationPrompt` is gone. Its body — inspect first,
read the guide, make a plan, implement the smallest change, prove it
works — is what the route already carries, with per-phase check-ins, a
`feature/stop` route for a missing prerequisite, prompts pinned to a CLI
version through `onboarding-graph.lock.json`, and intent-tagged
telemetry on every step. A copied paragraph carries none of that and
drifts the moment the API moves, which had already happened once to
Learning.
* One table, `FEATURE_ONBOARDING_INTENT`, maps each tile to one intent.
`Record<HomeServiceId, OnboardingIntent>` makes a new tile without an
intent a type error, and a test holds the two sets equal in both
directions.
* The two docs feature prompts follow: the Learning and Rich Threads
guides name an intent instead of repeating setup prose. They pass no
`--run` id, because these strings are static and `llm-text` inlines them
into cached raw Markdown, where one minted id would be shared by every
reader. The CLI mints its own when the flag is absent.
**Two naming decisions, both recorded in code**
The two id sets stay separate. A `HomeServiceId` names a tile and the
pane behind it, so `websocket` and `audio` are right for it; an intent
names work to be done, so `add-realtime-sync` and `add-voice` are right
for that. One table maps between them rather than forcing one string to
be both.
`memory` maps to `add-learning`, and that is now a fact rather than a
guess. `learningOn` is `learningSnapshot?.configuration.state ===
"configured"` — a configured Learning *container*, which is exactly what
`feature/learning/start.md` sets up through `getLearningContainerId`.
The tile id `memory` and the `memories` menu key are older names for
that same pane.
**The generic prompts stay generic**
The Inspector's install prompt, the docs CTA, and the Intelligence web
app keep pointing at the generic route. All three are entry points for a
developer with no CopilotKit app yet, and every feature route requires
one: it inspects for an app first and reads `feature/stop` when it is
missing. The reasoning is written into `onboarding-prompt.ts` so the
next person does not have to rederive it.
## The release blocker is cleared
`copilotkit@4.9.50` published on 2026-09-10 and is now `latest`. Its
tarball carries all seven `intentRoots` and all seven `prompts/feature/`
directories, built from Intelligence `1e703c3c`.
The exact string this PR's buttons copy was run against the real
package:
```
$ npx --yes copilotkit@latest onboard start --run abc123def456 \
--coding-agent claude-code --intent add-a2ui
onboarding_run_id: abc123def456
onboarding_graph_tree: 249d0337...
# Add A2UI to the existing CopilotKit app
```
All seven intents exit 0 against the published package. An unknown
intent is refused with `ONBOARDING_INTENT_NOT_FOUND` and a list of the
seven valid slugs, so a future drift between the table in this PR and
the CLI's map fails on the first command rather than onboarding the
wrong feature.
The release pinned the same CopilotKit template commit as 4.9.47
(`380ad122`), so the only delta between the two CLI versions is
Intelligence-side.
## The shell-docs half was ungated, so this adds a job
No CI job ran the `showcase/shell-docs` vitest suite, and none of the
prompt files were in `test_integration-docs.yml`'s paths filter. The
assertions in that half were verified on a developer's machine and
nowhere else, which is the same gap the retired prose had.
`feature-prompt-intents` now runs the five prompt test files on any
change to them, scoped to those files because the whole suite is not
green on main. Verified by running the job's exact command locally: 5
files, 17 tests, all passing.
## Related PRs and Issues
- Closes OSS-1150
- Follow-up: OSS-1151
- Callers for CopilotKit/Intelligence#994
## Validation
Run in a worktree off `origin/main`, with pre-existing failures
confirmed by running the same specs against unmodified `origin/main` in
the same worktree.
* `web-inspector` — `tsc --noEmit` clean; `tsdown` build clean; `vitest
run` 662 passed, 35 failed. All 35 are `threads-states.spec.ts` dying in
`setupSettledState` on `Cannot assign to read only property 'mock'`,
which reproduces identically on `origin/main` (35 failed | 1 passed of
36, before and after). The one assertion this PR changes in that file is
therefore not exercised locally; the same button is covered by
`launcher-hud.spec.ts`, which passes.
* `web-inspector` — `tsc --project dev/tsconfig.json` reports 2 errors
in `dev/*-state-lab-server.ts`, both `Uint8Array` vs `BodyInit`; same 2
on `origin/main`.
* `shell-docs` — `tsc --noEmit` clean; `vitest run` 875 passed, 6 failed
in `brand-nav`, `angular-docs-content`, `llm-text` (mastra) and
`ms-agent-python-stable-api`; the same 6 fail on `origin/main`.
* `oxfmt --check` and `oxlint` clean on every file in the diff. The
three files oxfmt still flags are two generated JSON bundles and
`page-tree-bridge.ts`, none of them touched here.
## Checklist
- [x] I have read the Contribution Guide
- [x] If the PR changes or adds functionality, I have updated the
relevant documentation
- [x] "Allow edits by maintainers" is checked
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The packaged skills had grown into a second copy of the documentation.
`runtime` and `react-core` were roughly 60% transcribed API surface, and
most of their remaining "Common Mistakes" prose already existed on a docs
page. A cached copy of an API goes stale silently: four claims in the
deleted skills contradicted the source they cited, and one of them reached
a shipped PR before it was caught.
Replace them with two skills that look the answer up instead of restating
it:
- `copilotkit` — the four search tools and two explore tools of the
bundled `copilotkit-docs` MCP server, which corpus answers which
question, and the instruction not to answer from memory.
- `copilotkit-cli` — the CLI, led by `copilotkit verify --json`. Since
#1180 `verify` covers version skew, CORS, and transcription, which is
what most of the old `copilotkit-debug` skill described by hand.
Deleted: copilotkit-setup, copilotkit-develop, copilotkit-integrations,
copilotkit-debug, copilotkit-upgrade, copilotkit-agui, copilotkit-contribute,
copilotkit-self-update, and the three package-generated skills (react-core,
runtime, a2ui-renderer).
The `skills` directory is dropped from the `files` field of the three
packages that shipped one, so the tarballs no longer carry a copy.
`public-skill-drift.test.ts` guarded wording in files that no longer exist.
It is now a link guard: every `docs.copilotkit.ai` path named by a packaged
skill has to resolve to a page in this repo, and the two entry points have
to stay free of a transcribed API surface.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Completes the docs side of the runtime-skill consolidation. With #7005
and this, **every hazard the skill carries has a documented home**, so
the deletion can proceed without losing anything.
Three callouts — because most of these 15 turned out to be documented
already.
## Added
| Hazard | Home |
| --- | --- |
| A `BuiltInAgent` refuses a second concurrent run on itself |
`backend/copilot-runtime.mdx` § Agents |
| Don't call `.abort()` on a factory's `abortController` |
`backend/custom-agent.mdx` |
| What to pass when wiring an external agent, and which URL it takes |
`backend/copilot-runtime.mdx` § Agents |
The concurrent-run one is the most valuable. `Agent is already running.
Call abortRun() first or create a new instance.` — and every example
constructs the instance at module scope, so on a server serving more
than one person, the *second* concurrent request is the one that fails.
Nothing in the docs said so.
## Already covered, so nothing written
`maxSteps` and the tool-call loop. The `"provider:model"` rule —
`model-selection.mdx` states it *and* that `"provider/model"` also
works, which matches `index.ts:178` normalising `/` to `:`.
`forwardSystemMessages` defaulting to `false`. TanStack AI not surfacing
reasoning events. State tools and `config.tools` being the factory's
job, covered by both the Simple-versus-Factory table and the converter
reference.
Four of the six wiring hazards **cite a docs page as their own source**,
and each still holds: `getLocalAgents` returning a record is in the
Mastra guide, and the `/run` and `/agui` suffixes are in the LlamaIndex
and Agno guides.
## Not carried over
The skill flags defaulting to Simple Mode as a **HIGH** mistake and
calls Factory Mode with TanStack AI "the preferred default". Source
expresses no preference between the two — `isFactoryConfig` is a type
guard and nothing more, and the word "prefer" does not appear. The
skill's own evidence is an example file plus a maintainer conversation.
The docs say to stick with simple mode until you need more, which
nothing contradicts.
That is the **fourth** skill claim in this effort that source did not
support, after the deprecated-handler pair, the edge-runtime adapters,
and server-tool rendering. It was also the skill's headline
recommendation for this entire surface.
Also skipped: a hazard about passing a URL to `A2AAgent`. The documented
path is `A2AMiddlewareAgent`, so writing it would introduce an API the
docs deliberately leave out.
## Method note
Two hazards looked uncovered to a keyword search and were not.
`model-selection.mdx` states the model-string rule in quotes (``
`"provider:model"` ``), which my grep for `openai/` missed entirely; I
only found it by reading the file. Every "covered" verdict above came
from reading the page, and every "added" claim was verified against
source — `index.ts:997` for the concurrent-run message, `:746-748` for
the `abortController` JSDoc.
## Testing
Both changed files parse as MDX (`remark-parse` + `remark-mdx`):
```
OK docs/backend/copilot-runtime.mdx
OK docs/backend/custom-agent.mdx
```
## What this unblocks
The runtime skill's 27 files can now be deleted. Remaining prerequisites
for that are no longer about content:
- `packages/runtime/package.json` `"files": ["dist", "skills"]` needs
deciding
- Both copies must go together (`packages/runtime/skills/` and
`skills/runtime/`), which `check:plugin-skills` enforces
- One hazard stays unresolved by design: whether a thrown error in a
server tool kills the run. `/server-tools` says throw, the skill says it
kills the run, and nothing in the repo pins it. Worth a live test before
the deletion, so the answer isn't lost with the skill.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Added guidance for connecting external agents, including accepted
agent types and endpoint configuration.
- Documented concurrent-run limitations and recommended handling for
per-request agents or serialized turns.
- Clarified cancellation practices for custom agents to ensure proper
teardown.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Ran Shemtov