Skip to main content
A general browser agent rediscovers a site on every run: where the login form is, which button submits, how long the dashboard takes to render. A site-specific skill writes that knowledge down once, so the agent starts from what already works. For a site you automate repeatedly, this is usually what moves reliability the most. Everything below assumes agent-browser with the Kernel provider (agent-browser -p kernel); the same structure works with the SDKs.

​
One skill per domain

Name the skill folder after the site’s primary domain — the domain where the automation actually happens:

​
Skill template

When KERNEL_PROFILE_NAME is set, the profile is created if it doesn’t exist, and cookies, logins, and session data are saved back to it when the session ends. That’s what makes the second run of a skill cheaper than the first.

​
Discovering the workflows

Work through the site once, interactively, and write down what you learn.
  1. Open a session with a profile so the login survives.
  2. Snapshot before every interaction. Element refs (@e1, @e2) are session-specific and change after navigation and significant DOM updates.
  3. Document the login flow. Most sites are one of three shapes: a single-page form, a two-step form (username, then password), or an OAuth redirect. If bot detection or a strange login page blocks you, don’t grind — get the live view URL and have a person log in once, then let the profile carry it:
  4. Walk each workflow the agent will need — navigate, snapshot, interact, verify — and record the URL patterns, the element refs, the waits, and how you confirm success.
  5. Test each step alone before combining them, then end to end.

​
Techniques worth knowing

Prefer direct URLs to navigation. If the site has a stable deep link, use it. https://www.kroger.com/mypurchases beats four clicks through a menu. Wait on conditions, not clocks. A fixed sleep is the last resort:
Fall back to JavaScript for stubborn elements.
Cross-origin iframes need Playwright. Get the session ID with kernel browsers list, then run playwright execution against the frame. Never put credentials in SKILL.md. Use managed auth or a profile so the agent never sees them. If a site’s flow genuinely needs credentials in the agent’s config, keep them in the agent config file and reference them from the skill rather than duplicating the values.

​
Patterns by site type

​
Kernel best practices to bake in

These apply to every skill you write, and they’re the defaults the Kernel rules file installs into your agent:
  • Always delete browsers when done — try/finally so cleanup is guaranteed.
  • Set timeout_seconds on every browser as a safety net.
  • Turn on stealth for any site with bot detection.
  • Use a profile for anything behind a login, with save_profile_changes: true.
  • Use headless: true when nobody needs to watch.
  • Proxy quality for anti-detection, best to worst: mobile → residential → ISP → datacenter.
  • Never hardcode credentials.

​
Measuring whether a skill is actually better

A skill is a prompt, and prompts regress. Once a skill exists, treat it as something to measure rather than something that’s done: run the same task set with and without it and compare completion rate, steps, and wall-clock time. Two Kernel projects do this end to end and are worth reading before you build your own harness: