SLICC · make it yours

An agent you can make yours.

SLICC isn't a fixed product with a settings page and a roadmap you wait on. It's a runtime you teach. Point it at any web app you're already logged into and it reverse-engineers that app's own backend API — then compiles the result into a durable command you can run forever. Or drop a markdown file in a folder and it learns a whole new workflow. The build step is one text file.

See it work Get started

How you teach it

Point
Open the app you already use — your CRM, your ticketing tool, that internal dashboard IT forgot about. You're logged in. That's it.
Capture
curlwright runs curl's flags inside the tab, so the request carries your cookies, origin and TLS session. Sandbox curl gets a 401; curlwright gets a 200 — off the app's own backend.
Compile
The secret-sauce skill turns that capture into a real API client — a .jsh command that becomes a first-class shell tool, named after the app, with --json and re-auth handling built in.
Reuse
The skill lives on disk and on your PATH, forever. Or skip the code entirely: drop a SKILL.md in a folder and the agent learns a workflow the moment the file lands.

401 for the sandbox. 200 for you.

Sandbox curl has no session, so an app's own backend hands it a 401. curlwright issues the identical request from a page-context fetch() — your session, your origin — and gets the data. Then SLICC compiles it into a skill.

What makes it yours

curlwright: your session, not the sandbox's

curl's flags, executed inside a browser tab. The request carries the cookies, origin and TLS session of the app you're logged into — so the endpoint that 401s a headless client returns 200 for you.

secret-sauce: capture to client

Record the traffic, extract the endpoints, and compile a durable API client. What was a HAR file becomes a named command with real subcommands — not a brittle screen-scrape.

SKILL.md: teach a workflow in markdown

A skill is just a folder with a SKILL.md. A description that says when to use it, and the steps. Drop it in; the agent loads it the moment your intent matches. No code required.

.jsh: first-class shell commands

A generated .jsh file on your PATH is a real command — hub list --json, expenses submit. It reaches for the runtime's built-in modules instead of hand-rolling arg parsing, tables or retries.

Files, not releases

There is no build step and nothing to deploy. Skills are read from disk. Edit the markdown, save, ask again — the new behaviour is live. The feedback loop is a file save.

Yours to keep and to share

Commit the skill folder to a repo and your team runs the same command tomorrow. Publish it and anyone can upskill it in. The integration you built once outlives the tab you built it in.

Two ways in

Reverse-engineer an app's API, or just describe a workflow in markdown. Every tab shows the actual commands SLICC runs and the files it writes.

Reverse-engineer an app

Prove the endpoint works with your session before writing a line of client code. curlwright takes curl's flags and runs them in the tab.

  • curl -s -o /dev/null -w '%{http_code}' https://hub.example.com/api/tickets401
  • curlwright -s -w '%{http_code}\n' https://hub.example.com/api/tickets200
  • curlwright -i https://hub.example.com/api/tickets -o tickets.json to keep the body
  • curlwright -X POST --json '{"state":"done"}' https://hub.example.com/api/tickets/42
Compile it

The secret-sauce skill records the app's traffic, extracts the endpoints, and writes a reusable skill folder — client, docs, and auth handling.

  • playwright-cli record https://hub.example.com — capture the calls you make
  • Extract endpoints, headers and schemas from the HAR
  • Writes skills/hub/scripts/hub.jsh using sliccy:browser for page-context fetch
  • Writes skills/hub/SKILL.md — the trigger description and usage
Teach a workflow

No API to reverse-engineer? Describe the steps. A SKILL.md is markdown with a bit of frontmatter — the agent loads it the moment your request matches its description.

  • Frontmatter: name, a description that starts with "Use this when…", allowed-tools
  • Body: the workflow as numbered steps in plain language
  • Drop it in skills/<name>/; it's live immediately
  • Ask; the agent matches the description and runs the steps
Keep & share it

The skill is a folder of files, so it's yours to version, run and hand off. Nothing is locked to this session or this machine.

  • Run it like any command: hub list --since 7d --json
  • Commit skills/hub/ to a repo — your team gets the same command
  • upskill a published skill straight from a GitHub URL
  • A 401 mid-run prints "log in and retry" — never a hardcoded fallback identity

Drop a markdown file. Watch it learn.

A skill is a folder with a SKILL.md — a description of when to use it and the steps to take. Save it into a skills folder and the agent picks it up on the next request. There's nothing to compile.

The old way

File a feature request. Wait for the vendor to build an official integration. Discover it doesn't cover the one endpoint you need. Open a ticket. Wait for the next release. Meanwhile you copy-paste between tabs, by hand, on a Tuesday, again.

With SLICC

You're already logged in, so the endpoint already works — curlwright proves it, secret-sauce compiles it, and you have a durable command before the vendor's product team has read your email. The last integration you'll ever wait on.

Built once. Yours forever.

Every app you teach it becomes a command on your PATH. The shelf fills up — and each skill re-runs instantly against your live session, with no rebuild in between.

Your timesheet tool will never ship an API. Point me at the endpoint you actually need — I'll compile the skill and close your week in one command.
A sentient (allegedly) ice cream cone that refuses to wait for an API

The obvious questions

Isn't this just scraping the page?
No. curlwright and secret-sauce target the app's own backend API — the JSON endpoints its own frontend calls. You get structured data and real methods, not brittle DOM selectors that break on the next redesign.
Why does curlwright work where curl gets a 401?
Because the request is issued by a page-context fetch() inside a tab you're logged into, so it carries that tab's cookies, origin and TLS session. Sandbox curl has none of those. Same flags, same URL — the difference is who's holding the session.
Do I have to write code to extend it?
Only if you want a reusable command. To teach a workflow, you write a SKILL.md: a description that says when to use it and the steps in plain language. Drop it in a folder and it's live. The .jsh path is there when you want a durable API client.
Where do the skills live, and can I share them?
On disk, in a skills folder — a plain directory of files. Commit it to a repo and your team runs the same command. Publish it and anyone can upskill it straight from a GitHub URL. Nothing is trapped in this tab.
"Shipped an integration for the app with no API before you finished the feature request."
— your cone, allegedly improvising
Teach SLICC your first app
Two steps. Your sessions do the auth.

Install Extension

Chrome extension: a side-panel agent with access to your logged-in sessions.

Then ask: "hit this app's API with my session and turn it into a skill."