CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

70

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

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.

Repository
BuilderIO/agent-native
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.