Help that knows which screen you are on

Someone stuck on a compensation screen at the end of a pay cycle clicks the help button. It opens the help center's home page in a new tab. It does not know which screen they came from, so they start searching from nothing, in the middle of the job they were trying to finish.

The question was whether help could open on the right article instead, without changing a line of the product.

Two ways in, neither touching the product

The product is a client-rendered app we do not own. That left two routes that need no deploy.

A browser extension, built first because it depends on nothing in the app. It reads which screen you are on and shows matching articles in Chrome's side panel. The side panel is deliberate. The app ships global styles, and a panel injected into the page is one CSS collision away from breaking the page it is there to help. The help center token lives in the extension's background worker, the only place no page can reach it.

Pendo, which was already running inside the app and can inject a guide. This one reaches everyone, with nothing to install. It also replaced the button that started this: Pendo already had a "Help Center Articles" link, and it went to the home page. The new panel sits in the same place and opens on the screen you are on.

Pendo code runs in every user's browser, where anything it knows can be read from devtools. So it carries no credentials at all. It ships with a saved copy of the article list, and a new article means a rebuild. A slower update path is the price of not handing everyone an admin token.

Finding the screen, then the article

Most screens have no headings, so the page title does the work. The app sets it after load, which is why the extension checks it every second. A table of route hints expands a cryptic route into the words a person would search for, and routes not in the table fall back to splitting their names apart.

Matching is BM25 over a local index of every article summary, not the help center's own search. That was not an optimization. The search endpoint only indexes published articles, and about half the help center, 639 of 1,305 articles, was still in draft. Local matching finds drafts. Server-side search cannot.

The real problem was the articles

The extension worked, and the results were poor. Of those 1,305 articles, twelve were about this product. Four sections had names and no articles in them: pay proposals, salary scales, pay summaries, and closing a pay cycle. A search cannot find an article that was never written.

So the project changed shape. We built a skill for a coding agent that works like a technical writer. It opens the app, visits each screen, records what is actually there, and writes the article for that screen, with the closest existing articles ranked underneath.

It never clicks Save, Delete or Archive. This is a working HR system with real employee data, so the agent reads and never writes. That means it cannot always tell what a button does, and when it cannot, the article says so. Every article ends with a list headed "Needs verification before publishing." It does not guess.

Drafts only, by construction

The articles reach the help center through an MCP server we wrote for it. Its read tools list, search and fetch. Its write tools exist only when writing is switched on, and there are two of them. Creating an article forces it to draft. Updating one never touches its publish state, and refuses to edit a published article unless told to explicitly. There is a dry-run mode that logs what it would have done.

There is no publish tool. Not a disabled one, not one behind a flag: the code path does not exist. Thirteen articles went in, covering all four empty sections, in a new section only staff can see. A person publishes them after answering what the agent could not.

The same rule as the recruiting agent, arrived at from the other direction. There, the agent can do what the signed-in person can do. Here, it can do less than any person on the team, on purpose, because what it writes goes out under the company's name.

Held to the house standard

Both panels use the design system, and every color pair was checked against WCAG. That found two real problems: white text on the orange accent failed at small sizes, and the green meant for success backgrounds had been used as text. Both are fixed.

Then the articles were rewritten to the help center's own writing standard, which sets five article types: task, overview, reference, best practice and troubleshooting. One of each for fourteen screens is seventy articles. The panel shows them on the screen they describe, one section per type.

Walking every screen also turned up two bugs in the product itself: a menu item that opens the home page instead of its report, and a misspelled route. Both are written up for the team that owns it.

What it showed

It took about a week. The retrieval was the easy part. The finding was that contextual help fails first on content, and that an agent can close that gap fast if it is only ever allowed to write drafts, says what it does not know, and leaves the last step to a person.