Clickable prototype in 48h
AI & integrations

E-commerce process mining

Employee process mining for an e-commerce back office: a consented browser extension that records DOM events, not pixels, a form for the work a browser cannot see, and an AI pipeline that writes per-role SOPs and ranks what to automate.

Repository
timerise-ai/ecommerce-process-mining
Released
September 29, 2026
Build it with TimeriseBuild it yourself
npx skills add timerise-ai/ecommerce-process-mining
v0.1.7
Current release
13
Reference docs
6
Non-negotiables
MIT
License

The problem

What problem does E-commerce process mining solve?

Nobody in an e-commerce back office can tell you exactly how an order, a return or a supplier claim is handled. The work is spread across the shop admin, marketplace seller panels, carrier portals, the helpdesk and the ERP, and it lives in people's heads. Onboarding takes months, audits guess, and automation projects start without a map.

Recording that work is possible, but the screens are full of other people's data. The employee can consent. The customer whose order is on screen never did. That single fact decides the design.

This skill gives a coding agent the whole pipeline the way we build it: a consented Manifest V3 extension that reads DOM events rather than pixels, exclusions applied in the extension and again on the server, values that would need scrubbing never read at all, a gap-capture form for work outside the browser, and a batch AI step that turns the record into per-role SOPs and a ranked list of what to automate first. Managers see aggregates, and consent is re-read on every batch.

The module

What does the skill build?

An agent with this skill builds one module as a Chrome MV3 extension and the Next.js App Router app it reports to, on your stack. For E-commerce process mining that module consists of:

  • 1. A consented MV3 extension reading DOM events rather than pixels
  • 2. A gap-capture form
  • 3. An ingest route that scrubs before it stores
  • 4. A batch AI pipeline writing per-role SOPs and a ranked automation shortlist

Provenance

Where do the rules come from?

This skill was written by the engineer who has shipped this module. The earlier implementation it was audited against was the employee process-mining module of a back-office platform, of which the consent record, the gap-capture form and a manager view ran while the capture path existed as design notes. The templates here hold the properties such a module has to hold: consent that is per person and per tenant and answered from the database on every batch, one exclusion matcher imported by both sides, a scrubber that tells a card number from a barcode, a one-time code that can be redeemed exactly once, a consent history nobody can rewrite, and an enrollment count that is withheld when the number would name the people. Each is stated as a rule below and held by the suites in `references/testing.md`; `references/provenance.md` has the record, and the maturity tags say which parts have run in production and which have not.

The engineering ledger for this skill. Three things are kept apart here, and keeping them apart is the skill's credibility: what the audit of the earlier implementation changed and how the templates verify it, what was kept deliberately and why it is safe, and what was designed here and has never run in production. Read this file before simplifying anything in references/: most of the odd-looking parts of the templates are an entry below.

The ledger separates what the audit changed, what was kept on purpose, and what has not run in production yet.

  1. Fixed: defects in the running code **[P]**

    Six entries. Each names what the templates do instead and where that is verified.

    • The consent switch could show Off while the server said On The toggle updated local state before calling the server and never rolled back on failure. A failed revoke left the switch Off, an error toast faded, and the server still held an active consent. Latent only because no capture existed yet. Shipped: a server-confirmed toggle, with its suite, in console-surfaces.md.
    • Managers could read who opted in The principle was written down: aggregate only. The row-level policy granted process_mining:read holders SELECT on the consent table, so any manager's browser client could list individuals regardless of what the page rendered. Shipped: no team policy, and a suppressing aggregate function, in data-model.md. The SQL checks assert that a manager role reads zero consent rows.
    • Consent was one row per user in a multi-tenant system Primary key user_id, with a tenant column. The platform supported staff shared across tenants. Granting in a second tenant rewrote the row: the first tenant's consent vanished with no revoke recorded, while captured events were strictly per-tenant. Shipped: the composite key (user_id, scope_id).
    • Two sources of truth for the tenant The consent action re-derived the tenant by joining user to store to organisation; the page and the policy's with check used the session claim. When the two disagree the policy refuses the write. Read from the code, not reproduced at runtime. Shipped: the session's tenant everywhere, in the page, the action and the policy.
    • No consent history Re-granting overwrote consented_at. Revoking with no row updated nothing, silently, and still emitted a "revoked" audit event. History lived only in an event log with a short hot retention. Shipped: an append-only ledger with an immutability trigger; a zero-row revoke is reported to the caller.
    Show 2 more
    • Enrollment count capped and unscoped Counted by fetching rows and reading .length, so it was bounded by the API's maximum-rows setting, 1,000 by default on Supabase, and it carried no tenant filter, so an all-tenant admin saw more consents than employees. Shipped: a server-side count inside the stats function, scoped to the acting tenant.
    • Smaller ones, fixed in the same pass Entries were accepted under soft-deleted categories. A delete reported success for zero rows. The entry list stopped at a fixed cap with no signal. Every string was hard-coded in English inside an internationalised app. Dates were formatted in the server's locale rather than the viewer's.
Read the full record in provenance.md

Non-negotiables

What are the 6 rules the module never breaks?

Every module built from this skill holds these, whoever builds it. The same list is in the skill's README and SKILL.md, so the agent reads it before it writes a line.

  1. A privacy switch never fails open.

    Unreadable pause state reads as paused, an unparseable host reads as excluded, and a failed consent save leaves the toggle showing what the server believes. The pause reducer, the exclusion matcher and the toggle hook each assert their failure case.

  2. A value you would have to scrub is never read.

    Password, card, one-time-code and hidden fields are skipped at the point of capture, and the scrubber is the net behind that, not a licence to read. The value gate and the scrubber have separate suites, and the scrubber runs again on the server, where it is authoritative.

  3. A one-time code is claimed in one statement.

    DELETE ... RETURNING, with the challenge verified after the claim, so two concurrent redeems cannot both mint a key. The SQL checks run a first claim, a second claim, a wrong extension id and an expired code.

  4. An authorization request from an unknown extension id is refused.

    A well-formed id proves nothing about who published the extension, so the console keeps an allowlist in configuration, empty by default and with no id written into code, and re-validates it in the authorize action, where hidden inputs are attacker-controlled.

  5. Success is never reported for an event that was not stored.

    The emitter returns false rather than swallowing a write error, and the route answers 207 with the indexes to retry, because a 200 makes the extension delete its only copy. An in-memory store standing in for a missing database is not storage.

  6. Who opted in is not a manager's business.

    There is no team policy on the consent table, only an aggregate function that suppresses small groups and full enrollment alike. The SQL checks assert that a manager role reads zero consent rows, whatever the page renders.

Fit

When should you use it, and when not?

Use it for

  • Mapping real order, return, listing, purchasing or support workflows across several web tools
  • Building the capture extension, its consent, exclusion and pause controls, or the ingest API
  • Generating per-role SOPs, or ranking manual work by cost so automation can be scoped

Not for

  • Customer behaviour on the storefrontInsteadProduct analytics. This module captures staff at work, not shoppers
  • "Who opened this link"InsteadServer-side visit logging; the visit-logger skill
  • Data out of, or actions into, a service with no APIInsteadThe sibling `browser-extension-connector` skill, which replays the page's own session; this one only observes what the employee does
  • Process mining over ERP or OMS event logsInsteadA data-warehouse job over case id, activity and timestamp. No capture is needed
  • Productivity scoring, leaderboards, who has not opted inInsteadNothing here. The database withholds the rows, and references/consent-and-privacy.md says why
  • Session replay or screen recordingInsteadA replay vendor. This reads the DOM and stores structure, not video
  • Work in desktop applicationsInsteadThe gap-capture form. A browser extension sees browser tabs only

Build it yourself

How do I install it?

One command. The skills.sh CLI installs the skill into every skills-compatible agent it finds.

$ npx skills add timerise-ai/ecommerce-process-mining

Claude Code

Invoke with /ecommerce-process-mining

Codex CLI

Invoke with $ecommerce-process-mining

Gemini CLI

Invoke with /skills

Name the agents instead with -a, for example npx skills add timerise-ai/ecommerce-process-mining -a claude-code -a codex. Or clone the repository into your agent's skills folder. Nothing in it is agent-specific.

What is inside the repository (16 entries)
  • SKILL.mdEntry point: the architecture diagram, ten critical facts, six hard rules, the quick start, and the reference directory
  • references/adaptation.mdThe seam contract with the host app: tenancy, auth, capabilities, API keys, the event store, the rename table, background jobs, placement
  • references/consent-and-privacy.mdThe two groups of people, the four capture layers, pause against revoke against disconnect, the excluded-domain module, what the employee is told, the legal layer
  • references/data-model.mdNeutral TypeScript shapes, the Postgres schema with RLS and the consent ledger, the Supabase and Firestore variants, volume estimates
  • references/console-surfaces.mdThe employee page and the manager page: the server-confirmed consent toggle, the gap-capture form, automation ranking, the help page, their suites
  • references/ingest.mdThe ingest contract: authentication, the consent re-read, per-event validation, idempotency, 207 with retry indexes, counters and retention
  • references/pii-scrubber.mdThe scrubber: card against barcode, IBAN, JWT, email masking, sensitive labels, credential URLs, per-deployment configuration
  • references/extension-auth.mdThe connect handshake: PKCE, launchWebAuthFlow, the extension-id allowlist, the atomic claim, minting and revoking the scoped key
  • references/extension.mdManifest V3, the tested control logic for pause, budget, queue and session, label resolution and dom_confidence, the Chrome wiring, the unproven assumptions
  • references/screenshots.mdScreenshot modes, the capture gate and throttle, viewport and crop perceptual hashing, bounding boxes, upload and retention
  • references/ai-pipeline.mdThe three batch stages, routing on dom_confidence, embeddings, SOP output and the guardrails
  • references/ecommerce-playbook.mdWhich tools to capture in a shop, which processes to mine first, default gap-form categories, the rollout order, how it goes wrong
  • references/testing.mdWhat is verified and how: the vitest suites, 76 cases, and verify.sql, 24 SQL checks, plus what to add in the host
  • references/provenance.mdThe engineering ledger: the maturity tags, what the audit changed, what was kept deliberately, what was added here, what is unverified
  • evals/The prompts an operator types after installing (prompts.md) and one file per agent eval: the skill installed into an empty Next.js app, one prompt, no help, then type-checked, built and tested
  • .github/workflows/agent-eval.ymlThe caller of the index's eval workflow: runs prompt 1 in Claude Code, Codex CLI and Gemini CLI on every published release, and any prompt on a maintainer's dispatch

Recent releases

  1. v0.1.7September 29, 2026

    Wording release, from scoring the prompt-1 agent eval runs against 0.1.6. The templates and the suite are unchanged.

  2. v0.1.6September 29, 2026

    Wording release, from scoring the prompt-1 agent eval runs against 0.1.5. The templates and the suite are unchanged.

  3. v0.1.5September 29, 2026

    Wording release, from scoring the prompt-1 agent eval runs against 0.1.4. The templates and the suite are unchanged.

SKILL.md README.md CHANGELOG.md

After installing

What do I tell my agent?

Say what you need in your own words; the skill supplies the how. These are starting points, and the ones we tested say how it went.

  1. Build a browser extension our back-office staff install with consent. It records what they do in the shop admin and carrier portals as DOM events, never screenshots, and sends them to our Next.js app on Supabase.

    SupabaseGemini CLIBuilt, checks passCodex CLIBuilt, checks passClaude CodeBuilt, checks pass

  2. From the captured events, write an SOP for each role and rank the manual tasks worth automating by the time they take.

    Supabase

  3. Make sure the capture never stores card numbers or customer emails, and that staff can pause it or exclude a domain.

Tested

How does it do in each agent?

We install the skill into an empty Next.js app, give the agent one of the prompts above and no further help, then type-check, build and run the tests it left behind. Nothing is fixed by hand before the checks, and a failing run is published like a passing one. The procedure and every result are public, and the first prompt runs again before each release.

  • Gemini CLI0.61.0

    gemini-3.8-flash

    Built, checks pass
    Build a browser extension our back-office staff install with consent. It records what they do in the shop admin and carrier portals as DOM events, never screenshots, and sends them to our Next.js app on Supabase.
    Typecheck: passBuild: passTests: pass
    Time
    13 min
    Changed
    51 files, +6,251 lines
    Stack
    Supabase
    Skill
    v0.1.7
    Run
    Sep 29, 2026

    Result fileAgent log

    What we saw

    Rubric 8/8, scored from the final summary. The nine suites report 76 under vitest, its SQL sits in host.supabase.sql, the allowlist is empty configuration with a key-generation script, the database seam answers 503 without an in-memory store, a session without a tenant is signed out in every environment, and the summary closes with the three handover points in the skill's words.

  • Codex CLIcodex-cli 0.159.0

    gpt-6-astra

    Built, checks pass
    Build a browser extension our back-office staff install with consent. It records what they do in the shop admin and carrier portals as DOM events, never screenshots, and sends them to our Next.js app on Supabase.
    Typecheck: passBuild: passTests: pass
    Time
    17 min
    Changed
    78 files, +6,348 lines
    Stack
    Supabase
    Skill
    v0.1.7
    Run
    Sep 29, 2026

    Result fileAgent log

    What we saw

    Rubric 8/8, scored from the transcript. Its final diff touches no template: its own modules and SQL sit in dom-policy.ts, lib/host/*, schedule.supabase.sql and verify.host.sql. It installed from the registry, the nine suites run unchanged under vitest (76 of 94), .env.example is tracked and empty with ALLOWED_EXTENSION_IDS, and the final message closes with the three handover points.

  • Claude Code2.1.284

    claude-opus-5-5

    Built, checks pass
    Build a browser extension our back-office staff install with consent. It records what they do in the shop admin and carrier portals as DOM events, never screenshots, and sends them to our Next.js app on Supabase.
    Typecheck: passBuild: passTests: pass
    Time
    15 min
    Changed
    75 files, +7,858 lines
    Stack
    Supabase
    Skill
    v0.1.7
    Run
    Sep 29, 2026

    Result fileAgent log

    What we saw

    Rubric 8/8, scored from the final summary. The skill's SQL files are unchanged with its own in host.supabase.sql, the nine suites report 76, routes answer 503 without credentials and pages redirect to sign-in, PM_ALLOWED_EXTENSION_IDS is empty by default with no id in code, and the summary closes with the three handover points.

Build it with Timerise

How long does it take, and what does it cost?

We quote this module per project. The price depends on what it has to connect to. The path to a number is short and free:

  1. Step 1

    Brief

    Tell us what the module must connect to. Takes minutes, in a chat.

  2. Step 2

    Prototype in 48 hours

    A clickable prototype of your system and a quote, at no cost.

  3. Step 3

    Build and handoff

    One project price. Source code, documentation and IP are yours.

Two ways to get E-commerce process mining

Build it yourself

Install the skill. Your own agent builds the module.

  • MIT licensed, no strings
  • Runs in Claude Code, Codex CLI and Gemini CLI
  • The same rules our engineers build by
$ npx skills add timerise-ai/ecommerce-process-mining
Install the skill

Build it with Timerise

Send a brief. We build E-commerce process mining into a system you own.

  • Clickable prototype and a quote within 48 hours, free
  • One project price, no subscription, no commission
  • Source code, documentation and IP handed over
3 years of support included.
Start the brief

Generated from the skill's own files at commit 74e4f80. Every rule above links to where the repository says it. All skills