chat-sdk-add-adapter
Skill8 starsChanged 26 days agoApache-2.0View on GitHub
Add a vendor-official or community adapter to the Chat SDK catalog and docs — adapters.json registry, chat/adapters catalog entry, the docs MDX page, meta.json, integration-test lists, and a changeset. Use when a developer wants to add, list, register, or submit a third-party (vendor-official or community) adapter to this repo, add an adapter to the catalog, or create or edit an adapter docs page under apps/docs/content/adapters/vendor-official or apps/docs/content/adapters/community.
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Use this to list a third-party adapter in the Chat SDK catalog and docs.
- Distinctive: line 12
Ask the user for:
- Distinctive: line 17
Read both. Everything you write into the catalog and docs must come directly from those sources or from the user.
- Distinctive: line 24
If the repo or README does not make something clear, stop and ask the user rather than filling it in.
- Very specific: line 55
Imports: Every import in an MDX code block must be listed in VALID_DOC_PACKAGES.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Add a catalog adapter (vendor-official or community)
Use this to list a third-party adapter in the Chat SDK catalog and docs. It is not for building a first-party packages/adapter-* package.
Gather the source — never invent details
Ask the user for:
- Their adapter's GitHub repository URL.
- Their docs or README.
Read both. Everything you write into the catalog and docs must come directly from those sources or from the user. Do not assume or guess any information:
packageName— read it from the repo'spackage.json, verbatim.- Factory export (e.g.
createFooAdapter) — read it from the package's exports/source. Do not guess it from the display name. type(platformorstate), env vars, and the feature matrix — base these on what the code and README actually document.- Install and usage snippets — take them from the README; do not write example code the adapter may not support.
If the repo or README does not make something clear, stop and ask the user rather than filling it in. When in doubt, ask.
Choose the slug (kebab-case) and confirm it is not already taken: ls apps/docs/content/adapters/*/.
Pick the tier
- community — listed in the docs only. No
chat/adapterscatalog entry, no changeset. - vendor-official — a maintained/blessed adapter. Everything community has, plus a
chat/adapterscatalog entry, a matchingcreate-chat-sdkscaffold-spec entry, and a changeset. Frontmatter addsvendorOfficial: trueandauthor.
Files to change
<tier> is vendor-official or community.
apps/docs/content/adapters/<tier>/<slug>.mdx— the docs page. Start from assets/adapter.mdx. The filename basename must equal theslugfrontmatter field, and the page must render<FeatureSupport />.apps/docs/content/adapters/<tier>/meta.json— add"<slug>"to thepagesarray.apps/docs/adapters.json— add a registry entry:name,slug,type,community: true,description,packageName,author,readme(the GitHub URL). AddvendorOfficial: truefor vendor-official.packages/integration-tests/src/docs-adapters.test.ts— add"<slug>"to the hardcoded expected list for its tier.packages/integration-tests/src/documentation-test-utils.ts— add thepackageNametoVALID_DOC_PACKAGES, plus every import specifier used in the MDX code blocks (subpaths count separately).
Vendor-official also:
packages/chat/src/adapters/index.ts— add anADAPTERSentry withgroup: "vendor-official". Reuse theenv/secretEnv/urlEnvhelpers; useenv: { notes: "…" }when there are no env vars. Seepackages/chat/src/adapters/AGENTS.md.packages/create-chat-sdk/src/catalog/scaffold-spec.ts— add a matching"<slug>": { invocation: … }entry, modeled on a similar adapter. This is a required registration step, not a behavior change: the object issatisfies Record<AdapterSlug, …>, so every catalog slug must have one orcreate-chat-sdkfails to type-check..changeset/<slug>-adapter.md—"chat": patch+"create-chat-sdk": patch, one line describing the addition.
Invariants the tests enforce
- Registry ↔ catalog parity.
Object.keys(ADAPTERS)must equal the adapters.json slugs where!community || vendorOfficial. So vendor-official must be inchat/adapters; community-only must not be. This is why community adapters skip steps 6–8. - peerDeps ↔ PackageInstall. The catalog entry's
peerDeps(sorted) must exactly equal the extra packages in the MDX<PackageInstall package="…" />, after removing the adapter's ownpackageName,chat, and any@chat-adapter/state-*. Easiest:peerDeps: [], install only<packageName> chat(plus a state adapter) inPackageInstall, and keep any other imports in fenced code blocks. - Fields match.
packageName,type,community, andvendorOfficialmust match between the MDX frontmatter and the adapters.json entry. - Required frontmatter:
title,description,packageName,slug,tagline,type(platform|state),mdxBody: true,community: true(plusvendorOfficial: trueandauthorfor vendor-official). - Imports. Every import in an MDX code block must be listed in
VALID_DOC_PACKAGES.
Validate
pnpm --filter chat build # regenerate the catalog the tests import
pnpm --filter @chat-adapter/integration-tests test
pnpm --filter chat typecheck
pnpm --filter create-chat-sdk typecheck # vendor-official only
pnpm check && pnpm konsistentResources
- Human guide (vendor-official):
apps/docs/content/docs/contributing/vendor-official.mdx - Human guide (community listing):
apps/docs/content/docs/contributing/publishing.mdx - MDX template: assets/adapter.mdx
- Catalog conventions:
packages/chat/src/adapters/AGENTS.md - Examples to copy:
apps/docs/content/adapters/vendor-official/andapps/docs/content/adapters/community/
In this repository21 other files it gives its agents.
- AGENTS.mdAGENTS.md
- mongodb-atlas-stream-processingSkill
- mongodb-connectionSkill
- mongodb-mcp-setupSkill
- mongodb-natural-language-queryingSkill
- mongodb-qe-size-estimationSkill
- mongodb-query-optimizerSkill
- mongodb-schema-designSkill
- mongodb-search-and-aiSkill
- mongodb-connectionSkill
- mongodb-natural-language-queryingSkill
- mongodb-query-optimizerSkill
- mongodb-schema-designSkill
- mongodb-search-and-aiSkill
- agent-engine-feature-validationsSkill
- agent-engine-troubleshoot-deploySkill
- atlas-agent-engine-docsSkill
- atlas-agent-engineSkill
- chat-sdkSkill
- deploy-mongodb-agentsSkill
- gh-stackSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

