my-pi/pi-chrome/docs/EXAMPLES.md

pi-chrome examples

Real, useful agent prompts. Drop any of these into Pi after running /chrome onboard, then /chrome authorize. Each one uses Chrome tabs and accounts you already have.

Daily workflow

PR triage

Use chrome_tab list to find my GitHub notifications tab.
chrome_snapshot it. Group PRs by:
  - awaiting my review
  - blocked on me (changes requested back)
  - mergeable (approved + green CI)
Output a 5-bullet ranked triage. Do not click anything.

Linear standup

Open my Linear current cycle in the active tab.
chrome_snapshot, then write yesterday/today/blockers
in the exact format my standup channel uses.

Slack catch-up

For each unread channel in my Slack tab, chrome_snapshot,
extract the top 3 messages that mention me or my team,
and summarize what I missed in <100 words total.

Debugging

Reproduce a customer bug with evidence

1. chrome_navigate to https://staging.acme.com/orders/<id>
2. chrome_snapshot
3. Click "Refund" with chrome_click
4. Use chrome_list_network_requests to capture the API call
5. chrome_get_network_request on the failing one — give me the response body
6. chrome_screenshot the error state to ./repro/refund-bug.png

Visual diff local vs staging

chrome_screenshot http://localhost:3000/pricing → ./diff/local.png
chrome_screenshot https://staging.acme.com/pricing → ./diff/staging.png
Then read both, describe layout differences in plain English.

Console + network forensics

Reproduce the checkout bug on the active tab.
After the failure:
  - chrome_list_console_messages
  - chrome_list_network_requests
Cross-reference the timestamps and tell me what broke first.

Admin / ops

Multi-tab cross-check

I have Stripe, Postmark, and our internal admin open in 3 tabs.
For user <id>, chrome_snapshot each tab in turn and find
any field where state disagrees. Output a 3-column table.

Bulk gentle action (safe form-fill, no submit)

Open our vendor portal "Add Vendor" form.
For each row in ./vendors.csv:
  - chrome_fill the form
  - chrome_screenshot it
  - STOP before submit
  - chrome_evaluate "history.back()" to return to the list
I will review screenshots and submit manually.

Auth-only data pull

My analytics dashboard is open and the cookie auth would die in headless mode.
chrome_evaluate to read window.__APP_STATE__.dashboardData
and dump today's KPIs as JSON.

Demos / PRs

Capture screenshots for a PR description

On localhost:3000/feature-x:
  - empty state → ./pr/01-empty.png
  - filled state → ./pr/02-filled.png
  - error state (delete the API key from devtools first) → ./pr/03-error.png
Save each with chrome_screenshot. Output a markdown block I can paste into the PR.

Record a guided demo flow

On my staging app:
1. Walk the new-onboarding flow start to finish
2. After each chrome_click or chrome_navigate, chrome_screenshot
3. Save numbered PNGs under ./demo/
4. Write narration captions for each step

Forms with frameworks

React controlled inputs

Use `chrome_fill` for React inputs when you want to replace the full value.
Pass `includeSnapshot=true` to verify the component re-rendered with the new value.

File upload without the native picker

chrome_upload_file paths=[./fixtures/avatar.png] selector="input[type=file]"
# Uses Chrome file-input control. No native file picker opens.

Drag-to-reorder lists

chrome_drag fromUid=row-3 toUid=row-1
# Uses Chrome pointer drag through its input layer.

Multi-session patterns

pi-chrome shares one bridge across all Pi sessions on the same machine. Useful patterns:

Planner + Worker

• Planner session stays high level: "find the bug, decide the fix."
• Worker session runs the actual chrome_* tools.
• Both see the same Chrome state because they're both pointing at your real profile.

Watcher

A third Pi session can run chrome_snapshot periodically in background: true mode and post summaries via pi-qq — handy for long-running flows.

Chrome input

Interactive tools use Chrome's real input layer by default: clicks, typing, fill, keys, hover, drag, scroll, and touch. This is reliable for:

• sign-in flows
• guarded buttons
• audio/video controls
• fullscreen and other user-activation checks
• pages where DOM injection/evaluate is limited, if the agent can use screenshots + coordinates

Strict CSP note: chrome_snapshot/chrome_evaluate work even on pages that disallow unsafe-eval, because they run via CDP Runtime.evaluate (not page-level eval/new Function), which is not subject to page CSP. chrome_screenshot, tab/navigation tools, and real input also work under any CSP.

Chrome may show its debugger banner while pi-chrome is attached.