How it works#

Click Guide has three moving parts. A script in your page, a console where your team works, and an index built from content you approve.

The overlay#

The script loads after your page renders. It attaches one element to the body and builds everything inside a shadow root, so your stylesheet cannot reach in and its styles cannot leak out.

The overlay is transparent to clicks. Every layer it draws passes pointer events straight through to your application, and only the instruction card accepts input. Your dropdowns open. Your handlers fire. A help layer that swallowed the click it was pointing at would be worse than no help at all.

When a guide runs, the page dims and one control stays lit. The instruction sits beside it. The user clicks the real button in your real application, and the guide moves on.

Finding the control#

This is the hard part, and most of the engineering lives here.

Click Guide does not store a CSS path. A generated path breaks when somebody adds a column, sorts a table, or ships a class rename. Instead it records what a person sees: the visible label, the accessible name, the role, the destination of a link, and where the control sits on the page.

Then it filters by what is actually on screen. Many applications render their navigation twice, once for phones and once for desktops, so a label matches two elements and only one has any size. Checking visibility first turns that ambiguity into a single answer, and it does so without a scoring model or a guess.

Some controls cannot be pinned down, and Click Guide says so rather than pretending. A button in a table row is identified by the row it sits in, and the row is identified by your customer's data. Bind a guide to that and it works for one account and fails for every other. So the step widens instead: it highlights the control on every row and lets the user choose which record they came for. The guide stops saying "click the row called Acme" and starts saying "click the row you want", which is what it should have said first.

Recording a guide#

Two ways in.

A person records it. An author opens the application, and Click Guide watches. Each click becomes a step, with its target, its confidence, and a warning where the confidence is thin. The author writes the copy, previews the run, and publishes a version.

An agent drafts it. An agent explores a test environment and drafts guides for the tasks it finds, along with a glossary of screens and fields. It only opens menus, expands rows, and follows links. It never submits a form, never types into an input, and never touches a confirmation dialog. Everything it produces lands as a draft, and a human publishes it.

The agent runs against test environments, never live ones. That restriction is enforced on the server, not requested in a prompt.

Answering questions#

Upload your documentation. Click Guide extracts the text, keeps the headings and page numbers so a citation can point somewhere real, and indexes it against your workspace alone.

A user asks a question. The assistant searches only your approved content, only for your application, and only in the environment they are in. It answers in a few sentences and shows the passage it used. Where it lacks the evidence, it says that instead of filling the gap with something plausible.

If the answer is a task rather than a fact, it offers the guide.

Publishing and rollback#

A published guide is a version, and a version never changes. Publishing writes a new one and moves a pointer. Rolling back moves the pointer again.

Your users only ever receive published versions. Drafts stay in the console, invisible to the runtime, which means an author can work on next month's onboarding flow while this month's keeps running.

What we keep#

Where your controls are. Which steps people finish. Which ones they abandon. Which questions came back empty.

What we do not keep: passwords, payment fields, input values, page snapshots, or the contents of your users' records. The overlay learns the shape of your interface, not the data inside it.

Every guide that fails tells you something. A step people abandon is a screen that needs work. A question with no answer is a page your documentation never covered. The help layer ends up reporting on the product it was installed to explain.