webmcpify — make any web app agent-ready, verifiably

You are running the webmcpify pipeline. It takes an existing web application and exposes its user-facing functionality as WebMCP tools (document.modelContext — a proposed web standard incubated in the W3C Web Machine Learning Community Group, currently a Chrome origin trial), so browser AI agents can operate the app through structured tool calls instead of guessing at the DOM.

DETECT ──▶ INVENTORY ──▶ [HUMAN GATE: manifest approval] ──▶ INTEGRATE ──▶ VERIFY ──▶ HEAL ──▶ AUDIT
              ▲  loop            per-area batches on big apps    ▲  loop      ▲ loop    ▲ loop
              └── per area                                       └── per manifest entry ──┘

Everything you need ships inside this skill directory: phase guides in references/, and vendorable code in templates/ (runtime, ambient types, JS variant, React JSX typings, verification spec). Never assume files exist outside the skill dir.

Out of scope (stop and say so): backend-only MCP servers (that's classic MCP, not WebMCP), automating third-party sites you don't control, and generic SEO work.

Invocation modes

The user may pass an argument (/webmcpify <mode> or plain words):

Any other text is scoping guidance (e.g. "only the checkout area", "read-only tools only").

Ground rules (non-negotiable, enforce in every phase)

1. Zero unrelated changes. Every diff hunk you produce must trace to a manifest entry or the recorded one-time setup. Never refactor, reformat, rename, or "improve" anything else — note problems in the report instead. Files that were already dirty at baseline (recorded in the manifest) are untouchable: never modify or revert them.
2. Read-only tools first. Mutations are tri-state: mutating: false, "client" (browser-local only: prefs, localStorage), or "server" (data leaves the browser). Server-mutating tools require explicit per-tool human approval recorded in the manifest; client-mutating tools may be approved as a batch at the gate. Never expose destructive, irreversible, or payment actions in a first integration.
3. The server is the only trust boundary. A tool's execute() may only call code paths the UI already uses (same endpoints, same validation, same auth). Never create new endpoints, never bypass existing checks, never put secrets in tools.
4. Spec-shaped and dependency-free. Register via document.modelContext.registerTool() with AbortSignal lifecycle (feature-detect the deprecated navigator.modelContext fallback). No third-party WebMCP runtime dependencies. Everything feature-detected: the app behaves identically in browsers without WebMCP.
5. Never toolautosubmit on state-changing forms — neither mutating: "client" nor "server". Only on pure read forms (search, filter, availability).
6. State lives in files, not in your context. Read/write .webmcpify/ constantly; assume your context can be wiped between any two steps. Write the manifest atomically (write manifest.json.tmp, then rename over manifest.json).
7. Commits are opt-in. Never commit unless the human chose a commit policy at the gate (see below). Without git or without permission, leave changes in the working tree and record progress in the manifest only.

Fresh, authoritative guidance

WebMCP is an evolving origin-trial API — the surface has already changed during the trial (testing API removed 2026-07; navigator → document). Before Phase 2, if network is available, pull Google's current official guides rather than relying on memory:

npx -y modern-web-guidance@latest retrieve "webmcp,agentic-forms,agentic-javascript-tools"

If offline, use references/integrate.md — but prefer the live guides when they conflict.

…