Enquire docs
    Enquire docs
    Getting startedUser guide
    ArchitectureBrowser toolsProcedures
    Claude Code integrationExtension guide
    DeploymentRoadmapBenchmarks
    Concepts

    Procedures

    Save browsing recipes as YAML procedures and replay them. CRUD + one-shot run via MCP.

    A procedure is a YAML recipe that captures how to accomplish a task on a specific site. Procedures are stored locally in the extension (chrome.storage.local), grouped by domain, and load as system primers when an agent works on that domain.

    This doc covers the v0 free-form Procedure tier — YAML body, no schema gate, replayable by an LLM. The typed + signed SKILL.md tools are listed in the Browser tools reference and remain a separate, more constrained tier.

    When to write a procedure

    Three signals you have something worth saving:

    1. You hit the same friction twice — e.g. Amazon's search-result price chips don't match cart prices, sponsored results redirect via tracking URLs that land on the wrong product. The first time you (or an agent) hit it, it's a footgun. The second time, capture the workaround.
    2. The task has a stable shape but variable inputs — "search Amazon for X, click into the product page, verify the cart price". Same flow, different X each run.
    3. You want a small model to drive it cheaply — once a procedure is captured, the next run can use a local Gemma 4 E2B model instead of Claude Sonnet, dropping cost to ~$0.

    Anatomy of a procedure

    Edit on GitHub

    Browser tools

    Auto-generated reference for the 31 MCP tools the bridge exposes — input shape, constraints, and descriptions.

    Claude Code integration

    Wire Enquire into Claude Code: HTTP MCP setup, multi-tunnel routing, common patterns.

    On this page

    When to write a procedureAnatomy of a procedureManage procedures over MCPTelemetryWorkflow: capture-and-promote
    # Procedure: Amazon JP shopping helper
# Domain: amazon.co.jp

notes:
  - DO NOT trust title-to-price index alignment from
    extract([data-component-type=s-search-result] h2). Search results
    have heterogeneous price markup; the Nth title is NOT the Nth price.
  - Sponsored search results redirect via /sspa/click tracking URLs.
    After clicking a search result, ALWAYS verify with list_chrome_tabs
    that the active tab title matches the intended product.
  - Cart-add success signal = the header badge "カート内の商品数：N"
    increments. Use find('カート内の商品数', kind:'link') after each add.

steps:
  - "navigate to https://www.amazon.co.jp/s?k=<query>"
  - "find the product link by exact title fragment"
  - "click into the product page; verify destination via list_chrome_tabs"
  - "extract the price from #corePrice_feature_div .a-price .a-offscreen"
  - "click 'カートに入れる'; verify cart count incremented"

    Three top-level conventions:

    • notes: — empirical observations and explicit don'ts. The agent reads these first.
    • steps: — the canonical happy-path flow, written in prose the agent interprets.
    • never: — hard rules. Agents should refuse to take any of these actions during execution.

    There's no enforced schema — write whatever helps a model do the task right. Common additions: verify: blocks (post-condition checks), selectors: (canonical CSS selectors that survive page redesigns), success_criteria: (what "done" looks like).

    Manage procedures over MCP

    The bridge exposes five procedure tools:

    ToolPurpose
    enquire__save_procedureCreate or upsert. Pass {name, domain, body, id?}. If id matches → update; else if (name, domain) matches existing → update; else create new. Returns {id, contentHash, created}.
    enquire__list_proceduresList metadata (no body, for compactness). Optional {domain} filter.
    enquire__get_procedureFetch one with full body by id.
    enquire__delete_procedureRemove by id.
    enquire__run_procedureOne-shot agent invocation. Loads the procedure body as the system primer, runs your prompt through the agent, increments totalRuns / successRate, returns {procedureId, conversationId, finalText}.

    You can also save and edit procedures via the extension's Options → Procedures UI on each profile.

    Telemetry

    Each procedure tracks:

    • totalRuns — incremented on every run_procedure call (regardless of outcome).
    • lastUsedAt — timestamp of the most recent run.
    • successRate — running average of agent runs that returned a non-empty finalText. (v0 success heuristic — a future tier will use richer signals like validate-step pass/fail.)

    This data is local to the extension. The dashboard has cloud-visible procedure records through api.enqr.dev/procedures, but extension procedure sync remains local-first while the sync path is hardened.

    Workflow: capture-and-promote

    The expected loop:

    1. Run a task with the cloud-tier agent (enquire__chat, Sonnet).
    2. When it succeeds, write down what made it work: the right selectors, the gotchas, the "never" list.
    3. Save as a procedure with save_procedure. Use a descriptive name + domain.
    4. Future runs: call run_procedure({id, prompt}) instead of chat. The agent loads your notes and steps as the system primer.
    5. Iterate: when the procedure breaks (site redesign, new edge case), update the body via save_procedure with the same id.

    Eventually, polished procedures can move toward typed + signed SKILL.md procedures, where deterministic execution replaces the LLM-driven recipe path for stable flows. Today, v0 free-form procedures are the default active tier.

    never:
    - "trust ¥-strings from search-result extraction without product-page verification"
    - "click sponsored search results without verifying the destination tab"