slicc

Use this whenever the user asks to browse, navigate, click, fill a form, scrape, take a screenshot, or otherwise interact with a web page. SLICC drives the browser through the `playwright-cli` shell command (also aliased as `playwright` and `puppeteer`). Read this BEFORE running any browser automation: every tab-operating command requires a `--tab` target id, and multi-agent tab handling has rules you must follow.

Record short demo videos of UI features using playwright-cli. Captures browser interactions with a visible animated cursor, chapter markers, and produces trimmed MP4s ready for GitHub PRs. Use when asked to record a UI demo, showcase a feature, or create a video for a pull request.

Use this skill when the user says things like `handoff to slicc`, `move this to slicc`, `move to the browser`, `test in the browser`, `handoff to browser`, `install this skill in slicc`, `upskill slicc with this repo`, `add this skill to slicc`, or otherwise asks you to continue the work in the SLICC browser agent or install a skill into it.

Use this when the user wants to change the SLICC UI appearance — switch preset themes, create custom themes, adjust colors, toggle the animated background, or export/import theme files. Covers the theme shell command, full token reference, and the JSON format for programmatic theming.

Use this whenever the user asks to mount anything — local folders, S3 buckets, S3-compatible services (Cloudflare R2, MinIO), or Adobe da.live / AEM Document Authoring repos. Read this skill BEFORE deciding which backend to use; do NOT default to a local file picker when the user names a remote service. Covers credential setup with profile-namespaced `secret set` keys (e.g. `s3.aws.access_key_id`) or the extension Options page, the right `mount --source` invocation per intent, and common errors (EACCES on missing credentials, EBUSY on concurrent edits, EFBIG on oversized files).

Use this when you need to test or QA the `playwright-cli` browser-automation command, re-run the browser-automation test session, check playwright-cli for regressions, or verify that browser automation still works after a change. Covers a repeatable 12-group e2e session: a `pcli-e2e` runner that automates the deterministic groups and diffs against a known PASS/FAIL baseline, a reusable HTML test fixture, and a manual checklist for the visual/interactive groups. For everyday browsing/scraping (not regression testing) use the `playwright-cli` skill instead.

Use this when the user wants to write a new skill, edit an existing one, or understand SLICC's skill system. Covers SKILL.md frontmatter (name, description, allowed-tools), how to write a description that triggers reliably, native `/workspace/skills/` vs compatibility `.agents/` / `.claude/skills/` discovery, and when to ship companion files like `.jsh` scripts or `.bsh` browser hooks.

Use this when the user wants a persistent UI panel — a dashboard, form, editor, report, or visualization that lives alongside the chat. Sprinkles are `.shtml` files under `/shared/sprinkles/` rendered in the side rail or as a full-screen tab. For ephemeral inline widgets, use dips instead. Covers creation, modification, layout constraints, the cone-to-scoop orchestration rules, the `slicc.*` bridge API, and `sprinkle chat` for blocking inline prompts.

Search X (formerly Twitter) for real-time posts, sentiment, and citations via xAI's `x_search` server-side tool. Works with any model — the search call runs through your xAI Grok OAuth credentials regardless of which model is steering the cone. Use when you need fresh social-media signal, public reactions, or to find specific posts by keyword, hashtag, or handle.

Use this when you receive an `[Upgrade Event: x.y.z→a.b.c]` lick — fired on boot whenever the bundled SLICC version differs from the previous run. The lick renders a binary action card: `lick_confirm` to Update workspace files (three-way merge of bundled `vfs-root` files against the user's local edits) or `lick_dismiss` to clear it. Reviewing the changelog from GitHub is a separate step you can run first. Never auto-applies; the user resolves the card.

Use this when you receive a Navigate Event lick — emitted whenever the user opens a tab whose main-frame response advertises a SLICC handoff via an RFC 8288 `Link` header. Covers both verbs: `handoff:` renders a human approval card and acts on accept (never auto-accept, never fetch before approval); `upskill:` installs via the `lick_confirm` / `lick_dismiss` lick tools.

Use this when a task is a fan-out/aggregate job worth orchestrating in code rather than doing turn-by-turn: codebase-wide sweeps, large migrations, multi-source research you cross-check, or multi-angle planning. Covers authoring a workflow (the meta block + the agent/parallel/pipeline/phase/log API), running it (non-blocking by default), and saving a good run as a reusable command. NOT for one-off single-agent tasks — use a plain scoop or `agent` for those.

Use this when a cherry target is connected — a third-party host web page that has embedded a SLICC follower via the @ai-ecoverse/cherry SDK and lent itself to you (a cloud-cone leader) as a driveable, capability-limited browser target. Covers what you can and cannot do with a cherry target (navigate / screenshot / open URL, NEVER raw network), the `cherry-emit` command for pushing host-page events, and the `[cherry]` licks you receive when the host page reports an event.

Use this whenever a response could benefit from richer visualization, guided interaction, or a touch of fun — pickers, calculators, sliders, mini explorers, charts, animated demos, choose-your-own-adventure prompts, anything that lands better as a hydrating widget than as plain prose. Dips are ephemeral `shtml` code blocks rendered inline in chat (no state persistence, lick-only). Reach for them generously: every interactive moment the user gets is a moment they don't have to type a clarifying message. For persistent dashboards, editors, or multi-page apps use sprinkles instead.

Use this when you receive a `[Sprinkle Event: welcome]` lick with `action: 'onboarding-complete-with-provider'` — fired exactly once after the user finishes the first-run wizard and validates an LLM provider. Send a short personalized reply (greet by name, react to provider/model, three follow-up actions: obvious + obligatory + outrageous), then silently run `upskill recommendations --install`. Other welcome-flow actions (`first-run`, `onboarding-complete`, `connect-ready`, `connect-attempt`, `oauth-attempt`, `shortcut-migrate`, `request-mount`) are intercepted by the runtime and do not reach the agent — ignore them if they ever leak.

Use this when deciding whether to do work yourself or delegate to a scoop, when fanning out parallel scoops, or when picking models for sub-agents. Covers scoop lifecycle (when to drop), parallel orchestration (`scoop_mute`, `scoop_unmute`, `scoop_wait`), one-shot ephemeral sub-agents via the `agent` shell command, and model selection. Read this BEFORE running `scoop_scoop` for non-trivial work.

Use this when setting up event-driven automation in SLICC — webhooks, cron tasks, or filesystem watchers that route events to scoops. Covers `webhook`, `crontask`, and `fswatch` shell commands. Read this BEFORE wiring up anything that should fire on a schedule, an HTTP call, or a VFS change.