Build · For builders

Build the workflow. Publish the extension. Monetize your expertise.

Turn specialized knowledge into a focused product. Reuse ISA Warden for agents, models, identity, projects, files, audio, and other host services—then package the value you create.

Built on ISA Warden

Extension architecture

A focused UI, connected through a controlled bridge

Normal extension code runs in an iframe and calls only the host commands it declared. Native logic is optional and should be reserved for work that genuinely needs local binaries or operating-system access.

01

Extension UI

Svelte and Vite in a sandboxed iframe

02

Host bridge

Capability discovery and permission checks

03

ISA Warden services

Projects, files, chat, documents, audio and themes

Verified repository workflow

Scaffold and package a minimal extension

The current CLI is installed from a checked-out ISA Warden repository. A standalone public registry install is not documented yet.

What you need

  • Access to a checked-out ISA Warden repository
  • Rust and Cargo for the repository CLI
  • Node.js and npm for the generated extension
  • A compatible ISA Warden build for local mounting and testing

Result: The build produces the dist/acme-review.isax package directory. It contains the public extension.json manifest and a compressed payload whose SHA-256 digest is recorded for integrity verification.

Next: Mount the generated source directory through ISA Warden’s developer extension installation flow, then test it in the workspace and group contexts it supports.

Repository access is currently required. Contact developer support.

Terminal
# From a checked-out ISA Warden repository
cargo install --path chat-ui-3/extensions/isa-ext

# Create a minimal extension
isa-ext scaffold --name "Acme Review" --author "Acme" --directory acme-review
cd acme-review

# Validate and produce the .isax package
npm run build
Capability check
const info = await window.isaExtensionBridge.invoke('get_app_info', {});

if (!info.projects?.canRead) {
  showUnavailable('Projects are not available in this group.');
  return;
}

const { projects } = await window.isaExtensionBridge.listProjects({
  includeArchived: false
});

Discover before use

Ask the host what is available

A manifest permission is a request, not a guarantee. Check the current launch context and advertised commands before showing a feature, and provide a useful unavailable state.

Host capabilities

Use the platform instead of rebuilding it

Choose only the capabilities the workflow needs and discover their availability at runtime.

01

Chat and scoped documents

Stream host chat and attach only documents that the host has ingested and approved for the current extension thread.

Manifest stream_chat, document_ingestion

02

Group files and user grants

Store extension-owned group data or ask the user to grant access to a specific workspace file or folder.

Manifest filesystem_read, filesystem_write, filesystem_delete

03

Shared projects

List and create stable project identities shared by every project-aware extension in the active group.

Manifest projects_read, projects_write

04

Audio and transcription

Use host-owned microphone recordings and group-authorized speech-to-text providers without receiving local audio paths or credentials.

Manifest audio_capture, transcribe_audio

05

Host themes

Follow light and dark mode with the extension theme bridge and stable extension-facing design tokens.

Manifest No additional data permission

06

Optional native logic

Package target-specific binaries only when browser and host capabilities cannot do the job.

Manifest native_code

Security by construction

Authority stays with the user and host

An extension is not independently privileged. The host combines user rights, contextual visibility, declared permissions and host policy for every operation.

  • Request only the permissions the workflow needs.
  • Operate within the current user’s workspace and group rights.
  • Let the host inject the frozen launch context; do not accept caller-supplied scope.
  • Use the bridge instead of handling dashboard tokens in extension code.
  • Ask users to grant specific files and folders, and handle revocation.
  • Disclose native code and privileged host modifications before distribution.

One identity, isolated content

Projects connect workflows without merging their data

The Shared Project Registry provides one stable identity and name for the active group. Each extension stores its own content in its own group folder, keyed by that shared project ID.

Active group Shared project ID
ISA Compareisolated content
ISA CV Compareisolated content
ISA Scribeisolated content

Planned extension marketplace

Turn a workflow into a product

Prepare a listing that explains the outcome, earns trust, and will make the value of your expertise easy to evaluate when the marketplace launches.

01

Present the value

Show the problem, intended audience, workflow, screenshots, and example outcomes.

02

Make trust visible

Declare permissions, models, providers, data behavior, compatibility, and native-code boundaries.

03

Plan the commercial model

Prepare possible pricing, licensing, trial, subscription, or organizational terms for launch.

04

Plan support and growth

Define compatible updates, customer support, and a feedback process for the workflow.

Extension store availability and commercial terms are subject to launch.

Product lifecycle

From expertise to a publication-ready product

  1. 01

    Scaffold

    Create the manifest, entry page and build script.

  2. 02

    Build

    Compile the UI and any optional native assets.

  3. 03

    Declare

    List the minimum permissions and compatibility version.

  4. 04

    Mount and test

    Use developer installation to test the source directory locally.

  5. 05

    Validate and package

    Run the build and inspect the generated .isax package directory.

  6. 06

    Prepare to publish

    Prepare the listing, support plan and possible commercial model ahead of marketplace launch.

A strong listing explains both the value of the workflow and the trust requirements of the extension. Marketplace availability and commercial terms remain subject to launch.

Before distribution

Validate behavior and package integrity

Package checks protect integrity; interface and fallback checks protect the people using the extension.

  • Run the extension root npm run build.
  • Test light and dark themes, keyboard focus and narrow layouts.
  • Test every capability fallback and revoked-permission state.
  • Confirm the manifest parses, the entry exists and every declared asset is packaged.
  • Confirm dist/<id>.isax/extension.json and payload.tar.xz exist.
  • Confirm payloadSha256 matches the generated payload.
  • Inspect permissions, compatibility, native code and model disclosures in both manifests.

Build · Publish · Monetize

Build the workflow. Publish the extension. Monetize your expertise.

Start with one valuable job, reuse the host capabilities it needs, and prepare your specialist knowledge for distribution and future marketplace launch.