Skip to content

Surfaces

Every place an extension can put UI, and the rules specific to each — a settings page built like a standalone modal (or vice versa) reads as foreign immediately, so know which surface you're building for before you pick components.

Modals

An extension can create three kinds of modal UI. They share the same components and tokens, but each has its own layout conventions, persistence pattern, and best practices.

Standalone modals

Opened with ctx.ui.showModal — a dialog your extension owns end to end: pickers, forms, confirmations richer than ctx.ui.confirm, detail views.

The host provides the shell: backdrop, the title (pass title — never render your own heading), sizing (sm 400px / md 560px / lg 800px), the close ✕, Escape handling, the focus trap, and stacking.

You provide everything inside, ending in a ModalActions footer.

Rules specific to this surface:

  • Persistence is explicit. The user edits, then commits or abandons: one primary action (rightmost), a neutral Cancel beside it. Wire both to the close callback showModal hands you.
  • Set dismissible: true only when closing can't lose user input; the default (non-dismissible) protects staged edits.
  • Pick the smallest size that fits; don't design content that needs the modal to grow.
  • Scrollable middles (long lists) get .silo-scroll with a max height, so the title and footer stay pinned.

Settings pages

Registered with ctx.registerSettingsPage — your page appears in Silo's Settings modal, alongside the built-in Editor and Terminal pages.

Settings
Editor
Terminal
My Extension
Auto-refresh
Poll the API in the background.
Poll interval
Minutes between checks.

The host provides the whole Settings chrome: the left rail (your page's entry appears under Extensions), the page title, scrolling, and search.

You provide the page body: Sections of SettingRows.

Rules specific to this surface:

  • Persistence is immediate. Every control applies the moment it changes — there is no footer, no Save button, no Cancel on a settings page. Persist with ctx.storage as the change happens.
  • Structure is SectionSettingRow → one control per row (Switch, Select, a number Input, …). Prose-heavy layouts don't belong here.
  • Use RadioGroup/RadioCard when one choice needs a sentence of explanation per option.
  • Don't build a rail, tabs, or your own page title — the rail is host chrome, and pages that need internal grouping use Tabs within the page body sparingly.

Workspace property tabs

Registered with ctx.workspaces.registerPropertyPage — your page appears as a tab in the Workspace Properties modal, next to the built-in General tab, scoped to one workspace.

Monitor this workspace
Watch workflow runs for repos in this workspace.

The host provides the modal, the tab strip, and your tab's placement; your page receives the workspace it's scoped to.

You provide the tab body — typically SettingRows and small forms, same grammar as a settings page.

Rules specific to this surface:

  • Persistence is immediate, like settings pages — values save as the user edits (use workspace-scoped ctx.storage.workspace). No footer.
  • Everything on the tab should be about this workspace. Global extension settings belong on a settings page; don't duplicate them here.
  • Use visible to hide the tab for workspaces where it's meaningless (e.g. no matching repo), rather than showing an empty tab.
  • Don't render your own tab strip — you're in one. If your tab needs sub-navigation, it's probably two property pages.

Choosing between the three, in one line each

  • Transient task the user completes and leaves → standalone modal.
  • How the extension behaves everywhere → settings page.
  • How the extension behaves for this workspaceworkspace property tab.

Side panels

Registered with ctx.registerSidePanel — a persistent panel docked in Silo's side column, alongside the file explorer and git panel.

Coming soon

Side panel components and layout patterns — headers, toolbars, empty states, and how the modal kit's components (List, Badge, EmptyState, …) carry over into a docked panel — aren't documented yet.

Status bar items

Registered with ctx.registerStatusItem — a compact item in Silo's status bar, alongside the branch indicator and process monitor.

Coming soon

Status bar item patterns — icon + label conventions, click/hover behavior, badge and color usage at that scale — aren't documented yet.

Dock panels & editors

Registered with ctx.registerEditor or ctx.registerDockPanelKind — content that lives in Silo's center dock alongside the code editor and terminal.

Coming soon

Dock panel and editor UI patterns — toolbars, breadcrumbs, and how much of the modal kit (if any) is the right fit for a content viewport — aren't documented yet.