Add Webex channel integration via Chat SDK.
Adds Cisco Webex support via the Chat SDK bridge. NanoClaw doesn't ship channels
in trunk — this skill copies the Webex adapter in from the channels branch.
The mechanical steps under Apply carry nc: directive fences: an agent
reads the prose and applies them, and a parser can apply them deterministically
from the same document. Every directive is idempotent, so the whole skill is
safe to re-run; anything a parser can't apply falls back to the prose beside it.
Fetch the channels branch and copy the Webex adapter and its registration test
into src/channels/ (overwrite — the branch is canonical):
src/channels/webex.ts
src/channels/webex-registration.test.ts
Append the self-registration import to the channel barrel (skipped if the line is already present). This one line is the skill's only reach-in into core:
import './webex.js';
Pinned to an exact version — the supply-chain policy rejects ranges and latest.
The Webex adapter ships under the third-party @bitbasti/* namespace, not
@chat-adapter/*, so it carries its own version line (0.1.0) rather than
tracking the chat core version:
@bitbasti/chat-adapter-webex@0.1.0
Build first: it guards the typed createChatSdkBridge(...) core call and proves
the dependency is installed. Then run the one integration test.
pnpm run build
pnpm exec vitest run src/channels/webex-registration.test.ts
webex-registration.test.ts imports the real channel barrel and asserts the
registry contains webex. It goes red if the import line is deleted or drifts,
if the barrel fails to evaluate, or if @bitbasti/chat-adapter-webex isn't
installed (the import throws) — so it also covers the dependency from step 3.
End-to-end delivery against a real Webex space is verified manually once the
service runs — see the webhook setup below.
Webex bot setup is human and interactive — these steps are prose, not directives (no parser can click through the Webex Developer Portal). A recipe rebuild produces a compiling, registered adapter that cannot receive a message until they're done.
https://your-domain/webhook/webex.Capture the two values, then write them. prompt only asks and binds the
answer to a name; a separate directive consumes it — so the same prompts could
feed ncl or the OneCLI vault instead of .env by swapping only the consumer.
Here they go to .env (set-if-absent — a value you've already filled in is
never overwritten):
Paste the Bot Access Token — from the Webex bot you created.
Paste the webhook secret you set for signature verification.
WEBEX_BOT_TOKEN={{bot_token}}
WEBEX_WEBHOOK_SECRET={{webhook_secret}}
The Chat SDK bridge automatically starts a shared webhook server on port 3000
(WEBHOOK_PORT to change it), handling /webhook/webex. This port must be
publicly reachable for Webex to deliver events. Running locally, expose it with
ngrok (ngrok http 3000), a Cloudflare Tunnel, or a reverse proxy on a VPS —
the resulting public URL is the base for the webhook URL above.
If you're in the middle of /setup, return to the setup flow now. Otherwise run
/manage-channels to wire this channel to an agent group.
webexGET /rooms) to list spaces and their IDs.Sends fail with 401. The Bot Access Token is shown once, on the bot's page under developer.webex.com → My Apps — it is not the 12-hour personal access token from the API docs pages, which is the classic mix-up (that one works briefly, then everything 401s). Regenerate the token on the bot page if needed; regenerating invalidates the old value, so update WEBEX_BOT_TOKEN right away.
Messages in the space never reach the agent. Webex delivers only to the webhook you created: it must target your public host at /webhook/webex (shared webhook server, port 3000) with resource messages. List your webhooks with GET https://webexapis.com/v1/webhooks using the bot token — Webex flips a webhook to inactive after repeated delivery failures, and it stays off until you re-enable or recreate it.
Events arrive but are rejected. Signature mismatch: the secret set at webhook creation must equal WEBEX_WEBHOOK_SECRET exactly. Recreate the webhook with a known secret and update .env to match.
Adapter installed but silent. Run pnpm exec vitest run src/channels/webex-registration.test.ts — red means the barrel import or the @bitbasti/chat-adapter-webex install drifted, so re-run the Apply steps. If green, restart the service so it loads the adapter and the tokens, then watch logs/nanoclaw.log for the webhook hit.
Copy a source-pinned command for your client. You run it yourself.
Destination: .claude/skills/add-webex · pinned to the source commit
# Run from your project root
git clone https://github.com/nanocoai/nanoclaw.git .skillboard-tmp
git -C .skillboard-tmp checkout 7be8d7f6b9863e7c78c513717c21a6fcf04c3d28
mkdir -p ".claude/skills"
cp -r ".skillboard-tmp/.claude/skills/add-webex" ".claude/skills/"
rm -rf .skillboard-tmpReview the source before running. This copies files into your project; it is not a one-click install and does not verify runtime safety.
sudo apt update && sudo apt install -y gitnpm install -g @anthropic-ai/claude-code# Run from your project root
git clone https://github.com/nanocoai/nanoclaw.git .skillboard-tmp
git -C .skillboard-tmp checkout 7be8d7f6b9863e7c78c513717c21a6fcf04c3d28
mkdir -p ".claude/skills"
cp -r ".skillboard-tmp/.claude/skills/add-webex" ".claude/skills/"
rm -rf .skillboard-tmpDestination: .claude/skills/add-webex
Scanner static-checks@0.1.0 · commit 7be8d7f6b986. Static checks cannot prove runtime safety – review the source and the exact diff before installing. How checks work.
References credentials, tokens or secret files that a skill should not need.
Evidence: [redacted]· fingerprint e9cbb0224c4a3d23