--- name: gstack version: 1.1.0 description: | Fast headless browser for QA testing and site dogfooding. Navigate any URL, interact with elements, verify page state, diff before/after actions, take annotated screenshots, check responsive layouts, test forms and uploads, handle dialogs, and assert element states. ~100ms per command. Use when you need to test a feature, verify a deployment, dogfood a user flow, or file a bug with evidence. gstack also includes development workflow skills. When you notice the user is at these stages, suggest the appropriate skill: - Brainstorming a new idea → suggest /office-hours - Reviewing a plan (strategy) → suggest /plan-ceo-review - Reviewing a plan (architecture) → suggest /plan-eng-review - Reviewing a plan (design) → suggest /plan-design-review - Creating a design system → suggest /design-consultation - Debugging errors → suggest /debug - Testing the app → suggest /qa - Code review before merge → suggest /review - Visual design audit → suggest /design-review - Ready to deploy / create PR → suggest /ship - Post-ship doc updates → suggest /document-release - Weekly retrospective → suggest /retro - Wanting a second opinion or adversarial code review → suggest /codex - Working with production or live systems → suggest /careful - Want to scope edits to one module/directory → suggest /freeze - Maximum safety mode (destructive warnings + edit restrictions) → suggest /guard - Removing edit restrictions → suggest /unfreeze - Upgrading gstack to latest version → suggest /gstack-upgrade If the user pushes back on skill suggestions ("stop suggesting things", "I don't need suggestions", "too aggressive"): 1. Stop suggesting for the rest of this session 2. Run: gstack-config set proactive false 3. Say: "Got it — I'll stop suggesting skills. Just tell me to be proactive again if you change your mind." If the user says "be proactive again" or "turn on suggestions": 1. Run: gstack-config set proactive true 2. Say: "Proactive suggestions are back on." allowed-tools: - Bash - Read - AskUserQuestion --- {{PREAMBLE}} If `PROACTIVE` is `false`: do NOT proactively suggest other gstack skills during this session. Only run skills the user explicitly invokes. This preference persists across sessions via `gstack-config`. # gstack browse: QA Testing & Dogfooding Persistent headless Chromium. First call auto-starts (~3s), then ~100-200ms per command. Auto-shuts down after 30 min idle. State persists between calls (cookies, tabs, sessions). {{BROWSE_SETUP}} ## IMPORTANT - Use the compiled binary via Bash: `$B ` - NEVER use `mcp__claude-in-chrome__*` tools. They are slow and unreliable. - Browser persists between calls — cookies, login sessions, and tabs carry over. - Dialogs (alert/confirm/prompt) are auto-accepted by default — no browser lockup. - **Show screenshots:** After `$B screenshot`, `$B snapshot -a -o`, or `$B responsive`, always use the Read tool on the output PNG(s) so the user can see them. Without this, screenshots are invisible. ## QA Workflows ### Test a user flow (login, signup, checkout, etc.) ```bash # 1. Go to the page $B goto https://app.example.com/login # 2. See what's interactive $B snapshot -i # 3. Fill the form using refs $B fill @e3 "test@example.com" $B fill @e4 "password123" $B click @e5 # 4. Verify it worked $B snapshot -D # diff shows what changed after clicking $B is visible ".dashboard" # assert the dashboard appeared $B screenshot /tmp/after-login.png ``` ### Verify a deployment / check prod ```bash $B goto https://yourapp.com $B text # read the page — does it load? $B console # any JS errors? $B network # any failed requests? $B js "document.title" # correct title? $B is visible ".hero-section" # key elements present? $B screenshot /tmp/prod-check.png ``` ### Dogfood a feature end-to-end ```bash # Navigate to the feature $B goto https://app.example.com/new-feature # Take annotated screenshot — shows every interactive element with labels $B snapshot -i -a -o /tmp/feature-annotated.png # Find ALL clickable things (including divs with cursor:pointer) $B snapshot -C # Walk through the flow $B snapshot -i # baseline $B click @e3 # interact $B snapshot -D # what changed? (unified diff) # Check element states $B is visible ".success-toast" $B is enabled "#next-step-btn" $B is checked "#agree-checkbox" # Check console for errors after interactions $B console ``` ### Test responsive layouts ```bash # Quick: 3 screenshots at mobile/tablet/desktop $B goto https://yourapp.com $B responsive /tmp/layout # Manual: specific viewport $B viewport 375x812 # iPhone $B screenshot /tmp/mobile.png $B viewport 1440x900 # Desktop $B screenshot /tmp/desktop.png # Element screenshot (crop to specific element) $B screenshot "#hero-banner" /tmp/hero.png $B snapshot -i $B screenshot @e3 /tmp/button.png # Region crop $B screenshot --clip 0,0,800,600 /tmp/above-fold.png # Viewport only (no scroll) $B screenshot --viewport /tmp/viewport.png ``` ### Test file upload ```bash $B goto https://app.example.com/upload $B snapshot -i $B upload @e3 /path/to/test-file.pdf $B is visible ".upload-success" $B screenshot /tmp/upload-result.png ``` ### Test forms with validation ```bash $B goto https://app.example.com/form $B snapshot -i # Submit empty — check validation errors appear $B click @e10 # submit button $B snapshot -D # diff shows error messages appeared $B is visible ".error-message" # Fill and resubmit $B fill @e3 "valid input" $B click @e10 $B snapshot -D # diff shows errors gone, success state ``` ### Test dialogs (delete confirmations, prompts) ```bash # Set up dialog handling BEFORE triggering $B dialog-accept # will auto-accept next alert/confirm $B click "#delete-button" # triggers confirmation dialog $B dialog # see what dialog appeared $B snapshot -D # verify the item was deleted # For prompts that need input $B dialog-accept "my answer" # accept with text $B click "#rename-button" # triggers prompt ``` ### Test authenticated pages (import real browser cookies) ```bash # Import cookies from your real browser (opens interactive picker) $B cookie-import-browser # Or import a specific domain directly $B cookie-import-browser comet --domain .github.com # Now test authenticated pages $B goto https://github.com/settings/profile $B snapshot -i $B screenshot /tmp/github-profile.png ``` ### Compare two pages / environments ```bash $B diff https://staging.app.com https://prod.app.com ``` ### Multi-step chain (efficient for long flows) ```bash echo '[ ["goto","https://app.example.com"], ["snapshot","-i"], ["fill","@e3","test@test.com"], ["fill","@e4","password"], ["click","@e5"], ["snapshot","-D"], ["screenshot","/tmp/result.png"] ]' | $B chain ``` ## Quick Assertion Patterns ```bash # Element exists and is visible $B is visible ".modal" # Button is enabled/disabled $B is enabled "#submit-btn" $B is disabled "#submit-btn" # Checkbox state $B is checked "#agree" # Input is editable $B is editable "#name-field" # Element has focus $B is focused "#search-input" # Page contains text $B js "document.body.textContent.includes('Success')" # Element count $B js "document.querySelectorAll('.list-item').length" # Specific attribute value $B attrs "#logo" # returns all attributes as JSON # CSS property $B css ".button" "background-color" ``` ## Snapshot System {{SNAPSHOT_FLAGS}} ## Command Reference {{COMMAND_REFERENCE}} ## Tips 1. **Navigate once, query many times.** `goto` loads the page; then `text`, `js`, `screenshot` all hit the loaded page instantly. 2. **Use `snapshot -i` first.** See all interactive elements, then click/fill by ref. No CSS selector guessing. 3. **Use `snapshot -D` to verify.** Baseline → action → diff. See exactly what changed. 4. **Use `is` for assertions.** `is visible .modal` is faster and more reliable than parsing page text. 5. **Use `snapshot -a` for evidence.** Annotated screenshots are great for bug reports. 6. **Use `snapshot -C` for tricky UIs.** Finds clickable divs that the accessibility tree misses. 7. **Check `console` after actions.** Catch JS errors that don't surface visually. 8. **Use `chain` for long flows.** Single command, no per-step CLI overhead.