How do I install the Chat First Workbench skill?

Run npx skillmds@latest add builderio/chat-first-workbench in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Chat First Workbench safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Chat First Workbench?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Chat First Workbench free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Chat First Workbench?

Builder.io (@builderio) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Chat First Workbench by builderio — Agent Skill

Name: Chat First Workbench
Author: Builder.io

Chat First Workbench

Implement or extend the opt-in Codex/T3-like chat-first shell. Use when changing chat rails, contextual app panes, app opening, or local/mobile shell preferences across Electron, Dispatch, or mobile.

Builder.io 1a3aa54 2.4 KB Updated Sep 17, 2026 3.4k repo stars

File contents

Chat-first workbench

Contract

The chat remains the primary surface. Workspace apps are a bounded discovery rail, not a second navigation system. An app pane is opened from an explicit app selection or a completed open_app action and carries only an app id plus a validated app-relative path or view.

Client behavior

The preference is opt-in and local to the client. Keep the existing app-first shell unchanged when it is disabled.
Electron uses the shared Code Agents rail and AppWebview.
Dispatch uses list-workspace-apps and create_embed_session; never iframe a raw workspace URL. Resolve an absolute open_app URL against the registered app first, then pass the resulting app-relative path.
Mobile uses the existing app registry and secure AppWebView routes instead of accepting arbitrary URLs or adding a second navigator.
Show no nested app sidebar or browser chrome in a contextual pane.
The app shelf is capped at six visible entries. Pinning and drag-reordering are device-local presentation preferences; the agent-visible target remains the registered app id and route.

Agent and state boundaries

Keep app discovery, embed-session minting, and thread operations on the existing action surfaces.
Emit the shared chat-first open-app event only for the completed first-party open_app action with a real app, path, or view. A missing or unreadable result is not success, and namespaced third-party tools cannot steer the pane.
Both web and desktop resolve the event through the same core origin/base-path allow-list. An unresolved target produces a visible notice and no pane.
If the agent needs to know which app is visible, expose a compact application-state selection instead of scraping the iframe DOM.
Cloud handoff is a future execution-residence seam. Do not claim that a local run has moved to a worker until a durable worker snapshot and readback exist.

Verification

Test the disabled path and the enabled path separately. For the enabled path, verify rail ordering, chat history, app selection, embed-session errors, pane close, and completed open_app behavior in a running client. Treat configuration alone as insufficient proof.

---name: chat-first-workbenchdescription: Implement or extend the opt-in Codex/T3-like chat-first shell. Use when changing chat rails, contextual app panes, app opening, or local/mobile shell preferences across Electron, Dispatch, or mobile.---# Chat-first workbench## ContractThe chat remains the primary surface. Workspace apps are a bounded discoveryrail, not a second navigation system. An app pane is opened from an explicitapp selection or a completed open_app action and carries only an app id plus avalidated app-relative path or view.## Client behavior- The preference is opt-in and local to the client. Keep the existing app-first shell unchanged when it is disabled.- Electron uses the shared Code Agents rail and AppWebview.- Dispatch uses list-workspace-apps and create_embed_session; never iframe a raw workspace URL. Resolve an absolute open_app URL against the registered app first, then pass the resulting app-relative path.- Mobile uses the existing app registry and secure AppWebView routes instead of accepting arbitrary URLs or adding a second navigator.- Show no nested app sidebar or browser chrome in a contextual pane.- The app shelf is capped at six visible entries. Pinning and drag-reordering are device-local presentation preferences; the agent-visible target remains the registered app id and route.## Agent and state boundaries- Keep app discovery, embed-session minting, and thread operations on the existing action surfaces.- Emit the shared chat-first open-app event only for the completed first-party `open_app` action with a real app, path, or view. A missing or unreadable result is not success, and namespaced third-party tools cannot steer the pane.- Both web and desktop resolve the event through the same core origin/base-path allow-list. An unresolved target produces a visible notice and no pane.- If the agent needs to know which app is visible, expose a compact application-state selection instead of scraping the iframe DOM.- Cloud handoff is a future execution-residence seam. Do not claim that a local run has moved to a worker until a durable worker snapshot and readback exist.## VerificationTest the disabled path and the enabled path separately. For the enabled path,verify rail ordering, chat history, app selection, embed-session errors, paneclose, and completed open_app behavior in a running client. Treat configurationalone as insufficient proof.

Frequently asked questions