Skip to main content
Sightkick compiles a .sightmap/ corpus and a .sightkick/ tool layer into WebMCP tool IR. Agents call search_flights(origin, destination, date) on your running app instead of reading the DOM and guessing which element is the search box. It ships separately from Sightmap, as @sightmap/sightkick, and it reads the corpus Sightmap produces. The component names, selectors, and memory notes already committed in .sightmap/ are what the tools are written against.
Sightkick requires a corpus. If your app has no .sightmap/ yet, author one first — see the quickstart — then come back here.

​
Why a tool layer

A .sightmap/ corpus tells an agent what the page contains. It does not tell the agent what the page can do, or in what order. An agent still has to decide which components to touch, in which sequence, and how to read the result. A tool layer answers that. Each tool is one named action at a single point in time: its parameters, the ordered steps that carry it out, and the shape of what comes back. The agent calls the name and gets structured JSON. WebMCP is an early W3C proposal from Google and Microsoft for how a page declares callable actions to an agent running in the same browser tab. Almost no production app declares any yet. Sightkick compiles that surface from the outside, with no change to your application code.

​
How the pieces fit

1

.sightmap/ — the corpus

Views, components, and the properties extracted off them, authored against the running app with the Sightmap CLI. This is the only place a CSS selector appears.
2

.sightkick/ — the tool layer

Any number of YAML files, all merged into one manifest. Tools address elements by corpus component name; they never carry selectors of their own.
3

sightkick build — the IR

One self-contained JSON artifact. The compiler resolves every reference against the corpus and reports the ones it cannot find, with candidates. --verify additionally checks each returns extractor against a captured snapshot.
4

The runtime — the callable surface

A ~19 KB bundle registers the IR on document.modelContext. On Chrome for Testing that is the browser’s native WebMCP surface, so any WebMCP client reads your tools the same way it reads a site’s own.

​
Install

Sightkick ships as a prebuilt native binary through npm, so no Go toolchain is required. Installing its skills also pulls the supporting Sightmap skills.
That writes four agent skills into ~/.agents/skills:

​
A first tool

The corpus already names a FareCard component with price and stops properties. The tool layer turns that into something callable:
.sightkick/tools.yaml
Compile it, then call it:

​
Next

Author the tool layer

The .sightkick/ grammar: tools, steps, returns, guards, and journeys.

CLI reference

Every sightkick command and its flags.

Run tools on a live page

Injecting the runtime, and the difference between the two execution paths.

The front desk, illustrated

The same idea on sightmap.org, with the building metaphor.