Opencli Browser Sitemap
Guide an agent through site navigation with opencli browser using lazy sitemap reads instead of blind clicking.
Overview
opencli-browser-sitemap is an agent skill most often used in Build (also Validate, Ship) that drives opencli browser sessions using lazy sitemap context while always privileging live browser state over sitemap guesses.
Install
npx skills add https://github.com/jackwener/opencli --skill opencli-browser-sitemapWhat is this skill?
- 6-step consumption loop from state refresh through stale-entry handling
- Reads only SITE.md, matching page/workflow markdown, and pitfalls when blocked
- Prefers named opencli adapters before raw browser fallback actions
- Treats sitemap as prior knowledge that must lose to live browser state
- Resumes workflows via state_signature comparison after each navigation
- 4 sitemap file types (SITE, pages, workflows, pitfalls)
Adoption & trust: 127 installs on skills.sh; 23.8k GitHub stars.
What problem does it solve?
You are automating a website with an agent but only have a sitemap or workflow docs, so the model clicks blindly and drifts off the real UI.
Who is it for?
Solo builders running opencli browser open or analyze with sitemap.available true who need repeatable, state-checked navigation on multi-page products.
Skip if: Static one-URL fetches, sites without sitemap context, or tasks where you refuse browser tooling and only need a single API call.
When should I use this skill?
opencli browser open or analyze reports sitemap.available true, or the user asks to use a site’s sitemap with opencli browser.
What do I get? / Deliverables
After the loop runs you navigate via the smallest sitemap slice, adapter-first when possible, with refreshed state signatures and stale sitemap flags when the live page disagrees.
- Navigation path following best or fallback workflow
- Updated stale sitemap notes when live state diverges
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Primary home is Build because it extends opencli browser sessions with structured agent workflows and adapter-first paths. Agent-tooling fits procedural browser control, state signatures, and session-scoped automation rather than shipping a user-facing feature.
Where it fits
Walk a competitor’s logged-out funnel using sitemap workflows without guessing URLs.
Post or configure via a named opencli adapter before falling back to raw clicks.
Replay a documented smoke workflow and confirm state_signature after each step.
How it compares
Use instead of ad-hoc “click until it works” browser prompts when you already maintain sitemap markdown for the site.
Common Questions / FAQ
Who is opencli-browser-sitemap for?
Indie builders and small teams using Claude Code, Cursor, or Codex with opencli browser who maintain SITE.md-style sitemap bundles and want agents to follow documented workflows.
When should I use opencli-browser-sitemap?
Use when opencli reports sitemap.available, the user asks for sitemap-guided browsing, during Validate prototype walkthroughs, Build integration flows, or Ship smoke paths that must match documented state signatures.
Is opencli-browser-sitemap safe to install?
It allows Bash(opencli:*), Read, Edit, Write, and Grep—review the Security Audits panel on this page before granting browser and filesystem access on production accounts.
SKILL.md
READMESKILL.md - Opencli Browser Sitemap
# opencli-browser-sitemap Use this skill when `opencli browser open` or `opencli browser analyze` reports `sitemap.available: true`, or when the user asks you to use a site's sitemap. The sitemap is **prior knowledge**, not ground truth. It should reduce blind clicking, but it must never override the live browser state. --- ## Consumption Loop 1. Run or reuse `opencli browser <session> state` to know the current page. 2. Read only the smallest relevant sitemap files: - `SITE.md` for site-level orientation. - One matching `pages/<page-id>.md` for current state. - One matching `workflows/<task-id>.md` for the user goal. - `pitfalls.md` only when blocked or warned by the workflow. 3. Prefer the workflow's **Best path**. If it names an adapter such as `opencli twitter post`, use that before raw browser actions. 4. If the adapter is unavailable or fails, use the **Fallback path** browser workflow. 5. After each navigation or state-changing action, refresh `state` and compare the workflow's `state_signature`. 6. If reality disagrees, trust reality, continue probing, and write a local stale note or draft patch. 7. If an action recovery includes `adapter_health_update: <adapter> -> suspect|broken`, update the local overlay workflow that references that adapter so future agents go straight to the fallback path. --- ## Lookup Order Read local overlay first, then global seed: ```text ~/.opencli/sites/<site>/sitemap/ # local overlay sitemaps/<site>/ # repo seed (top-level) ``` Local files override global files with the same stable id. Do not load an entire large sitemap into context. If the directory is large, list filenames first and then read only the page/workflow you need. --- ## Trust Reality Rule If sitemap says a button, URL, route, or API should exist but the browser does not show it: - Re-run `state` or `find` with semantic anchors. - Check whether login, locale, viewport, A/B test, or route state differs. - Follow the real page if a safe path is visible. - Mark the sitemap item stale in local overlay. Never keep clicking because "the sitemap says it should work." --- ## Stale / Draft Notes When you discover drift, write a small local note under the relevant page/workflow file or a draft file in the local overlay: ```md Stale note: - observed_at: YYYY-MM-DD - current_url: - expected: - actual: - next_probe: ``` Do not edit global seed files unless the task is explicitly a sitemap-authoring or repo PR task. ## Adapter Health Write-Back When an adapter fails and the sitemap action or workflow tells you to update adapter health: 1. Find the local workflow file under `~/.opencli/sites/<site>/sitemap/workflows/` whose `Best path` references the adapter command. 2. If no local workflow exists, copy the matching global workflow into the local overlay first; never edit the global seed directly during browser task execution. 3. Set `adapter_health: suspect` or `broken` as directed. 4. Add a short stale note with observed error, current URL, and timestamp. 5. Continue with the browser fallback path. This write-back is the memory loop: the current agent falls back once, and the next agent does not waste a turn retrying a known-suspect adapter. --- ## Output Discipline When reporting back, include: - Path chosen: adapter best path or browser fallback. - Checkpoint reached: current URL/state signature. - Sitemap health: used as-is, stale marked, or missing workflow. Keep the report task-focused. Do not summarize the whole sitemap.