Open protocol for safe AI website customisation

Let people choose how a website looks and feels.

Customex lets a website publish a machine-readable visual contract (manifest). AI can then translate natural-language requests into reviewable, reversible view changes.

Why it exists

Publisher-defined

Sites declare meaningful components, capabilities, allowed values, protected areas, and named views.

AI-assisted

Users can say “make this calmer” or “show only "design"- and "operations"-related posts.” The model proposes a patch, which the user has the authority to either accept or reject.

Safe by construction

The extension validates every action against the live manifest. Apply is explicit, changes are atomic, and Undo/clicking on a previous state restores the previous state.

Protocol surface

A minimal manifest describes visual surfaces. The reference client supports:

visibilitydensitythemelayout

Planned declarative capability families include:

groupingorderingcollapsingaccessibilityresponsive viewsmetadata projectionsdesign tokens

These future capabilities would remain publisher-declared and value-constrained. They can change a local, read-only view, but do not grant authenticated actions or arbitrary code execution.

AI does not define what a capability means. The website developer defines the allowed states and their rendering behavior; AI only maps user intent to one of those declared states:

User: "Fit more work on screen"

{
  "component": "workboard",
  "capability": "density",
  "value": "compact"
}
Customex.register({
      

A Customex client need not use AI at all: named publisher views can be applied directly. The reference extension uses Chrome's on-device model for short, local requests. A future client could let a user opt into a cloud model for larger semantic tasks, such as finding posts relevant to a design-system migration. In every case, the manifest still limits the resulting patch.

version: "0.1", site: { name: "Pulseboard" }, components: [{ id: "workboard", label: "Today's workboard", selector: "#workboard", capabilities: ["density", "theme", "layout"], constraints: { values: { density: ["compact", "comfortable"], theme: ["calm", "contrast"], layout: ["grid", "stacked"] }} }], views: [{ id: "focus", name: "Focus mode", description: "A calm, spacious workspace", actions: [{ component: "workboard", capability: "theme", value: "calm" }] }], policy: { protected: ["billing"] } });

Real-world use cases

Reading modes

Turn a news site into a distraction-free reading list, hide navigation, and enlarge text without changing the underlying service.

Work dashboards

Give a project board a focus, compact, or accessibility-oriented view for different moments in the workday.

Community recipes

Share advisory recipes such as “calm GitHub inbox” or “compact Reddit reading view.” Recipes can request declared values but never grant new permissions.

Customex and MCP

MCP commonly exposes tools that perform server-side work on a user's behalf. Customex is intentionally different: it is a presentation-layer protocol for choosing what a site shows and how it is rendered. Authentication, account mutations, and external side effects remain outside this reference protocol.

Extensible, without becoming an action protocol

Customex starts with visual capabilities such as visibility, density, theme, layout, metadata-based filtering, and named views. A publisher can also declare additional typed view capabilities with allowed values and CSS or site-owned rendering behavior.

The boundary is deliberate: Customex can change a website's local, read-only presentation, but it does not grant API access, credentials, account mutations, or external side effects. Those authenticated actions belong in a separate tool or a protocol like MCP.

Try the reference implementation

Run python -m http.server 8000 from the repository root, open Pulseboard or the JSON-backed feed, then load the unpacked Chrome extension from extension/. The feed includes publisher views and deterministic topic filtering.