libretto-readonly
Skill898 starsChanged 3 months agoMITView on GitHub
Read-only Libretto workflow for diagnosing live browser state without clicks, typing, navigation, or mutation requests.
We split this skill into the rules it gives an agent
15 rules. About 0 are common, 3 are distinctive, and 12 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
12
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Use this skill when the browser session must stay strictly read-only.
- Distinctive: line 16
Only a user can change the session mode for an existing session.
- Very specific: line 21
Do not use exec, run, or any direct Playwright action that could change browser or application state.
- Distinctive: line 22
Do not click, type, submit forms, navigate, upload files, dispatch DOM events, or send non-GET requests.
- Very specific: line 23
Prefer snapshot first when the visible page state is unclear.
- Very specific: line 24
Use readonly-exec for focused inspection: titles, HTML, locator text, counts, visibility checks, and GET requests.
- Very specific: line 25
Keep snippets small and purpose-built.
- Very specific: line 33
Use connect to attach to an existing CDP endpoint for a preserved browser session.
- Very specific: line 34
Use --read-only when creating the Libretto session handle for a preserved browser session.
- Very specific: line 43
Use pages when a popup, new tab, or second page exists.
- Very specific: line 44
If readonly-exec or snapshot complains about multiple pages, list ids first and then pass --page.
- Very specific: line 52
Use snapshot as the first high-level observation tool.
- Very specific: line 53
Run snapshot <ref> to inspect a subtree from the latest full snapshot.
- Very specific: line 57
Use readonly-exec for narrow inspection code only.
- Very specific: line 86
Use close when the inspection session is no longer needed, unless the user explicitly asks to keep the browser open.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
How Libretto Read-Only Works
- Use this skill when the browser session must stay strictly read-only.
- Libretto stores read-only vs write-access on the session itself.
- The primary inspection tools are
snapshotandreadonly-exec. readonly-execreuses Libretto's normal execution pipeline, but it only exposes read-only helpers and denies mutating Playwright methods.- Only a user can change the session mode for an existing session. Never change a session's mode on your own — the user must change it themselves manually.
Working Rules
- Announce which session you are using and what page you are inspecting.
- Do not use
exec,run, or any direct Playwright action that could change browser or application state. - Do not click, type, submit forms, navigate, upload files, dispatch DOM events, or send non-GET requests.
- Prefer
snapshotfirst when the visible page state is unclear. - Use
readonly-execfor focused inspection: titles, HTML, locator text, counts, visibility checks, and GET requests. - Keep snippets small and purpose-built. Do not run multiple
readonly-execcommands at the same time. - Close disposable sessions before your final response once inspection is complete. Open browsers keep consuming local or hosted resources.
- End with diagnosis and handoff guidance, not an attempted in-browser repair.
Commands
connect
- Use
connectto attach to an existing CDP endpoint for a preserved browser session. - Use
--read-onlywhen creating the Libretto session handle for a preserved browser session. - Libretto read-only mode is enforced through Libretto commands; direct CDP clients that skip Libretto are outside this boundary.
libretto connect http://127.0.0.1:9222 --read-only --session failed-job-debugpages
- Use
pageswhen a popup, new tab, or second page exists. - If
readonly-execorsnapshotcomplains about multiple pages, list ids first and then pass--page.
libretto pages --session failed-job-debugsnapshot
- Use
snapshotas the first high-level observation tool. - Run
snapshot <ref>to inspect a subtree from the latest full snapshot.
readonly-exec
- Use
readonly-execfor narrow inspection code only. - Denied operations fail with
ReadonlyExecDenied: ....
Helpers
page— a read-only PlaywrightPageproxy. Standard Playwright read methods work normally (url(),title(),content(),frames(),getByRole(),locator(),textContent(),isVisible(),count(),scrollIntoViewIfNeeded(), etc.).frames()returns read-onlyFrameproxies, including fromchildFrames()andparentFrame(). Anything that mutates a page or frame (click,fill,goto,evaluate,keyboard,mouse) is blocked.state— the current Libretto session state object.get(url, options?)— HTTP client restricted to GET and HEAD requests. Replacesfetch, which is blocked in readonly mode. Any request with a body or a non-GET/HEAD method throwsReadonlyExecDenied.scrollBy(deltaX, deltaY)— scroll the viewport by pixel offset. Use this to inspect content below the fold without targeting a specific element.
Standard JS globals console, URL, Buffer, setTimeout, and setInterval are also available.
Examples
libretto readonly-exec "return page.url()" --session failed-job-debug
libretto readonly-exec "return await page.getByRole('heading').first().textContent()" --session failed-job-debug
libretto readonly-exec "return await page.frames()[1]?.getByRole('heading').textContent()" --session failed-job-debug
# HTTP GET inspection
echo "const r = await get('https://api.example.com/status'); return await r.json()" \
| libretto readonly-exec - --session failed-job-debug
# Scroll down to inspect below-the-fold content
libretto readonly-exec "await scrollBy(0, 500)" --session failed-job-debugclose
- Use
closewhen the inspection session is no longer needed, unless the user explicitly asks to keep the browser open.
libretto close --session failed-job-debugOther versions1 project uses a version of this.
Word for word · 1
- saffron-health/libretto★ 883100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository30 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .deepsec/AGENTS.mdAGENTS.md
- docs/AGENTS.mdAGENTS.md
- .opencode/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- docs/CLAUDE.mdCLAUDE.md
- address-reviewSkill
- cli-developmentSkill
- erroreSkill
- external-electron-appsSkill
- fix-merge-conflictsSkill
- generate-specSkill
- generate-spec-v2Skill
- get-pr-reviewsSkill
- glimpse-changesSkill
- implement-specSkill
- improve-codebase-architectureSkill
- libretto-readonlySkill
- librettoSkill
- promptingSkill
- push-everythingSkill
- pushSkill
- reviewSkill
- spec-reviewSkill
- summarizeSkill
- technical-writingSkill
- turborepoSkill
- update-docsSkill
- writing-testsSkill
- librettoSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

